My ROMS

Suggest improvements/optimizations to the ROMS code.

Moderators: arango, robertson

Post Reply
Message
Author
User avatar
m.hadfield
Posts: 521
Joined: Tue Jul 01, 2003 4:12 am
Location: NIWA

My ROMS

#1 Unread post by m.hadfield »

Like many ROMS users--I suspect--I have my own lightly hacked version of the ROMS source code and a collection of roms-related scripts. I have just put a selection of these on GitHub.com for the edification and amusement of the ROMS community. There are 3 repositories:
  • roms-trunk-mgh: There are two branches in this repository. The roms-trunk branch is the code from the Rutgers Subversion repository trunk. The master branch is my locally modified copy, into which I regularly merge from roms-trunk. The modifications are minor. I have submitted a few to the Trac system as bug fixes/improvements and there are a few more I may submit. (I've just discovered the delights of using Meld as a Git difftool, which makes it easy to review the differences.) One that I won't be submitting (because it only makes sense to use it for code that's managed by Git) is one that I've just finished: printing Git rather than Subversion revision information to the log file.
  • roms-scripts-mgh: Bash and Python 3 scripts for building the model executable, creating a series of model input files for a multi-segment run, and post-processing model output files. The one I'd specifically like to mention is roms_build, which does the same job as build.bash, but avoids the need to have a separate script for every simulation.
  • roms-test-mgh: This is structured like roms-trunk-mgh, but based on the Subversion repository test directory. The roms-test branch is the Rutgers test tree and the master branch is my modified version. I have been working though a few of the simulations replacing the build.bash script with a "build environment" file, .build_env, required by roms_build.
Regarding the Git revision information, here is an excerpt from some model output:

Code: Select all

...
 Input Script  : ocean_inlet_test.in

 Git Root URL  : git@github.com:hadfieldnz/roms-trunk-mgh.git
 Git Revision  : branch master commit 51965b32fdaf4014a3d69b96f94c27efad45aabb

 Local Root    : /home/hadfield/ROMS/roms-trunk-mgh
 Header Dir    : /home/hadfield/ROMS/roms-test-mgh/inlet_test
 Header file   : inlet_test.h
 Analytical Dir: /home/hadfield/ROMS/roms-test-mgh/inlet_test
...
One cool thing about this is that Git hashes are globally unique, so the commit identifier, 51965b32..., uniquely identifies the codebase for that model run. And this particular commit is on GitHub.com in a public repository, so anyone can find it by entering the hash code, or just the leading digits, into the GitHub.com search box. It's a bit like a DOI system for code revisions.

Actually the above will hold true only if the working copy was clean when the model was built, i.e. without any untracked or uncommitted changes. Generally you should only build from a clean repository, but you might do otherwise by mistake, or when debugging. So I'm going to add a field based on git status output to warn about dirty working copies.

The roms_build script, as I said, is a single replacement for the simulation-specific build.bash scripts, but it requires a bit of guidance to carry out this role:
  • Platform-specific environment variables (eg. FORT, USE_NETCDF4) should be set in the shell before invoking roms_build. I do this with Bash functions defined in .bashrc--see the attached file for examples.
  • Simulation-specific environment variables are specified by a "build environment" file (./build_env by default)--see this example.
  • The roms_build script accepts options to control the compilation mode: -o for OpenMP, -m for MPI, -g to turn on bounds-checking, traceback, etc.
The license is MIT so you can do what you like with this stuff. I'd appreciate suggestions for improvements. Documentation is a bit thin, I'm afraid.
Attachments
bash_functions.txt
Bash functions to set ROMS variables on different platforms
(2 KiB) Downloaded 763 times

User avatar
kate
Posts: 4091
Joined: Wed Jul 02, 2003 5:29 pm
Location: CFOS/UAF, USA

Re: My ROMS

#2 Unread post by kate »

Thanks! Doing a diff between your branches, I don't think this is correct:

Code: Select all

+#  if defined ATM_PRESS & defined PRESS_COMPENSATE
+      real(r8) :: OneAtm, fac
+#  endif
The rules according to this page state that the "and" should be "&&".

Oh, man, I always have untracked cruft in my directories.

User avatar
m.hadfield
Posts: 521
Joined: Tue Jul 01, 2003 4:12 am
Location: NIWA

Re: My ROMS

#3 Unread post by m.hadfield »

Thanks. PRESS_COMPENSATE is something I added to ATM_PRESS. I think it lets you use lateral boundary zeta data from a model without ATM_PRESS (the inverse barometer effect) for a model that does have it. I haven't used ATM_PRESS for a while, but if you're interested in storm surge it's a must-have . I should submit the PRESS_COMPENSATE stuff to Hernan.

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

Re: My ROMS

#4 Unread post by wilkin »

We'd be interested to know more about your PRESS_COMPENSATE.

To use Mercator-Ocean sea level as open boundary conditions to our model we make our own ad hoc adjustment to the sea level to impose an inverse barometer response. Our regional model has the ATM_PRESS effect driving local "storm surge" - actually any dynamic atmosphere forced response which may include Coastal Trapped Waves.
John Wilkin: DMCS Rutgers University
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu

User avatar
m.hadfield
Posts: 521
Joined: Tue Jul 01, 2003 4:12 am
Location: NIWA

Re: My ROMS

#5 Unread post by m.hadfield »

wilkin wrote:We'd be interested to know more about your PRESS_COMPENSATE.
See

https://github.com/hadfieldnz/roms-trun ... u2dbc_im.F
https://github.com/hadfieldnz/roms-trun ... v2dbc_im.F

but replace "&" with "&&".

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

Re: My ROMS

#6 Unread post by arango »

Hi Mark, Are you ready to submit the changes due to the PRESS_COMPENSATE?

Thank you.

User avatar
m.hadfield
Posts: 521
Joined: Tue Jul 01, 2003 4:12 am
Location: NIWA

Re: My ROMS

#7 Unread post by m.hadfield »

Sure. In the next few days.

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

Re: My ROMS

#8 Unread post by wilkin »

The CPP flag should be more explicit that this is solely a modification to the open boundary data, like ADD_IB_TO_OBC_ZETA (!).

Since it requires Pair, which is typically only loaded for BULK_FLUXES, it might need some trickery in globaldefs and get_data.F to load Pair in the event that BULK_FLUXES is not defined.
John Wilkin: DMCS Rutgers University
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu

User avatar
m.hadfield
Posts: 521
Joined: Tue Jul 01, 2003 4:12 am
Location: NIWA

Re: My ROMS

#9 Unread post by m.hadfield »

Hi John

I've just created a ticket for PRESS_COMPENSATE on the Trac system:

https://www.myroms.org/projects/src/ticket/805

I hadn't noticed your follow-up to my comment, sorry, so didn't take it into account. My work weeks are rather fragmented these days! A result of my semi-retired status, an injury in the family and it being too hot to think about work.

PRESS_COMPENSATE has an effect only when ATM_PRESS is defined, and all the trickery to get Pair is already handled for ATM_PRESS. Are you just saying that PRESS_COMPENSATE should have a name that implies its relationship to ATM_PRESS? Or do we need some code to abort compilation if PRESS_COMPENSATE is defined and ATM_PRESS is not? Or have I missed something more fundamental?

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

Re: My ROMS

#10 Unread post by arango »

Thank you, Mark. Your logic is correct. We don't need to add processing logic since it needs ATM_PRESS anyway. I loaded your request ticket to the repository.

Post Reply