search

LLNL / axom

CS infrastructure components for HPC applications
BSD 3-Clause "New" or "Revised" License
150 stars 27 forks source link

Higher dimensions (for Space-time meshes?) #171

Open pguthrey opened 4 years ago

pguthrey commented 4 years ago

Are there plans for Mint to support 4D meshes?

gzagaris commented 4 years ago

@pguthrey , this hasn't really come up. I actually don't know of any codes that do Space-Time DG beyond 1D (i.e., 2D Space-Time) and 2D (i.e., 3D Space-Time). But, I am happy to hear ideas.

One way to support this in the present implementation is to store your coordinates as a node-centered vector Field, to which, you can specify the number of components N, or have multiple scalar, node-centered fields, each corresponding to a dimension.

pguthrey commented 4 years ago

One speculative thought I had about our own meshes was if vertices were "extended vertically" in time. For example, when you have 2D triangles in space, the space-time mesh could be triangular prisms. That way, one could avoid the headache of thinking about 4D tetrahedrons.

gzagaris commented 4 years ago

One speculative thought I had about our own meshes was if vertices were "extended vertically" in time. For example, when you have 2D triangles in space, the space-time mesh could be triangular prisms. That way, one could avoid the headache of thinking about 4D tetrahedrons.

Yes, I understand that. I think in this case, you'd want to keep:

  1. An instance of the 3D space-time mesh to which you keep appending to it prisms, or other space-time elements as well as,

  2. A snapshot of the evolving surface mesh as it is advancing, i.e., the advancing front, at which you extrude from and add new prisms.

I can show you how to do that.

I do have a hard time thinking about this though when you have a 3D space mesh (e.g., with tets) and you want to extrude elements in time.