OMEGA_IMPLICIT in estuaries

[stlaur]

If you run ROMS domains that have realistic bathymetry, resolution <=500m, tides, and your timestep is dictated by Cw, you might want to give OMEGA_IMPLICIT a try (Shchepetkin 2015 https://doi.org/10.1016/j.ocemod.2015.03.006). It's available inside the feature/kernel branch. In our case, the benefits outweighted the trouble of switching to feature/kernel. Pierre

[arango]

Hi Pierre, I am glad to hear that. I must return to that branch and check what I need to do to merge it into the develop branch. In the ROMS GitHub version, we can switch branches in the build script very quickly by the command:

Code: Select all

build_roms.sh -j 10 -b feature/kernel

It creates the src subdirectory in your project directory containing the code for the specific branch. We always recommend that users update the cloned copy of the ROMS code.

[stlaur]

I wanted to update my earlier post and mention that OMEGA_IMPLICIT (Shchepetkin 2015) is now directly available in the standard/official branch ("develop").

[pmaccc]

Pierre, Thanks for pointing this out. I will try it.
Question: how do you determine that your time step is limited by Cw? I must confess that even after years of using ROMS I still have very limited understanding of exactly what causes my models to blowup.
Thanks, Parker

[stlaur]

The Courant numbers (Cu, Cv, Cw) are reported at every timestep in the standard output:

Code: Select all

 TIME-STEP YYYY-MM-DD hh:mm:ss.ss  KINETIC_ENRG   POTEN_ENRG    TOTAL_ENRG    NET_VOLUME
                     C => (i,j,k)       Cu            Cv            Cw         Max Speed

The 2015 paper discusses Cw and the hybrid explicit/implicit fix for cases when it becomes high.

[pmaccc]

Pierre, thanks for pointing out this Courant number part of the log file.
Question: What does the (i,j,k) refer to? I assume it is the indices of one of the Courant numbers, but which of the three?

Also, I am rerunning a model using OMEGA_IMPLICIT and it appears to have fixed some blowup issues. I believe the new version (develop) also includes some bug fixes in advection/turbulence that Ramsey Harcourt pointed out, and these may also be helping.

Cheers, Parker

[stlaur]

The relevant code is in Nonlinear/diag.F, but I believe it is the (i,j,k) for which the sum of the three (i.e. Cu+Cv+Cw) is greatest.

[arango]

The (i,j,k) are the 3D state array indices of where the maximum value of the velocities occurs. It is an indication of possible trouble spots if the model blows up. In our experience, ROMS typically fails due to vertical CFL violations in shallow regions with extremely thin vertical level thicknesses. The OMEGA_IMPLICIT helps in those situations. Also, with OMEGA_IMPLICIT, we can try a larger time step. If the (i,j,k) is near the grid's open boundaries, it can indicate that we need to be concerned about a possible trouble spot due to lateral boundary conditions. Thus, it is a handy diagnostic value.

[pmaccc]

I am having a blowup problem that I have been unable to diagnose or fix in the usual ways. It is during a day about a year into a long hindcast. I am using ROMS version 4.3. On this particular day the model blew up at the same hour, regardless of how small I made the timestep. Nothing looked amiss in the last good saved history file, but the Cw was large, around 20, at a place where one of the largest rivers enters the system. I am using OMEGA_IMPLICIT and I believe this version has the bug fixes in the turbulence closure that were suggested by Ramsey Harcourt. A key piece of evidence is that a very similar model using ROMS version 4.2 did NOT blow up at all on this day (no OMEGA_IMPLICIT and no new fixes to the turbulence closure). There were a few other changes to model forcing, but swapping them out for the previous versions, and running with OMEGA_IMPLICIT undefined made no difference at all - the model still blew up at the same hour.

So, I have no idea what the problem is. Any help would be much appreciated. If there is more information I can provide I'd be happy to.

Cheers,

Parker