Open jeff-cohere opened 2 years ago
I think we can optimize geometry so it's faster than reading a file. (And this should be done in PETSc.) If it's still an issue, what is a current representative example?
@jedbrown These functions were written before your fix to PETSc in https://gitlab.com/petsc/petsc/-/merge_requests/4273. I need to evaluate if reading geometry is still an issue with the latest PETSc.
@jeff-cohere We should introduce these functions back because they are helpful in debugging the code.
Sounds good. Maybe we can discuss this sometime soon. It would help me to understand when/where you're using them, and what you're using them for.
@knepley , here's where we've started talking about writing/reading mesh geometry files. I'd really like it if we could write out HDF5 geometry files and develop some simple tools for manipulating them, and/or visualize them with existing software.
@jeff-cohere So the way I would start is to do the cellwise stuff in an HDF5 way. You can make a P0 element easily with PetscFECreateLagrange(), and set it into a cloned DM. Then the local/global vectors will be what we want, and you should be able to just do VecView(), if you change the name of the cloned DM, say "diagnostic", so that it is put in a parallel dir in the HDF5 file.
@bishtgautam , what would you like in this file? Cell centroids and volumes, face normals and areas, node coordinates? Anything else?
215 discarded these mesh geometry reading and writing functions, because the assumptions they were written under changed as a result of the work in that PR:
If I understand things correctly, @bishtgautam introduced these functions to save time on calculating mesh geometry for debugging. Maybe it's time for us to optimize the geometry calculations so we don't need these functions anymore. But if that's not practical, we can try to rewrite these functions so they work in the post-215 world.