compressibility

[inga]

Hi, my name is Inga, I was a participant of the workshop in Venezia in 2004 but it somehow happened that I am about to start enjoying with ROMS only now. I warn you, it is my first numerical model

I intended to start with generals & idealized configurations, performing some experiments with the old version of code from Patrick Penven. Then I decided to update myself and I loaded version 2.2. It is working! And here comes my question: is there any treatment of the compressibility in the 2.2 version? In the old one there was a SPLIT_EOS switch and a routine prsgrdAC1.F. I read carefully different routines for pressure gradient computation in the new version and compared with the old one (prsgrdAC1.F) and the compressibility switch seems non-existing in the 2.2. Or am I wrong? Is there any way to perform the experiments similar to those in (Shchepetkin and McWilliams 2003)?

Thanks,

Inga

[shchepet]

...as far as I know, the compressibility switch has never been implemented in Rutgers codes, but is now standard in UCLA codes (SPLIT_EOS is #defined all the time).

...and yes, it leads to additional pressure gradient errors, if EOS does not allow you to distinguish between in-situ and adiabatic diferences/derivatives of density.

The only update relative to the 2003 code with respect to this matter is cancelling the bulk part of "passive" compressibility in the spirit of Dukowicz, 2001, paper (see appearance of number 0.000649 below). The recommended value of Boussinesq rho0 is now 1027.8 (which is slightly different from more widely used 1025 or 1000) which is closer to the real at-depth values consistent with model EOS.

Code: Select all

    dr00=r00-rho0

            Tt=t(i,j,k,nrhs,itemp)
#  ifdef SALINITY
            Ts=max(t(i,j,k,nrhs,isalt), 0.)
            sqrtTs=sqrt(Ts)
#  else
            Ts=0.0
            sqrtTs=0.0
#  endif
            rho1(i,j,k)=( dr00 +Tt*( r01+Tt*( r02+Tt*( r03+Tt*(
     &                                                               r04+Tt*r05 ))))
     &                         +Ts*( r10+Tt*( r11+Tt*( r12+Tt*(
     &                                                              r13+Tt*r14 )))
     &                              +sqrtTs*(rS0+Tt*(
     &                                    rS1+Tt*rS2 ))+Ts*r20 ))
#  ifdef MASKING
     &                                                                  *rmask(i,j)
#  endif
            K0= Tt*( K01+Tt*( K02+Tt*( K03+Tt*K04 )))
     &         +Ts*( K10+Tt*( K11+Tt*( K12+Tt*K13 ))
     &              +sqrtTs*( KS0+Tt*( KS1+Tt*KS2 )))

#  ifdef SPLIT_EOS
            qp1(i,j,k)=( 0.000649 +  0.1*(K00*rho1(i,j,k)-rho0*K0)
     &                                                           /(K00*(K00+K0)) )
#   ifdef MASKING
     &                                                                      *rmask(i,j)
#   endif
......
\..

[inga]

Thanks a lot. But now I am a little bit puzzled about which code to use. Are there other significant differences between the Rutgers and UCLA codes? To start with, I will use ROMS for the idealized configuration, quite deep (maybe 2000m), rather periodic conditions, possibly some coast or island later on, with an ecosystem, but not the default one in ROMS, but other, with bacteria. Are there any other features in UCLA code that make it more appropiate for that case? Are the UCLA version loadable from the internet at all (I haven't found an adequate webpage)?

Inga

[shchepet]

Regarding which code to use: the short answer is use a version which is the most suitable for your particular needs. This is because there are many peripheral developments and submodels driving my applications for which you (and most people except those directly involved) probably do not care about, but they just increase complexity and size of the code.


Since you are already familiar with both of them, I suggest that you compare "the old version of code from Patrick Penven" you already have and the updated version 2.2 you also have working and do the following:

Configure them both for the same simple pre-defined test application, starting with SOLITON (just a simple 2D problem), UPWELLING, SEAMOUNT (they all should do it with just a flip of CPP-switch), make sure that you have the same resolution, the same subdomain partitioning policy and the same set of compiler flags.

Say for SOLITON use:

Grid resolution: 384 x 128 partitioning NSUB_X x NSUB_E = 3 x 32 time step: dt=0.055 NTIMES=2400

Compiler optimization flags (I presume you have some sort of Linux):

OMP_FLAG = -fpp2 -openmp #<-- only if you use Open MP

ifort $(OMP_FLAG) -pc80 -tpp7 -axN -xN -align dcommon -auto -stack_temps -O3 -IPF_fma -ip

[in the above replace "-axN -xN" with "-axP -xP" Intel P4 Prescott on newer CPU (these come with 1M cache)]


Make sure that this is consistent for both codes.

It should take only a fraction of a minute to run this test.

Then you report your findings back to this board, if you want to. I will reply then.


Regarding the availability of UCLA ROMS codes on the web: they were
freely available on the web directory

http://www.atmos.ucla.edu/~alex/ROMS/

until the late last summer when we started having major issues with Dr. Yhe Tony Song. The most recent file "roms.tar" is dated back on June 1, 2005 is still available for download, along with earlier versions. You are welcome to examine it --- this should be reasonably close to what you got from Pierrick, and therefore easy to adapt. You may include it in the test too.

Newer versions are no longer downloadable on the web because of the issues, but are still available upon request.