Skip to content

Conversation

@mleoni-pf
Copy link
Contributor

This PR introduces two convenience functions to write CG1 and DG0 functions to VTKHDF.

/// @note Limited support for floating point types at present (no
/// complex number support).
template <std::floating_point U>
void write_CG1_function(std::string filename, const mesh::Mesh<U>& mesh,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The decision to split up into different functions depending on function space looks problematic, it will not scale. A generic write_function would be favourable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was inspired by the Python interface having separate "write point data" and "write cell data" but I realize that that's not quite the same... I agree that a generic write_function would be better but I am not knowledgeable enough on the VTKHDF format to know how to write mixed or exotic elements...
An API-saving option could be to error out for unsupported function spaces; another one, used somewhere else in the repo though unsatisfactory, could be to interpolate whatever function is passed to CG1 or DG0 before saving. What are your thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think supporting subsets of elements is fine. Good to add tests, which check for a proper assertion being raised on such invocations.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think in this case, raise an exception for unsupported function spaces.

@chrisrichardson
Copy link
Contributor

This PR makes implicit assumptions about the dofmap for P1 and DG0 functions (i.e. that they are simply the same as the geometry).
I agree with @schnellerhase that there should be a common interface, and also there should be some tests that run with MPI.

@mleoni-pf
Copy link
Contributor Author

This PR makes implicit assumptions about the dofmap for P1 and DG0 functions (i.e. that they are simply the same as the geometry). I agree with @schnellerhase that there should be a common interface, and also there should be some tests that run with MPI.

I'm interested in learning how to relax that assumption, if you can point me to whatever functions we have to map the geometry dofmap into the P1 and DG0 dofmaps.

As far as tests are concerned, I didn't know how to write a test for a writing without being able to read back but in #4027 I added a test that includes a full write-read-compare cycle.

@schnellerhase
Copy link
Contributor

Have a look at add_function in xdmf_function.cpp, in particular how data_values is constructed.

@mleoni-pf mleoni-pf force-pushed the mleoni/vtkhdf_write_cg1_dg0_function branch from a0ee385 to 222bb1e Compare December 23, 2025 13:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants