I have a configuration that I could run with dt=240s for 10 years. When I invoke the option AGRIF for nesting, the model blows up. I check the history and the issue seems to be large w in regions very far away from the child domain. I just reduced the time step and run it again, but my first question is whether CROCO and AGRIF have different numerical schemes (those handling the pressure error in Sasha’s paper 20 years ago or perhaps something else?).
Are you running AGRIF in the 1-way or 2-way case (#define AGRIF_2WAY)? In the 1-way case, the parent grid should not be affected by the child grid at all. So we would expect similar results because AGRIF would in principle only affect the code structure, and not the numerical schemes. Of course, there may be some mishandling of the code by AGRIF that we may have overlooked. But before we get into that, could you confirm whether the 1-way case has the same stability as the non-AGRIF case? Also, are you starting from the same file as for the non-AGRIF case?
Thanks for your quick response, Patrick.
The snapshot below shows the bottom w at the same time instance (it is not for Benguela though the titles say so). The left panel is on the parent domain by agrif 2-way nesting and the right panel is no nesting on the parent domain by croco. They use the same forcing and boundary files. The large bottom w are near shelf breaks and trenches (I had similar issues with w using the other version of roms with the same time step). The child domain is in the upper left corner of the parent domain, quite far (100s km) from those disturbances. I just downloaded the agrif-only code and will run it on the parent domain only. I will report back on how that run goes.
It turns out that this was just because FRC_BRY was undefined (though the code without nesting could run for 10 years even when FRC_BRY was undefined). Thanks again.