Saving interval and restart interval

[nicolasdlss]

Save restart

All solver wrappers inherit a parameter save_restart from the coupled solver. This parameter is an int (positive, negative or zero). Based on the value of the parameters, the solver wrapper should have the following behaviour:

• 0 save files for restart when the time step is a multiple of save_restart

• =0 do not save any files for restart
• <0 same as '>0', but only keep latest files

In this way, the user can specify, the save interval for restart in one place only, as it does not make sense to save files for restart on different times in all solver wrappers and coupled solvers. The files for restart themselves are solver specific, but should allow a restart from that specific time step. In the coupled solver the parameter is optional, and its default value is -1 (save every time step, but only keep last). Similarly to timestep_start and delta_t, its value will be usually determined by the coupled solver, nonetheless it can also be provided to the solver wrapper itself for standalone testing. Whether or not this parameter is optional in that case, and what the default value is, is up to you.

Save results

Besides saving files for restart purposes, the user also may want to safe files for postprocessing. In a calculation with many time steps, this will typically be every so many time steps. For this reason there should be a save_interval or save_results (the name can be discussed), which allow to set this interval (int >0). In some solverwrappers, the current name is save_iterations, but this is confusing and should be changed.

The specific files which are stored for postprocessing will depend on the solver wrapper. Possibly, they they are the same files that are kept for restart, but not necessarily. Files which are not required for postprocessing should be removed.

Feel free to comment any remarks on the proposed workflow.

To do

• [x] Fluent
• [x] Abaqus
• [x] OpenFOAM
• [x] Kratos

[hdolfen]

In #108 I fixed the mistake due to which .dat files were only removed for the ModelPart with index 0.

[hdolfen]

I agree to have the value of save_restart determined by the coupled_solver (the highest level) because it has to be consistent among all components in a simulation.

As to the save_results, I like that name because it says what it does more than save_interval (and certainly more than save_iterations). In this case I'm inclined against copying its value from the coupled_solvers to the solver_wrappers, because it really depends on the solver how much data is written (e.g. Fluent case and data files can be quite big, so you may want to save those not as often as the interface data of the coupled solver). I would even make this a mandatory parameter without default value, such that one is obliged to consider the amount of data stored.

[navaneethkn]

I agree with @hdolfen on passing the value of save_restart from the coupled_solver, because the solver should be able to restart at the time step specified in the timestep_start.

Although, I agree with @hdolfen on not passing the value of save_results, because of the reason he mentioned. However, I will not make it a compulsory JSON parameter because it depends on the implementation. For example, in the case of openfoam solver wrapper, the user sets up the CFD case including the writeInterval, so it can run stand-alone. The solver wrapper reads all the parameters and modifies only the necessary parameters required for an FSI simulation e.g. delta_t, timestep_start, etc.

[nicolasdlss]

For OpenFOAM the writeInterval and purgeWrite keywords provide enough flexibility, at least with respect to saving results. However, there are also files in the folder postProcessing with traction and pressure data, which should also be deleted. This is not the case at the moment.

[awbral]

Has been done for Abaqus.

The checks for determining whether the current timestep is a multiple of either save_results and save_restart are always with respect to 0. Moreover, files from previous calculations (so at timesteps smaller than timestep_start) cannot be removed in the current calculation. As such, if errors occur in a restarted calculation, it will always be possible to start anew from the previous calculation.

EDIT: reference saves now occur with respect to global timeframe (i.e. timestep 0)

[nicolasdlss]

Closed by #181

For Kratos there is no parameter save_results, but the retainment of solution files can be controlled through the case settings (ProjectParameters.json).