Skip to content
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

Merged
merged 1 commit into from Oct 17, 2017

Conversation

gassmoeller
Copy link
Member

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.

@tjhei
Copy link
Member

tjhei commented Oct 19, 2017

(sorry, late to the party) How does the filtering behave if you output other discontinuous data (stress, errors, topography, DG pressure, etc.)?

@gassmoeller
Copy link
Member Author

Same problem. Should we disable it unconditionally? Or make it an input parameter (for people who want to save disk space)?

@bangerth
Copy link
Contributor

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.

@bangerth
Copy link
Contributor

(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.)

@gassmoeller
Copy link
Member Author

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 😄 ).

@bangerth
Copy link
Contributor

Fair enough :-)

@tjhei
Copy link
Member

tjhei commented Oct 19, 2017

I think an option with default = false (independent of FE choice) is the best approach if you care about it.

@gassmoeller
Copy link
Member Author

I just read your comment @tjhei 😄, see #1959

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.

None yet

3 participants