TS_PSOURCE, UV_PSOURCE and ANA_PSOURCE

Archive of important messages sent via the ROMS mailing list

Moderators: arango, robertson

Post Reply
Message
Author
User avatar
arango
Site Admin
Posts: 1081
Joined: Wed Feb 26, 2003 4:41 pm
Location: IMCS, Rutgers University
Contact:

TS_PSOURCE, UV_PSOURCE and ANA_PSOURCE

#1 Post by arango » Mon Feb 15, 2010 5:36 pm

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.

Post Reply