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

Document binary incompatibility of the Triangulation post 9.2 #10447

Closed
agrayver opened this issue Jun 2, 2020 · 6 comments · Fixed by #10450
Closed

Document binary incompatibility of the Triangulation post 9.2 #10447

agrayver opened this issue Jun 2, 2020 · 6 comments · Fixed by #10450

Comments

@agrayver
Copy link
Contributor

agrayver commented Jun 2, 2020

The changes done in #10326 led to binary incompatibility of the serialized triangulations.

This concerns both triangulations saved via tria.save as well as those saved by using GridOut::write_vtu (with the GridOutFlags::Vtu::serialize_triangulation flag).

Should be this be properly documented by adding an incompatibility item?

I've just hit this issue and it took me two hours to understand the issue...

@agrayver agrayver changed the title Document binary incompatibility ofthe Triangulation Document binary incompatibility of the Triangulation post 9.2 Jun 2, 2020
@bangerth
Copy link
Member

bangerth commented Jun 2, 2020

Yes, I think that is legitimate. In reality, this is by far not the first time this has happened, and we don't think that there should ever be an expectation that you can read anything that was serialized with anything other than the exact version you saved it with. But we should probably be clearer about that.

@peterrum -- FYI.

@agrayver
Copy link
Contributor Author

agrayver commented Jun 2, 2020

Well, apart from my personal frustration from debugging this, there is a positive side -- new triangulations became lighter and faster to read :)

@peterrum
Copy link
Member

peterrum commented Jun 2, 2020

I can write an incompatibility entry tomorrow! But, for me the binary output should be readable by the same program version (as normally done during restart). Everything else would prevent adding new features (or at least would make it very difficult).

@peterrum
Copy link
Member

peterrum commented Jun 2, 2020

Well, apart from my personal frustration from debugging this,

I can understand that. Sorry about this!

there is a positive side -- new triangulations became lighter and faster to read :)

Is that actually noticeable!?

@agrayver
Copy link
Contributor Author

agrayver commented Jun 2, 2020

we don't think that there should ever be an expectation that you can read anything that was serialized with anything other than the exact version you saved it with

If only I knew about this expectation! ;)

Anyway, this is minor, but it could be easily handled through the boost::serialization versioning mechanism. In the end, there is no other mechanism to save a deal.II triangulation for a later use than serialize it. Versioning this "file format" would not harm.

@bangerth
Copy link
Member

bangerth commented Jun 2, 2020

I'm not sure it is practical to read older formats of a triangulation. But it is definitely reasonable that we just write out a version number and throw an exception of the file we're trying to read is from an older version.

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 a pull request may close this issue.

3 participants