Up to Specific issues in real coupled models
Good afternoon,
I am trying to generate a series of restart files at various resolutions for OpenIFS-FESOM2 coupled with OASIS3MCT. For this purpose I start a short run with Lag=0 on all components.
The the namcouple looks for example like this:
############################################
$NFIELDS
18
$END
$NBMODEL
3 fesom oifs rnfma
$END
$RUNTIME
86400
$END
$NLOGPRT
1
$END
$STRINGS
#############################################
sst_feom A_SST 1 10800 2 rstos.nc EXPOUT
126858 1 35718 1 feom L080 LAG=0
P 2 P 0
LOCTRANS SCRIPR
AVERAGE
GAUSWGT U SCALAR LATITUDE 1 9 2.0
#############################################
The restart files that are generated contain variables that have the prefix loc{0000xx}_{var_name}. The ocean restart file ends like looking like this: cdo pardes rstos.nc -1 loc000014_cnt -2 loc000014_sst_feom -3 loc000017_cnt -4 loc000017_sit_feom -5 loc000016_cnt -6 loc000016_sie_feom -7 loc000018_cnt -8 loc000018_snt_feom -9 loc000015_cnt -10 loc000015_sia_feom It should look like this: cdo pardes rstos.nc -1 sst_feom -2 sit_feom -3 sie_feom -4 snt_feom -5 sia_feom
The resulting rstos.nc files can not be used to start the model with lag in the next run, since oasis tries to read from e.g. sst_feom rather than loc000014_sst_feom. Do you know what causes this behaviour and how to remedy it?
Best regards, Jan Streffing (AWI)
Hi Jan,
The fields loc{0000xx}_{var_name} that you see in the restart files are the restart fields corresponding to the LOCTRANS operation (see the forum discussion https://www.cerfacs.fr/site-oasis/forum/oa_main.php?c=113).
By the way you will not generate any restart files for your models, with restart fields in them if you put a LAG=0 in your namcouple.
I did a test with a simple toy model. I used the file areas.nc to create a restart file for a field equivalent to sst_feom. I put at 0.0 the field in the restart file. I put a LAG for the field equal to the time step of the model. The restart file is correctly read at t=0, and automatically written at the end of the run with the new restart field and the restart field corresponding to the LOCTRANS operation.
You should then be able to do the same and use this new restart file to run your simulations (still putting a LAG in your namcouple).
Let me know if this helps,
Best regards, Laure
Hello Laure, Thank you for the infos. We are not generating areas.nc files for our unstructured mesh ocean model yet. Thus for conservation was done by computing net fluxes in each model and sending correction terms directly across. While I admit that this is not the proper way to do things, fixing it is not high on the list of tasks. So for now I have no areas.nc I had a quick chat with my colleague Dirk Barbi and he confirmed to me that LAG=0 for the initial run is how he has been generating new restart files for years. He is using an older OASIS3MCT version same as MPI-ESM from ~5years ago and I use a newer version the same one as in EC-Earth ~1 year ago. I did actually create a set of restart files the way I described for one combination of grids. So this was working for me ~6 months ago. Are you sure that's not the way to create restart files? Best regards, Jan
Hi Jan,
First of all, it is not necessary to have the fields loc{0000xx}_{var_name} in your first restart file, and you can have a coupling field at 0 in the first restart file.
1- To generate restart files created by OASIS for the coupling fields, the only way is to run with a LAG > 0 defined in the namcouple, equal to the time step of the model. But in this case you need a restart file at t=0 that is read by the model (even if it has 0 values in it for the coupling field) and the model writes a restart file at the end of the run, with the coupling restart fields and eventually the LOCTRANS restart fields in it. Then you can use the written restart file for your simulations. In your case where LAG=0 and where you have LOCTRANS operations, you only have the restart fields of the LOCTRANS operations in the restart files written by OASIS so you can not use them afterwards for your simulations.
2- In the last version of OASIS3-MCT, OASIS3-MCT_4.0, you have an additional optional argument write_restart in the API oasis_put to write an intermediate restart file associated with the variable var_id at the current coupling timestep (see the User Guide https://oasis.cerfacs.fr/wp-content/uploads/sites/114/2021/02/GLOBC_TR_oasis3mct_UserGuide_4.0.pdf, section 2.2.7).
3- If Dirk was using LAG=0 to generate his restart files, they were not generated by OASIS. Maybe he used the debug files created by OASIS to create his restart files ? Using the option EXPOUT in the namcouple, the coupling fields are stored at each coupling step in a file of type ${name_of_coupling_field}_${model}_${number}.nc. Do you do the same to create your restart files ? Else how do you do ?
4- Another way to create realistic restart files would be to rename the fields loc{0000xx}_{var_name} into your coupling fields in the restart files you get with LAG=0, and then run again the model with a LAG>0 to get restart files with coupling fields (and also loctrans restart fields) at the end of the run that you could use for your simulations.
Let me know if it is clear,
Best regards, Laure
Few precisions to (hopefully) clarify few details:
-in the OASIS restart files, you can find coupling restart fields and LOCTRANS restart fields (of the form loc{0000xx}_{var_name}). LOCTRANS restart fields are completely managed by OASIS, just don’t need them in your initial restart file. Coupling restart fields are also managed by OASIS3-MCT but if you have a LAG>0, you need to create an initial restart file with initial coupling restart fields in it (as you know).
-the way OASIS manages coupling restart fields in its restart files has not changed since more than 5 years, so whatever Dirk was doing 5 years ago should still work for you. But, as Laure wrote it, it cannot be that restart files were generated by OASIS in a run with LAG=0, even 5 years ago.
-ideally, the coupling restart fields should contain the values of the physical coupling fields at initial time. For example if SST is a coupling field, the coupling restart file should contain the SST value that should be seen by the atmosphere during the first coupling period. If it is too difficult, for any reason, to put the real initial coupling fields in the restart files, you can use any “trick” described above by Laure to generate them, or what Dirk was obviously doing if you think this is physically justified. Starting with initial coupling restart fields = 0, running a first run with LAG>0, and then using the coupling restart files produced by OASIS at the end of the run would be kind of a spin-up procedure for producing the restart coupling fields.
I hope this helps, Sophie
Thank you both for the detailed explanation, I will send the link of our communication to Dirk. I understand the difference in LOCTRANS and normal restart fields.
Finally I went with the following solution: I use EXPOUT for the first simulation leg and do:
cdo merge {EXPOUT_OCEAN_FIELDS} tmp ncwa -a time tmp rstos
Once again, thank you for for the swift support.
Best regards & have a nice weekend, Jan Streffing