P4estMesh constructor for HOHQMesh Abaqus-type file #945
Conversation
Codecov Report
@@ Coverage Diff @@
## main #945 +/- ##
==========================================
+ Coverage 93.71% 93.79% +0.08%
==========================================
Files 281 284 +3
Lines 20376 20615 +239
==========================================
+ Hits 19094 19335 +241
+ Misses 1282 1280 -2
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Well done! I'm looking forward to seeing some crazy 3D meshes.
I left some comments, but I'm not really understanding most of the parsing properly. If this is clear to other reviewers, please just ignore my comment there. Maybe I just have to look into this a bit more, then.
Is anything of this done yet? |
There was a problem hiding this comment.
Great work, @andrewwinters5000 👍 Please find below some comments.
Co-authored-by: Hendrik Ranocha <[email protected]>
Yes, I forgot to check the box for the 2D implementation |
Co-authored-by: Hendrik Ranocha <[email protected]>
…ings and comments accordingly
src/meshes/p4est_mesh.jl
Outdated
| Increasing the `initial_refinement_level` allows one to uniformly refine the base mesh given | ||
| in the `meshfile` to create a forest with more trees before the simulation begins. | ||
| For example, if a two-dimensional base mesh contains 25 elements then setting | ||
| `initial_refinement_level=1` creates an initial forest of 4*25 = 100 trees. | ||
|
|
||
| # Arguments | ||
| - `meshfile::String`: an uncurved Abaqus mesh file that can be imported by p4est. |
There was a problem hiding this comment.
Right now, the mapping is only used if the file doesn't have a HOHQMesh header. This should be documented.
OTOH, would it make sense to allow mapping a curved HOHQMesh mesh? Then we could just apply the mapping after reading in the mesh, no matter if it's a curved or uncurved mesh file.
There was a problem hiding this comment.
This might be possible but I am not sure if it is necessary. I cannot think of an application where we would need this functionality. For instance, it seems strange to me that you would read in a mesh with curved physical boundaries (say an airfoil) and then have it be mapped to something else.
There was a problem hiding this comment.
@andrewwinters5000 Just FYI: I now came across an example where this is actually useful. You may want to stretch a grid smoothly towards an area where you want a higher resolution. With a spherical mesh, for example.
|
figure for the new mesh docs
|
examples/p4est_3d_dgsem/elixir_euler_source_terms_nonperiodic_hohqmesh.jl
Outdated
Show resolved
Hide resolved
| @@ -10,7 +10,7 @@ function init_elements!(elements, mesh::P4estMesh{3}, basis::LobattoLegendreBasi | |||
| @unpack node_coordinates, jacobian_matrix, | |||
| contravariant_vectors, inverse_jacobian = elements | |||
|
|
|||
| calc_node_coordinates!(node_coordinates, mesh, basis.nodes) | |||
| calc_node_coordinates!(node_coordinates, mesh, basis) | |||
There was a problem hiding this comment.
I think we call some calc_node_coordinates! from Trixi.jl in Trixi2Vtk.jl, e.g., https://github.com/trixi-framework/Trixi2Vtk.jl/blob/16057193f5ea4b3b1b9e5cbe8d4962e2e16e1c31/src/vtktools.jl#L186. Does this interfere with this change?
CC @efaulhaber
There was a problem hiding this comment.
Aha, gotcha. I noticed that the routine below the constructor with the @ assert about the two polydegs was never entered. That is, it was possible to run with mesh_polydeg > solver_polydeg.
Co-authored-by: Hendrik Ranocha <[email protected]> Co-authored-by: Michael Schlottke-Lakemper <[email protected]>
…inear_interpolant
…new constructor routines
…uired updates to the free-stream tests due to roundoff differences
andrewwinters5000
dismissed stale reviews from sloede and ranocha
via
8d9c7ba
This adds the capability to parse a HOHQMesh file, its high-order boundary information and names to set boundary conditions into the
P4estMesh. Related to the new HOHQMesh file type developed in this PR on the HOHQMesh generator.(possibly for a different PR because this will require some new 3D transfinite interpolation routines)