underworldcode
Unit vectors are not defined as normals
Hi @lmoresi,
In the following snippet, normals are not defined: https://github.com/underworldcode/underworld3/blob/4fe6bf4e6916a6d7b392840b1a8c81780f2fe4b4/src/underworld3/meshing.py#L719
I have two questions regarding this Q1) Is this necessary to define normals? Normals are defined for all other meshes. Q2) Don't see where these boundary_normals are used in discretisation.py? https://github.com/underworldcode/underworld3/blob/4fe6bf4e6916a6d7b392840b1a8c81780f2fe4b4/src/underworld3/discretisation.py#L193
The mesh.Gamma object wraps the PETSc normals. Thanks to your benchmarking, we know that the normals are not as useful as we expected for higher order fields.
This is therefore an incomplete interface - we want normals symbolically defined but we may need to do this via analytic solutions or interpolation from first order fields.
It’s a bit of a moving target so a wrapper is ok for now with a mesh-specific implementation if it’s needed.
Let’s discuss when I get back.
L
Sent from my iPhone
On 4 May 2024, at 08:50, Thyagarajulu Gollapalli @.***> wrote:
Hi @lmoresihttps://github.com/lmoresi,
In the following snippet, normals are not defined: https://github.com/underworldcode/underworld3/blob/4fe6bf4e6916a6d7b392840b1a8c81780f2fe4b4/src/underworld3/meshing.py#L719
I have two questions regarding this Q1) Is this necessary to define normals? Normals are defined for all other meshes. Q2) Don't see where these boundary_normals are used in discretisation.py? https://github.com/underworldcode/underworld3/blob/4fe6bf4e6916a6d7b392840b1a8c81780f2fe4b4/src/underworld3/discretisation.py#L193
— Reply to this email directly, view it on GitHubhttps://github.com/underworldcode/underworld3/issues/193, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADABPIYXRZ6UOV6G3KZ6CM3ZAUGUPAVCNFSM6AAAAABHG6X2MSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI3TSMJRGA2TAMQ. You are receiving this because you were mentioned.Message ID: @.***>
Not sure about the title of this issue and what we want to do about this. @julesghub and I chatted about all things to do with boundaries and there is clear scope to make this less fragile.
I suggest that we insist on a python class of some kind for boundary conditions that has any additional information that we need for our purposes in UW. Rather than mesh.boundaries.Upper.name, we just pass in the mesh.boundaries.Upper boundary to our routines.
This class could also contain boundary normals (if analytic functions are available) and UW would fall back to the PETSc ones otherwise.