Ok, after checking the implementation of Nedelec elements in
Getfem++, I see that there may be a difference with the common
definition of these elements.
In order to have a general implementation (for curved elements for
instance) and a maximum of computation done only once, they are
defined via a reference element.
What seems to be litigious is that that the base functions are
transported via the geometric transformation like vectors. That is,
they are multiplied to the left by the gradient of the
transformation. I tried to change this and transport them like
gradients (i.e. multiplied by the transposed inverse of the
gradient of the transformation) and I have the same results as
your python program.
It is a little bit annoying because this implies that there is two
kind of intrinsic vectorial elements, those which are transported
as vector and thos which are transported as gradients.
My question is : Is there a big difference in the capability of
approximation between the two versions ? The one which is presently
implemented in getfem is nevertheless a a valid finite element
(not really the Nedelec one). Should I give two versions ?
I am not a so much specialist in Nedelec elements, so I would
appreciate your advice.
Dear Yves,
in fact (limited to my personal use) there are two kinds of intrisic
vectorial elements : the H(rot) conformal and the H(div) conformal
elements.
If the usual definition of the Nedelec element is kept on the reference
element but the transformation used is not the valid one, the obtained
finite element family should not be H(curl) conformal.
My advice is then to keep only the original Nedelec family.
Best regards,
Ronan