Adding variables to a System and specifying FE Type with multiple Orders

[giorgiobornia]

Hi all,
   I have a very basic question that I guess can be answered more quickly here than me going through the source files. 

Let us say that I want to add a variable to a System.
From what I see from the documentation, the Finite Element type of the variable
is given by a Family and an Order.

 So, say that I want to add a Lagrange variable of Serendipity type (8 dofs) 
instead of a Biquadratic type (9 dofs), how do I do that?

They are both Lagrange, they are both second order,
however they are different FE spaces, 
 so it looks like I would need an additional argument to be specified in add_variable.

Is the underlying mesh driving the choice somehow? I would assume not,
i.e., I would expect the library to be able to construct whatever FE space on whatever underlying Mesh, like an 8-dof FE Lagrange on a Quad4 mesh (adding dof carriers as needed).

Thanks for any clarification and sorry if I missed some detail,
  Giorgio

[jwpeterson]

I would expect the library to be able to construct whatever FE space on whatever underlying Mesh

Unfortunately that's not the case. Generally speaking, you can have a lower-order LAGRANGE FE on a higher-order geometric element, and in that case some nodes won't have DOFs. For example, the following LAGRANGE combinations are supported:
✔️ SECOND on Quad8
✔️ SECOND on Quad9
✔️ FIRST on Quad4
✔️ FIRST on Quad8
✔️ FIRST on Quad9

As far as I know, it's not possible to declare a (SECOND, LAGRANGE) FE on a Quad9 and have it "drop" the DOF at the center node, giving you a serendipity discretization.

[giorgiobornia]

Thanks a lot for the ultra-quick reply. That helps a lot.
So, adding a variable of type (SECOND, LAGRANGE) would give

1. a Serendipity variable, if the Mesh is Quad8;
2. a Biquadratic variable, if the Mesh is Quad9;
3. nothing (not working), if the Mesh is Quad4.

I thought that case 3) was taken care of by adding the necessary nodes in the Mesh upon request. I don't know what happens in the background. Perhaps one wants to construct System variables on the Mesh with the Mesh being read-only (without modifying the Mesh backwards).
In that case, one could maybe decide to add all potentially needed nodes to the Mesh in the first place. But that may be overkill.

Giorgio

[roystgnr]

I thought that case 3) was taken care of by adding the necessary nodes in the Mesh upon request.

It is, but the request isn't add_variable(), it's mesh.all_second_order();, and you have to explicitly make it that way. I do like the "silently make things work" philosophy when it's cheap enough, but we're not going to nearly quadruple (in 3D, octuple) the number of nodes in your mesh without being asked.

In hindsight what we should have done is to have Order enums that don't correspond precisely to particular integers, like a SERENDIPITY enum for not-quite-SECOND order, but at this point we do so many conversions from Order to integer and back that I'm sure we'd see something break if we ever added an Order for which that conversion isn't bijective.

[giorgiobornia]

It is, but the request isn't add_variable(), it's mesh.all_second_order();

Along similar lines, semi-automatic ways to have a serendipity variable without redrawing mesh files (if the point is an inconvenience in that) would be to call

• a method like "mesh.remove_center_nodes()" if the starting mesh is a Quad9 (or other cases)
• a method like "mesh.add_serendipity_nodes()" if the starting mesh is a Quad4 (or other cases)
  If not there yet, they seem easy to implement.

but we're not going to nearly quadruple (in 3D, octuple) the number of nodes in your mesh without being asked.

Sure, makes sense.

In hindsight what we should have done is to have Order enums that don't correspond precisely to particular integers

Or maybe one would need a third FE specification besides Family and Order, like SubOrder or something, say for all-things-2nd-order.
No precise idea of the effects - in the guts of the library - of adding a 3rd parameter.

Giorgio