Up to Specific issues in real coupled models
I use coupled model NEMO+OASIS+WRF for a long-term modelling. I want to restart modelling from a specific time. Do I need any restart files for OASIS? I know that OASIS uses sstoc_d01_d01.nc and flxat_Ad01_to_Od01.nc files to exchange data between NEMO and WRF. Do I have to change fields in these files somehow (for example, to replace SST field in sstoc_d01_d01.nc with SST field from NEMO restart file)?
Hello, We can help you use the OASIS coupler but we will not decide in your place the simulation you want to produce! If you have a LAG specified in your namcouple for one of your coupling field, you will need a coupling restart file, so that the OASIS library attached to the source component can read the coupling field on the source grid and send it to the target model to fulfil its oasis_get at time 0 (see section2.5.3 of the User Guide). So yes, if you restart from another time, you should change your restart fields in your coupling restart file; these fields should be what you want your atmosphere model see as boundary conditions for the first coupling period. I hope this helps, Sophie
Hello everybody, I also use a coupled system NEMO-OASIS-WRF for a short term simualtion. This is also a key point for me. I have LAG specifies for both model equal to each model's time step (I am not completely sure this is necessary to be specified in both component, can you confirm me) Regarding the restart file for OASIS, what I do (after rreading the Users Guide) is to set T in the NNOREST section in order to force OASIS to start initializing to 0 the exchanged variables, run the coupled model for only 3 hours in order to have the restart file written at the end of the simulation. Then I set NNOREST to F and OASIS will use the restart file written at the time +3h. I understand this is just a shortcut becasue the error when starting the first coupled run from a zero initialization is not completely removed in just 3h run, it is a compromise if one cannot produce adequate IC/restart for OASIS. Bests Francesco
Hi Francesco, You need a LAG to be specified if you want an oasis_put performed at some time to match an oasis_get at a later time. Usually in the codes, the oasis_get is called at the beginning of the timestep (with the time at the begging of the timestep as argument) and the oasis_put is called at the en of the timestep (but still with the time at the beginning of the timestep as argument. In that case, if you want the last oasis_put of a coupling period in the source code to match the first oasis_get of the next coupling period in the target code, you need to specify a LAG. This will also ensure, as I wrote above, that the OASIS library attached to the source component reads (in the restart file during the coupling initialisation) the coupling field on the source grid and send it to the target model to fulfil its oasis_get at time 0 . You can do as you describe to create the first coupling restart files, as you wrote it is a compromise. But you could be more exact and create the coupling restart files "by hand" putting in those files the fields that you would like the models to see as boundary conditions during the first coupling period. For example, if the SST is a coupling field from the ocean to the atmosphere, you can put in the restart file the SST corresponding to the ocean restart state. Let me know if I am not clear, Sophie
Hi Sophie, thank you for your exaustive reply. I have a positive LAG specifies both for WRF and NEMO, both eqaul to each model's time step, that is 180s for NEMO and 20s for WRF. Yes, I know I can be more precise in creating the restart for OASIS. For the SST there is no problem because I can easily take from an uncopupled ocena run. For the fluxes unfortunately I do not have any previous uncoupled atmospheric run to them from. I tried to be more precise with a trick. I run a coupled simulation for 1 hour, starting without restart files for Oasis, decrasing the NEMO time step to 30s, and coupling frequency 120s. I can see in the exchanged fields that after few coupling time step the fluxes are stable, so I can use the restart written at the end of this short run, as initial condition for Oasis at the t=0. By the way, maybe I am missing something, but I see that at the end of the run Oasis is overwriting the restart file. Is there the possibility ot read and write the restart fields from different files? Thank you Francesco
Hi Francesco, I see you are perfectly mastering what you are doing, which I think is fine. I think any "trick" is fine as long as you then use the restart files created to first do at least a short spin-up run. Yes the restart files are overwritten at the end of the run and no the restart files used to read the field at the beginning of the run cannot have a different name from the ones used to write the field at the end of the run. (So if you want to restart from the newly created restart files, you have to copy them in your new working directory.I agree this can be problematic.) I will open a ticket on this. Regards, Sophie
Thank you very much for the reply. I just want to make sure. For example, the end of the run is 01 January 2010. If I want to restart the run from 01 January 2010, I need to use sstoc_d01_d01.nc and flxat_Ad01_to_Od01.nc files created by OASIS at the end of the previous run (e.g. at 01 January 2010). Am I correct?
