Ocean Modeling Discussion

ROMS/TOMS

Search for:
It is currently Sat Dec 16, 2017 7:27 am




Post new topic Reply to topic  [ 1 post ] 

All times are UTC

Author Message
PostPosted: Mon Feb 15, 2010 5:36 pm 
Offline
Site Admin
User avatar

Joined: Wed Feb 26, 2003 4:41 pm
Posts: 1019
Location: IMCS, Rutgers University
We continue getting messages in this forum, over and over, about the usage of the analytical option ANA_PSOURCE for setting point-sources of tracer (TS_PSOURCE) and momentum (UV_PSOURCE) to represent river runoff in coastal applications.

I have mentioned several times that the routine ana_psource.h should be used with extreme caution and in serial applications only :!: . Using this routine for parallel applications is extremely difficult in either shared-memory (_OPENMP) or distributed-memory (MPI) configurations. This is even time consuming and tricky for me... Last time that I looked a this routine and corrected several parallel bugs, I spent hours in the parallel debugger (TotalView). This routine is for people with advanced knowledge in parallelism and ROMS framework. You always have to debug any code added to this routine :!:

I have always recommended to not use ANA_PSOURCE, but a forcing NetCDF file instead to specify point-sources. See template Data/ROMS/CDL/frc_rivers.cdl showing how the river forcing NetCDF file looks like. It is very easy to create such file. It can be done very quicky :!: You just need to know how to manipulate and write NetCDF files. I will add a matlab script soon, so you can follow how this is done.

I have even noticed some users using ana_psource.h to specify open boundary conditions at each grid point. Well, think better about your approach and use the open boundary NetCDF files instead. This has to be done in a consistent way with a large scale model. You cannot simulate real circulations by specifying analytical point-sources at the open boundaries. Realistic ocean circulation is not as simple as that...

I hope that this is the last time that we hear from users in this forum about this issue. We will ignore such inquires, even if the river runoff is secondary. Overshooting/undershooting of tracer values next to rivers maybe associated with parallel bugs. So you are on your own here. I am now tempted to remove this capability from ROMS and used NetCDF files in all our test cases needing river runoff.

River runoff forcing is very tricky and requires experience. You need to look for a lot of things: bathymetry, land/sea masking, r-factors, vertical level distribution, temperature and salinity values, and so on. This even gets more complicated if you activated wetting and drying and/or include tidal forcing. Recall that we are representing an estuary with a single point :shock:. Point-forcing in a parallel framework is not trivial in a coarse-grained model like ROMS.

For stability considerations, you need to activate both TS_PSOURCE and UV_PSOURCE in 3D applications. You also need to specify both temperature and salinity :!: at each point-source - even if you include sediment and biology sources.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1 post ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group