getfem-users
[Top][All Lists]
Advanced

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

Re: [Getfem-users] Nedelec DOF definition


From: Yves Renard
Subject: Re: [Getfem-users] Nedelec DOF definition
Date: Mon, 1 Feb 2016 14:56:20 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

Dear Torquil,

I think that, normally, the base functions should be normalized
such that the vector base function is unitary on the real element.
The base function on the real element are corrected by applying the
transformation matrix (see matrix M in
http://download.gna.org/getfem/html/homepage/project/femdesc.html#finite-element-methods-description)
which is indeed computed by the
mat_trans method (it computes the factors for the different edges).

Do you think there is something incorrect ?

Best regards,

Yves.




Le 31/01/2016 16:50, Torquil Macdonald Sørensen a écrit :
> Hi!
>
> While working with FEM_NEDELEC(3), I got some unexpected basis function
> values and mass matrix values. I'm used to the Nedelec basis function
> definition
>
> sigma_{ij} := lambda_i Grad lambda_j - lambda_j Grad lambda_i
>
> where ij is the line going from node i to node j.
>
> But when I evaluate the FEM_NEDELEC(3) basis function values, I get a
> sqrt(2) factor difference between Getfem and my own calculations, for
> the DOFs that correspond to local DOF numbers 3,4,5 in the reference
> simplex, i.e. those corresponding to edges of length sqrt(2):
>
> I created a mesh consisting of a single simplex with vertices (0,0,0),
> (1,0,0), (0,1,0), (0,0,1). The position of DOF 0 is (0.5,0,0). Then I
> evaluated the values of all DOFs at this position. According to Getfem,
> the value of DOF 3 at this position is (0, sqrt(2), 0). But my own
> calculations on paper with the above definition gives (0, 0.5, 0).
>
> Does that mean that Getfem is using additional prefactor in the
> definition of the NEDELEC DOFs, that depends on the edge length? I don't
> see any such factor in P1_nedelec_::P1_nedelec_(dim_type nc_), but
> perhaps it has something to do with what happens in
> P1_nedelec_::mat_trans()?
>
> Best regards
> Torquil Sørensen
>
>
> _______________________________________________
> Getfem-users mailing list
> address@hidden
> https://mail.gna.org/listinfo/getfem-users


-- 

  Yves Renard (address@hidden)       tel : (33) 04.72.43.87.08
  Pole de Mathematiques, INSA-Lyon             fax : (33) 04.72.43.85.29
  20, rue Albert Einstein
  69621 Villeurbanne Cedex, FRANCE
  http://math.univ-lyon1.fr/~renard

---------




reply via email to

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