usage of both LuvSrc and LwSrc

[jcwarner]

Dear ROMS-

I am trying to use both LuvSrc and LwSrc at the same time. However, the code currently is not allowing that configuration, but i need to make it happen.
Can we make some simple modifications, such as defining a new direction of -1 to be used for the LwSrc?
This will need some minor code changes. For example, every place the LuvSrc is used, it has something like:

IF (LuvSrc(ng)) THEN
DO is=1,Nsrc(ng)
....
IF (INT(SOURCES(ng)%Dsrc(is)).eq.0) THEN
ELSE .... (<-------- Dsrc =1 implied)
END IF

we could change this to be:

IF (INT(SOURCES(ng)%Dsrc(is)).eq.0) THEN
ELSEIF (INT(SOURCES(ng)%Dsrc(is)).eq.1) THEN ....
END IF

If we have both LuvSrc and LwSrc, then this modified section of code will work because we set the direction to be -1 for LwSrc.


For the LwSrc, we also need to modify the code to include a Dsrc catch, for example, from something like this:

IF (LwSrc(ng)) THEN
DO itrc=1,NT(ng)
... DO is=1,Nsrc(ng)

to

IF (LwSrc(ng)) THEN
DO itrc=1,NT(ng)
... DO is=1,Nsrc(ng)
IF (INT(SOURCES(ng)%Dsrc(is)).eq.-1) THEN
....


Would this work? I am not sure what is currently used for Dsrc when imposing LwSrc option.
-john

[arango]

John, I think that will be a simple change and a good idea. We can have other values for Dsrc. I assume that your strategy is to have some point sources doing LuvSrc and other doing LwSrc. We cannot have both methods for the same point source.

[jcwarner]

thanks Hernan.
yes of course. the user would create a single file for all the points (LuvSrc and Lwsrc).
Then for each point, the user would define a Dsrc value.
If Dsrc is 0, then it is for a u point (LuvSrc).
If Dsrc is 1, then it is for a v point (LuvSrc).
If Dsrc is -1, then it is for rho point (LwSrc).
I think that should be enough to differentiate the type and locations.
-j

[wilkin]

In principle, yes, 'uv' and 'w' sources can co-exist, and the Dsrc flag is not used in 'w' sources so it is available to indicate the distinction.

The existing LuvSrc and LwSrc logical flags in roms.in would have to take on the meanings ... if(ANY(LuvSrc)) and if(ANY(LwSrc)) ... to force scanning the list of Dsrc values:

There are some code chunks where no modification is actually required. For example, in step3d_t.F there is only one test of LuvSrc and it has:

Code: Select all

      IF (LuvSrc(ng)) THEN
           DO is=1,Nsrc(ng)
              ...
              IF (INT(SOURCES(ng)%Dsrc(is)).eq.0) THEN 
              ...
              ELSE IF (INT(SOURCES(ng)%Dsrc(is)).eq.1) THEN
              ...
              ENDIF

which has the desired effect of doing nothing if Dsrc is neither 0 or 1. The analogous block of code in sted3d_uv.F simply needs an ELSEIF in place of ELSE.

But elsewhere it's a bit more nuanced and would take a bit of care to implement. To get both LuvSrc and LwSrc to work precisely for all advection scheme options it was critical where in the code various if(LwSrc) and if(LuvSrc) tests are made. They can't be moved around.

I would suggest using Dsrc = 2 for the 'w' sources. I've been a contributor to this Forum long enough to anticipate there will be users who don't read the docs and just assume Dsrc = -1 is for flow in the negative u- or v-direction.

One disadvantage (as far as I can see) is that it's not backward compatible. The new Dsrc value (=2) would have to be set for LwSrc to function. To check for this in the preprocessing would require scanning all Dsrc for the special value and issue a warning in the case that LuvSrc==false AND LwSrc ==true and AND there were no Dsrc == 2.

We have a version of ROMS that adds inflow of subglacial meltwater discharge with a parameterized buoyant plume against the glacier face using LuvSrc, and we want to add the surface runoff along the fjord coast as LwSrc, so I see another application for allowing this flexibility.

I created a metadata schema for my rivers files that allowed me to switch them back and forth between being configured for LuvSrc or LwSrc (by shifting the river_Eposition and river_Iposition if necessary, and keeping track of the river_sign for sources that flow in the negative u- or v- direction). This would break that flexibility, but that's OK.

Still, this will create new and creative ways for people to set up rivers sources incorrectly.

[jcwarner]

starting with the most recent version of Rutgers code, I used the RIVER_PLUME1 test case because it has 1 UV_Psource location for a river entering a N-S Periodic domain with East and West walls. Therefore, the entire volume change within the domain is due to the river inflow. I ran the test case 'as is' and the volumes were:
vol_init = 8.683200E+11
vol_final_river=8.721798E+11

I then added a large Q_Psource (Dsrc=2) to simultaneously simulate a rainfall event on 10 cells near the coast.
I used a rainfall of 0.10m/hr, so the flow on each cell is (dx dy Rain)
Qbar = 3000m * 1500m * 0.10 m/hr * 1hr/3600s = 125m3/s
over 10 cells for 30 days
125 m3/s *30days *24hrs/day*3600s/hr *10 cells = 3.240000000000000e+09 m3 of volume added from the rain.

I modified:
roms_riverplume1.in
ana_psource.h
omega.F
pre_step3d.F
step2d_LF_AM3.h
step3d_t.F
read_phypar.F

compiled and ran it with the river and the rain event. The final volume for river+rain is
vol_final_river_rain= 8.754198000000000e+11

The difference is:
vol_final_river_rain-vol_final_river= 3.240000000000000e+09
and that is the rainfall volume, thankfully.

Hernan/John - can you take a look at these routines and see if it can be incorporated into the distribution? thanks, j