Typo in roms.in following overhaul of advection schemes

Suggest improvements/optimizations to the ROMS code.

Moderators: arango, robertson

Post Reply
Message
Author
stlaur
Posts: 30
Joined: Sun Jun 27, 2010 8:45 pm
Location: Old Dominion University

Typo in roms.in following overhaul of advection schemes

#1 Unread post by 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
Posts: 30
Joined: Sun Jun 27, 2010 8:45 pm
Location: Old Dominion University

Re: Typo in roms.in following overhaul of advection schemes

#2 Unread post by 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.

User avatar
arango
Site Admin
Posts: 1347
Joined: Wed Feb 26, 2003 4:41 pm
Location: DMCS, Rutgers University
Contact:

Re: Typo in roms.in following overhaul of advection schemes

#3 Unread post by 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 :!:

User avatar
wilkin
Posts: 875
Joined: Mon Apr 28, 2003 5:44 pm
Location: Rutgers University
Contact:

Re: Typo in roms.in following overhaul of advection schemes

#4 Unread post by 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.
John Wilkin: DMCS Rutgers University
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu

User avatar
robertson
Site Admin
Posts: 219
Joined: Wed Feb 26, 2003 3:12 pm
Location: IMCS, Rutgers University

Re: Typo in roms.in following overhaul of advection schemes

#5 Unread post by robertson »

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

Post Reply