checkpointing with moving mesh free surface broken

Bug #1001273 reported by Stephan Kramer
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fluidity
In Progress
Low
Stephan Kramer

Bug Description

When moving the mesh according to the free surface, checkpointing does not work.

There are two situations:
1) the checkpointed mesh is the CoordinateMesh, then the written out gmsh or triangle mesh is moved. Fields on this and derived P2 and P1DG meshes are written out, where the coordinates in the vtu are based on a remap from "Coordinate" (which has moved) onto the derived mesh. Restarting from the checkpoint goes fine, but since fluidity interprets the input mesh as the equilibrium mesh, the FreeSurface movement will again be applied on top of the already existing displacement

2) the checkpointed mesh is another mesh, say BaseMesh (which is either the external mesh or an extruded mesh), where CoordinateMesh, VelocityMesh and PressureMesh are derived directly from BaseMesh. In this case the checkpointed mesh has its own coordinate field BaseMeshCoordinate, which hasn't moved at all. The checkpointed mesh therefore is unmoved. For the checkpointing of the fields on CoordinateMesh, PressureMesh or VelocityMesh however "Coordinate" will be used, resulting in a moved mesh vtu. This causes fluidity to refuse to start from the checkpoint as it checks whether the mesh in state is the same as that in the vtu (this check was added to catch all sorts of reordering issues we previously had with checkpointing).

I think the solution is to never checkpoint the moved mesh, but always use the original coordinates. So when checkpointing the CoordinateMesh (case 1)) it should use "OriginalCoordinate" and when creating the checkpoint field vtus it should use coordinate field remapped from "OriginalCoordinate". The restart run then starts from the original mesh and applies the movement according to the checkpointed FreeSurface values right at the beginning.

This of course would only fix mesh movement with free surface. For other mesh movement cases it might be that the moved mesh is actually information that needs to be retained. I will therefore add a warning that this is untested and likely broken functionality.

Related branches

Changed in fluidity:
status: New → In Progress
assignee: nobody → Stephan Kramer (s-kramer)
Jon Hill (jon-hill)
Changed in fluidity:
importance: Undecided → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.