Separate input output

[sebastianbeyer]

Separating the inputs from the outputs. This should enable us to have more 'predictable' runs, in that running with the same inputs and the same config/namelists should lead to the same results.
We can save time because we do not need to wait during backuping the restart files (this is the main motivation in DestinE project). Still this is done so that the old default behavior is not changed.

It introduces a new namelist option RestartPath that by default is set to the string same-as-result. if that is the case, it will be set to the same value as ResultPath, so the default behavior is not changed.

I also want a separate namelist option for RestartOutPath or similar, so that the restarts can be completely uncoupled from the outputs.

So far, I have only tested raw restarts.

[sebastianbeyer]

Some questions:

1. What about mesh.diag.nc and oce.blowup.nc? should it keep going to ResultPath?
2. would it be helpful to encode the current date of the restarts in the file- or path name, same as for the netcdf restarts? It would then be possible to have a common restart directory for a whole run and the particular restarts for one chunk would be selected by the clock file.

[JanStreffing]

I think oce.blowup.nc can stay where it is and named as is. Should the last timestep always, which will be clear from logfile.

For mesh.diag.nc I can imagine a use case in the future with a moving cavity between restarts where time coding it might make sense. However, changing its name might break a few postprocessing scripts initially, which are relying on this file for mesh info.

[sebastianbeyer]

Ah, I meant the time coding for the raw and bin restart files, not mesh.diag or blowup.
but I thought again and that will pose a problem when the clock file is also in the RestartOutPath and we want to retrieve the folder to use to restart from there we get a chicken egg problem ;)
Would like to get rid of the clock file in general, btw…

[sebastianbeyer]

What would be your preference with the clock file(s)? keep it in one central place (ResultPath or working directory (where namelist files are) )? so it will be always updated with the current date? I think that is how they were intended, but that does not go too well with the idea of 'same config does always produce same runs'... it contains state that somehow needs to be managed.