Kratos: Normal computation on condition using CalculateNormal3D for 4 noded (quad)

[mohittyagi-k]

Hi All, I was wondering if the functionality of the CalculateNormal3D in NormalCalculationUtils could be extended to linear quads. Currently, it considers only 3 nodes in the normal computation.

Any help/thought much appreciated, thank you.

---

@ddiezrod
@pooyan-dadvand

[loumalouomega]

You can use mortar utilities, it is general to any geometry:

https://github.com/KratosMultiphysics/Kratos/blob/feb8e05b7236f3987ecfc29bf9ff3e7966687334/kratos/tests/test_mortar_utilities.py#L15

It is an average normal

[loumalouomega]

https://github.com/KratosMultiphysics/Kratos/blob/feb8e05b7236f3987ecfc29bf9ff3e7966687334/kratos/utilities/mortar_utilities.h#L178

[ddiezrod]

Right now we are using NormalCalculationUtils to calculate normals for nodes and conditions which seems to be correct utility to use for this. I think it makes sense to only use this one and use a template or something to make it work for lines, triangles and quads, right?

[loumalouomega]

We decided to unify these utilities some time ago, but I have not done yet. My proposal was in case you needed right now you can use that

[loumalouomega]

I think it makes sense to only use this one and use a template or something to make it work for lines, triangles and quads, right?

The algorithm considered is slightly different, that's why I didn't know how to properly unify

[mohittyagi-k]

I guess one can use mortar utilities to compute the average normal at the node and the UnitNormal in Geometry to compute the normal to the conditions.

[ddiezrod]

@loumalouomega Its not very urgent, that's why we opened the issue to discuss how to unify it. I know there have been discussions about this, so, my question would be: is that enough if we extend NormalUtils to be able also to handle quads or are we missing something else? @KratosMultiphysics/design-committee

[RiccardoRossi]

The geometry utils was designed to give a specialized (and faster) solution for the specific case of triangles and tets.

if you want the general purpose solution in my personal opinion it is best to call directly the geometry normal calculation functions (which will work for any geometry).

[loumalouomega]

if you want the general purpose solution in my personal opinion it is best to call directly the geometry normal calculation functions (which will work for any geometry).

Yes, but that is the normal in the given GP, if you want the normal in the nodes you should do something, like it is done in the MortarUtilities

[ddiezrod]

@loumalouomega exactly

[RiccardoRossi]

i do not really follow.

if you want to assemble the normal on the gauss point to obtain the nodal normal, ok, but then simply call the geometry function inside the function that does the assembly...(and use the proper integration rule)

[pooyan-dadvand]

Maybe we can have a new method CalculateNormals as a generic version of CalculateOnSimplex which calls the geometry one?

Meanwhile, @RiccardoRossi, I am not sure about the virtual function effect on the performance. Don't forget that Normal has a cross-product inside and definitely does more than 20 flops. For me, the important reason for keeping the CalculateOnSimplex is because it is used in many places.

[loumalouomega]

See #7062

[RiccardoRossi]

@pooyan-dadvand it is a bit more than this, since the point is that for simplicial geometries you know the sizes so that you don't need any heap allocation, while in the other cases it is based on the computation of jacobians whose size is not known at compile time (also if you use anything that is not a simplex you will need to use full integration instead of one gauss point).

[ddiezrod]

But @RiccardoRossi, would it be ok if we maintained the current CalculateOnSimplex for performance and just added this new generic method?

[RiccardoRossi]

yes, ok to me

On Wed, Jun 24, 2020, 9:33 AM Daniel Diez [e-mail] wrote:

But @RiccardoRossi https://github.com/RiccardoRossi, would it be ok if
we maintained the current CalculateOnSimplex for performance and just
added this new generic method?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/KratosMultiphysics/Kratos/issues/7052#issuecomment-648648848,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AB5PWEN7XONUP4P2XFMWZF3RYGT3DANCNFSM4N2IQ26Q
.

[loumalouomega]

I created a transition PR, can anyone approve ?

El mié., 24 jun. 2020 9:34, Riccardo Rossi [e-mail]
escribió:

yes, ok to me

On Wed, Jun 24, 2020, 9:33 AM Daniel Diez [e-mail]
wrote:

But @RiccardoRossi https://github.com/RiccardoRossi, would it be ok if
we maintained the current CalculateOnSimplex for performance and just
added this new generic method?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<
https://github.com/KratosMultiphysics/Kratos/issues/7052#issuecomment-648648848
,
or unsubscribe
<
https://github.com/notifications/unsubscribe-auth/AB5PWEN7XONUP4P2XFMWZF3RYGT3DANCNFSM4N2IQ26Q

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/KratosMultiphysics/Kratos/issues/7052#issuecomment-648649545,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEYQZAG52IPC5MT5AARG4H3RYGUAXANCNFSM4N2IQ26Q
.

[pooyan-dadvand]

@pooyan-dadvand it is a bit more than this, since the point is that for simplicial geometries you know the sizes so that you don't need any heap allocation, while in the other cases it is based on the computation of jacobians whose size is not known at compile time (also if you use anything that is not a simplex you will need to use full integration instead of one gauss point).

I don't follow your point here. To my understanding, each geometry can/should provide the most efficient version of Normal calculation. And each geometry nodes perfectly what is the Jacobian's sizes and how to calculate it efficiently.