Typo in roms.in following overhaul of advection schemes

[stlaur]

Good afternoon,

I think there is a typo in the GLOSSARY section of roms.in.
It says:

Code: Select all

! or in nested applications
!
!  Hadvection == U3       \                     ! temperature, Grid 1
!                U3       \                     ! temperature, Grid 2
!                U3       \                     ! temperature, Grid 3
!                HSIMT    \                     ! salinity,    Grid 1
!                HSIMT    \                     ! salinity,    Grid 2
!                HSIMT                          ! salinity,    Grid 3

So the glossary says that the advection schemes should be entered with the grid index varying faster than the tracer index.
However, judging from what ROMS reports to standard output, the values are actually read by ROMS the other way around (tracer index varying faster than the grid index).
I'm seeing this with revision 1008.
Thanks,
Pierre

[stlaur]

Just to complete the earlier post---here is the relevant part of ROMS/Utility/read_phypar.F (as of rev.1008):

Code: Select all

            CASE ('Hadvection')
              IF (itracer.lt.(NAT+NPT)) THEN
                itracer=itracer+1
              ELSE
                itracer=1                      ! next nested grid
              END IF
              itrc=itracer
              Npts=load_tadv(Nval, Cval, line, nline, itrc, igrid,      &
     &                       itracer, 1, NAT+NPT,                       &
     &                       Vname(1,idTvar(itrc)),                     &
     &                       Hadvection)

My understanding is that the code...

(1) reads NAT+NPT values for grid #1,
(2) then resets itracer to 1,
(3) then increments igrid to 2 (see the code of FUNCTION load_tadv),
(4) then reads NAT+NPT values for grid #2,
(5) and so on.

(The same goes on for Vadvection.)

And here is a real-life example of the issue.
My roms.in follows the structure suggested by the GLOSSARY:

Code: Select all

   Hadvection == U3       \                     ! temperature, Grid 1
                 U3       \                     ! temperature, Grid 2
                 HSIMT    \                     ! salinity,    Grid 1
                 HSIMT                          ! salinity,    Grid 2

   Vadvection == C4       \                     ! temperature, Grid 1
                 C4       \                     ! temperature, Grid 2
                 HSIMT    \                     ! salinity,    Grid 1
                 HSIMT                          ! salinity,    Grid 2

and this is what is reported by ROMS in standard output:

Code: Select all

 Variable               Grid  Horizontal         Vertical
 ---------              ----  ------------       ------------

 temp                     1   Upstream3          Centered4
                          2   HSIMT              HSIMT

 salt                     1   Upstream3          Centered4
                          2   HSIMT              HSIMT

Note how the advection schemes are flipped.
In summary, I think it would be worth updating the GLOSSARY in a future revision.

[arango]

Yes, thank you for reporting this typo in the documentation. However, why do you want to set a different tracer advection scheme for temperature and salinity across nested grids? I will never do such a thing in any of my nesting applications. It doesn't make sense to me. You need to understand how the nesting exchange between donor and receiver grid is done. Just think about it. Your higher resolution grid has a monotonic scheme while the coarser grid (donor at the contact points) does not! I would recommend that if you choose a scheme for a particular tracer (say, salinity, biology, or sediment), maintain the same scheme for all the nested grid for that particular tracer

[wilkin]

Well this is something that needs some testing and experimentation.

In our model "Doppio" for the Mid-Atlantic Bight and Gulf of Maine we know that the MPDATA scheme tends to foster a poor separation of the Gulf Stream. The 3rd-order upwind (U3) or 4th-order Akima (A4) schemes give better performance in this respect.

However, at river point sources in the estuaries, especially the Chesapeake for strong discharge events in the Susquehanna River, MPDATA is preferred because otherwise we get intensely negative salinities which causes other problems.

So I am interested to use different schemes for salinity in a Chesapeake Bay nest versus the open ocean model parent grid.

I have not experimented to HSIMT to know if that is acceptable for the Gulf Stream separation.

[robertson]

The typos in the roms.in glossaries were corrected in SVN Revision 1009 and Git cbc84128d7d33150dc40ade4821b82dce6ce5662. Details can be found here