I’d like to initialise a nested configuration (OCE ICE) with restarts from a global configuration at the same resolution as the parent grid. Is there any advice on how to do this in NEMO 4.2.2 (or NEMO5)?
As far as I understood, the nesting tools are no longer fully compatible with the DOMAINcfg tool and will become obsolete anyway, so I wanted to use ln_init_chfrpar = .true. (which works perfectly fine for initialisation from rest and given hydrography) and only provide restarts for the parent grid.
I tried several ways, of treating the restarts, all of which either didn’t work at all or caused crashes within a few time steps.
The crashes appear with overshooting velocities at depth and locations where in the nested configuration bathymetry is deeper and more wet grid cells exist compared to the un-nested configuration. Among other attempts, I also tried to overcome this by extrapolating the restart fields into the sea-bed, however this didn’t solve the problem either.
My ultimate goal is to use restarts of a configuration with only one nest to initialize a configuration with a secondary nest embedded in the first child.
I encountered this issue myself with my double-nested configuration, and ultimately I ended up starting the model from rest. I discussed the issue with a few people at Drakkar, and the best suggestion I have at the moment is that you could try performing a short run from rest to create a set of restarts, and then try to merge/replace the data in them with valid data from the configuration you want to start from.
It is a nontrivial problem because of the bathymetry changes made to the parent model when introducing a nest, and for the new nest starting from a parent domain restart file is tricky because it is likely that some extrapolation will be required where coastal regions differ from the parent.
We should explore and find/document a good solution for this because I expect it will be an issue more and more people encounter.
thank you so much for your message.
Starting from rest, is what I’m doing for my current tests as well. But for a full simulation, we’d like to have a decent large scale circulation without too much spin-up involved anymore.
Thank you also for your thoughs, and in particular for the idea of merging restarts from the two configuration. I gave that a first try today and the first test looks promising - at least the simulation gets further than before.
I’ll dig deeper into that and try to get it running for the double-nested configuration and will let you and the community know in case this leads to a solution.
Related to potential problems with initialization, in particular in the case of hot starting with non zero velocities.
With ln_rstart=T, it is assumed that velocities are masked (e.g. are 0) where they should be with respect to the input grid. This is not ensured in the code since the ln_rstart has been historically designed for continuous integrations hence not “hot starting” from potentially drowned fields. I’ve just found that having unmasked velocities is particularly problematic with RK3 because the way advective velocities are updated is different from the MLF case. The latter makes us of masking while the former does not. As a consequence, volume conservation is wrong and so is vertical velocity at the first time step leading to model blow up.
Some guidelines when “hot starting” with RK3:
Remove from restarts the following barotropic fields if they exist, e.g. uu_n, sshbb_e (actually only tn, sn, un, vn and sshn are required).
Add a couple of lines in restart.F90 file here such as:
DO jk = 1, jpk
uu(:,:,jk,Kbb) = uu(:,:,jk,Kbb) * umask(:,:,jk)
vv(:,:,jk,Kbb) = vv(:,:,jk,Kbb) * vmask(:,:,jk)
END DO