You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As part of a recent discussion with @pazner on the mfem slack channel, it sounds like there may be a handful of limitations of periodic meshes in mfem that do not seem to be currently communicated in https://mfem.org/howto/periodic-boundaries/ . Concretely, if the mechanism of enforcing periodicity in mfem is just a 1-to-1 correspondence between nodes on periodic faces then it may not work correctly in general for:
vector-valued H1 spaces (e.g. rotational symmetry like in the torus example on the web page)
Hcurl (due to sign / orientation discrepancies, especially with triangular faces of cubic or higher order in 3D)
Hdiv (due to sign)
I'm hoping to find out more information on the potential limitations above (the signedness problem for Hcurl/Hdiv could likely be resolved easily if not already, but the orientation mismatch might be more involved). Has anyone successfully simulated elasticity or E&M problems with periodic meshes, especially with more interesting symmetries than just translation?
Also, the webpage does not indicate if the discretization is expected to be conforming along the periodic boundaries (I'm guessing this is a requirement, given the discussion above). If so, does this impose restrictions on mesh refinement (adaptive, uniform)?
The text was updated successfully, but these errors were encountered:
I agree with Tzanio that examples could help to clarify and/or confirm this functionality.
Regarding HCurl and HDiv there should be no issues on periodic meshes regardless of how the opposing surfaces are oriented as long as there is a one-to-one correspondence between the nodes. This is because once these opposing surfaces are stitched together their orientations are irrelevant. Only the topology of the resulting mesh is relevant in defining the basis functions. As long as the mesh was stitched with valid topology everything else should be fine.
Vector H1 is another matter. The same argument used above applies here and leads to valid basis functions. However, trouble can arise in how the vector components are interpreted. Clearly if they are thought of as xyz components of some vector field and the opposing surfaces are not simply translated then the xyz interpretation will produce strange results throughout the mesh not just where the opposing surfaces were stitched together. On the other hand if the resulting mesh is a portion of an object with cylindrical symmetry, for example, and the three vector components are interpreted as r, phi, and z in this cylindrical coordinate system then vector H1 should produce perfectly results.
After read the discussion on the MFEM #helpdesk the source of confusion is more clear to me. This matter certainly needs better documentation. I'll try to put something together when I get back from my current trek.
As part of a recent discussion with @pazner on the mfem slack channel, it sounds like there may be a handful of limitations of periodic meshes in mfem that do not seem to be currently communicated in https://mfem.org/howto/periodic-boundaries/ . Concretely, if the mechanism of enforcing periodicity in mfem is just a 1-to-1 correspondence between nodes on periodic faces then it may not work correctly in general for:
I'm hoping to find out more information on the potential limitations above (the signedness problem for Hcurl/Hdiv could likely be resolved easily if not already, but the orientation mismatch might be more involved). Has anyone successfully simulated elasticity or E&M problems with periodic meshes, especially with more interesting symmetries than just translation?
Also, the webpage does not indicate if the discretization is expected to be conforming along the periodic boundaries (I'm guessing this is a requirement, given the discussion above). If so, does this impose restrictions on mesh refinement (adaptive, uniform)?
The text was updated successfully, but these errors were encountered: