getfem-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Getfem-users] Question about non-linear terms


From: Konstantinos Poulios
Subject: Re: [Getfem-users] Question about non-linear terms
Date: Wed, 7 Jul 2010 19:32:12 +0200

Dears Yves,

thanks for your helpful information.

On Sun, Jul 4, 2010 at 12:20 PM, Renard Yves <address@hidden> wrote:
>
> Dear Kostas,
>
>
> The non-linear term allows to add a term to the generic assembly which is be
> computed on each Gauss point.
> The mechanism of the non-linear term is not fully satisfactory, I think, and
> you are right has not been documented.
> One of the problem is to furnish some efficient pre-computation not to have
> an interpolation of the shape function
> at each gauss point. This is the role of the
> getfem::fem_interpolation_context objects.
> One problem in the assembly routine is that there is only one
> fem_interpolation_context for each term of the generic assembly.
> The 'compute' method of the nonlinear term is called with the
> fem_interpolation_context corresponding to the first fem declared in the
> generic assembly (i.e. #1 for NonLin(#1,#2,#3, ...)).
> If there is more than one fem declared in the generic assembly for the
> nonlinear term, then the 'prepare' method of the nonlinear term is called
> for each additional fem. the second argument of 'prepare' is the index of
> the fem in the generic assembly. The method 'prepare' is called before
> 'compute' for each Gauss point and typically can make some pre-computations.

To my understanding the use of the prepare method makes sense only in
the case that the fems #2, #3, ... share the same mesh as the fem #1.
As far as I understand the ctx argument passed to the prepare method
refers always to the main mesh_im, so it makes sense only for the fems
which are defined on the same mesh as the applied integration method.
Anyway I don't consider this behaviour as a problem.

> Moreover, generally, you need in the term the value of a certain variable.
> So, generally, the constructor take the variable and the corresponding
> mesh-fem as a parameter.
>
> I don't know if my explanations are very clear ...
>
> This is sure that in order to build a nonlinear term, one has to have a
> clear idea of the internal of Getfem ! For instance, the difference between
> a scalar fem with is vectorized with the a set_qdim and an intrinsic
> vectorial element have to be taken into account ...
> This is one of my goal to try to simplify the writing of nonlinear terms ...
>
>
> Regards,
>
> Yves.

Now, I would have some further questions about the nonlinear terms.

1. In the existing examples of nonlinear terms in GetFem++ the
dimensions of the tensor t which is returned by the compute() method
are usually quite small. In my application case I would like to define
a nonlinear term which will return a tensor with its first dimension
equal to nb_dof(mesh_fem#1) and its second dimension equal to
nb_dof(mesh_fem#2) etc... . Would the big size of the tensor present a
problem for the performance of the assembly procedure?

2. I have studied a bit the implementation of the Normal() component
inside the assembly procedure and I have some questions about its
calculation in the add_elem method in getfem_mat_elem.cc file. The un
variable seems to represent the face normal in the reference element.
The vector up = B * un substitutes the Normal() component in the
assembly product. To my understanding the multiplication by up will
project every vectorial quantity defined in the real element onto the
un normal defined in the reference element. My question is if there is
an equivalence between the normals in the reference element and the
real element. Is it correct to interpret the Normal() term in the
assembly in the reference element? I wonder if I missed some step in
the calculation.

Best Regards

Kostas



reply via email to

[Prev in Thread] Current Thread [Next in Thread]