Checkpointing with matching time windows

[davidscn]

We have oftentimes the case that we reload the checkpoint after a single time step was computed (we have matching time windows in an implicit coupling). In the current implementation of the adapter and the way we handle the checkpointing, we copy all fields and reload them later

openfoam-adapter/Adapter.C

Lines 858 to 882 in 17d1776

	#undef doLocalCode
	#define doLocalCode(GeomField) \
	/* Checkpoint registered GeomField objects */ \
	for (const word& obj : mesh_.sortedNames<GeomField>()) \
	{ \
	addCheckpointField(mesh_.thisDb().getObjectPtr<GeomField>(obj)); \
	DEBUG(adapterInfo("Checkpoint " + obj + " : " #GeomField)); \
	}
	doLocalCode(volScalarField);
	doLocalCode(volVectorField);
	doLocalCode(volTensorField);
	doLocalCode(volSymmTensorField);
	doLocalCode(surfaceScalarField);
	doLocalCode(surfaceVectorField);
	doLocalCode(surfaceTensorField);
	doLocalCode(pointScalarField);
	doLocalCode(pointVectorField);
	doLocalCode(pointTensorField);
	// NOTE: Add here other object types to checkpoint, if needed.
	#undef doLocalCode

This might be somewhat wasteful in case OpenFOAM stores fields of the previous time step automatically. If it does, we could access these 'old' fields (of t_n-1) in order to reload the checkpoint (t_n -> t_n-1) instead of storing both snapshots explicitly (t_n and t_n-1) and reloading them later on (would need to reload the old fields, though). This could save us a considerable amount of memory (namely all global fields at least once).

However, I don't know, if the OpenFOAM fields at t_n-1 are stored and which we need to reload at all.

Extracted from #209 (comment).

[MakisH]

We have oftentimes the case that we reload the checkpoint after a single time step was computed (we have matching time windows in an implicit coupling).

I assume you refer here to the case of no subcycling. We don't always need to have solver_dt = precice_dt in implicit coupling and the solver may do multiple time steps in one coupling time window.

How would you imagine this in terms of configuration? I guess we cannot really extract this information automatically, since OpenFOAM is allowed to arbitrarily update its time step size (and the user is allowed to update it at runtime).

[davidscn]

How would you imagine this in terms of configuration? I guess we cannot really extract this information automatically, since OpenFOAM is allowed to arbitrarily update its time step size (and the user is allowed to update it at runtime).

Variable time step sizes as well as run time modifications can be disabled in the configuration file.

[MakisH]

Variable time step sizes as well as run time modifications can be disabled in the configuration file.

Of course, but then do you mean that we should make it "if solver_dt == precice_dt and disabled runtime modifications and disabled dynamic timestep size, then use the alternative mechanism"? We would then probably need to ensure that the precice_dt we are comparing with is the maximum one (e.g., we can compare during initialization).

[davidscn]

Actually, I did thought about configuring this yet. Let's first see if there is anything we can improve on before bothering with the details.