Same model, different number of gauss points about ifem-elasticity HOT 5 CLOSED

It is due to the zero-knot span elements that are genereted due to the C^0 lines in the first model. These "elements" are ignored during the numerical integration, but not when calculating the total number of quadrature points in the model. Therefore this value is misleading in this case.
It has to be like this, I think, as the FiniteDeformation classes that uses this to allocate internal gauss point buffers, also assumes that the zero-span elements have been allocated alllthough they are not processed (for implementation convenience).

Bonus answer: The multi-patch ModelGenerators has not been included in the Elasticity solvers to this point, think that was something added mainly for the (Navier)Stokes solvers,

from ifem-elasticity.

Apperently this is because it counts the "zero-knot-span" elements when evaluating the number of gauss points. The knot vector is [0 0 0 1 1 2 2 3 3 3] (i.e. 5 quadratic elements, including zero-size) in one direction and [0 0 1 2 3 3] (i.e. 3 linear elements) and then all elements are split into 8x8 new ones. The zero-size elements (6 of them) are only split in the linear direction, and will thus only make 8 new elements.

Total non-degenerate elements: 3x3x8x8 = 576
Total zero-area elements: 6*8 = 48
Total gauss points = (48 + 576)*16 = 9984

This only happens for the single-patch version as zero-area knots on patch boundaries are ignored.

I don't know if this is causing any subsequent follow-up errors or if we can safely ignore it. I'll leave that up to @akva2 and @kmokstad to decide.

from ifem-elasticity.

I think it is safe to ignore it. As I said, the calculated value is only used to allocate internal buffers for those integrands that needs that (mainly those with nonlinear material properties). In the worst case you then only allocate a larger buffer than strictly needed, but never too small.

from ifem-elasticity.

If it is safe to ignore it, then feel free to close the issue.

from ifem-elasticity.

No bug, but a harmless feature of the internal C0-lines

from ifem-elasticity.