New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Only filter hdf5 output for continuous elements #1958
Conversation
(sorry, late to the party) How does the filtering behave if you output other discontinuous data (stress, errors, topography, DG pressure, etc.)? |
Same problem. Should we disable it unconditionally? Or make it an input parameter (for people who want to save disk space)? |
I kept a tab open in my eclipse to remind myself that I wanted to add a warning that users should only do the filtering if their data is continuous. Anything else clearly will lead to incorrect output. We never did the filtering for VTU precisely because of the risk of doing something stupid, and because it's so difficult to find bugs if your visual output does not match the actual solution. I wouldn't mind if we ended up removing the filtering altogether -- who cares about a few extra MB or GB of disk space these days. |
(But if we end up doing that, I'd still be interested in getting this PR merged so we can go back to it if necessary.) |
I would like to keep the filtering as an option. Because we might not be talking about a few MB or GB, but several TB for some of us (although I have to admit for all my large scale models I used vtu so far, but I am also carrying around 10 TB of data right now, so I might need to start using this functionality 😄 ). |
Fair enough :-) |
I think an option with default = false (independent of FE choice) is the best approach if you care about it. |
Something I noticed while working on #1864.
The hdf5 filter tries to merge duplicate vertices at the same location to reduce the necessary disk space. However, for discontinuous elements this means averaging the values at the element boundary, something that is often not intended. Even worse: The merge does not always work, because the check in deal II does not take into account floating point imprecision in the vertex position, I am opening a separate issue for that. The consequence is that during mesh refinement, even if the mesh does not change and the solution stays the same, the internal position of the vertices can be changed slighty, and the filter will create a different output field, suggesting a change that does not exist. This behavior is not a problem for continuous elements (whether we average the constant values at adjacent vertices or not does not matter), but it is a problem for discontinuous solutions. Thus, this PR disables the filtering for discontinuous solutions.