speaking of advection and spurious dyes

[rduran]

I am advecting three dyes one looks great, one is terrible and the third is less than acceptable. This is during the same run and all options for the three dyes are the same. I had done a similar run before and it worked nicely. I have double checked my bry and ini and forcing files it is all as it should. Why would one dye be advected nicely and the other not?

I can see a bad oscillation in the first HIS file after I restart the simulation with the dyes.Plot attached. the dye values in leftmost are ok, the dye values in middle should be equal to the latitude at each point, that blue stuff coming out of the boundary isnt good. Similarly the one on right should all have values of -10 (about)

[lanerolle]

Are you advecting the three dyes simply from some initial condition (only) or are you having both initial conditions plus point sources for the dyes? I am assuming that you have some sort of open boundary value for the dyes too.

Could you please let us know what the minimum and maximum value of the dyes you are putting into the simulation? - I am assuming that the minimum value is 0 (zero) and the maximum value is some Pmax.

The dyes are going negative due to the discretization of the tracer advection terms. Its a little long, but you may want to read through the discussion topic "Can we have only passive tracers in rivers/point sources?" where I have also had similar experiences.

[rduran]

Thank you for you answer Lyon.

I do have a river but the problems happen with and without point source for the dyes. The boundary conditions (double-checked to be right) are given by the definition below.

The max min values for my dyes are:

-129<dye_01<-123.7 (Longitude)
48<dye_02<41 (Latitude)
min(depth)<dye_03<0 (Depth, negative)

These dyes are the initial position for any given grid cell and by advecting them I get Lagrangian label dyes. They are defined as:
dye_01=X(x,y,z,t=0)=x
dye_02=Y(x,y,z,t=0)=y
dye_03=Z(x,y,z,t=0)=z

And then advected to compare their initial with their final position. Up to one month integration has been successful before.


BRY conditions (same as successful experiment) are:

Code: Select all

 Variable               Grid    West Edge   South Edge  East Edge   North Edge
 ---------              ----    ----------  ----------  ----------  ----------

 zeta                     1     Chapman     Chapman     Closed      Chapman

 ubar                     1     Flather     Flather     Closed      Flather

 vbar                     1     Flather     Flather     Closed      Flather

 u                        1     Rad + Nud   Rad + Nud   Closed      Rad + Nud

 v                        1     Rad + Nud   Rad + Nud   Closed      Rad + Nud

 temp                     1     Rad + Nud   Rad + Nud   Closed      Rad + Nud

 salt                     1     Rad + Nud   Rad + Nud   Closed      Rad + Nud

 dye_01                   1     Rad + Nud   Rad + Nud   Closed      Rad + Nud

 dye_02                   1     Rad + Nud   Rad + Nud   Closed      Rad + Nud

 dye_03                   1     Rad + Nud   Rad + Nud   Closed      Rad + Nud

 tke                      1     Rad + Nud   Rad + Nud   Closed      Rad + Nud

I have been looking at the post you mentioned but the weird thing here is that I have done pretty much the exact same experiment with a different vertical discretization and it looked just fine. Could it be the vertical discretization?

Hernan did mention that

It is possible that you have a vertical CFL violation due to the rotated diffusion tensor

. And although I do have better vertical resolution this time I also smoothed my bathymetry some more.

And why would one dye (01) work perfectly and the two other not? ... Everything except the dye values are the same for the three dyes.

R

[wilkin]

You have radiation and nudging as your boundary conditions.

So have you set the boundary values that the nudging uses to be the same as the initial conditions?

Did you check the stdout to see that the boundary data are read, and have the correct values?

For the nudging time scale applied on the boundary, did you customize ana_nudgcoef.h to modify the nudging time scales, or are you using values of TNUDG set in ocean.in?

I believe you will need to set the values for all tracers in the line:

TNUDG == 2*0.0d0 ! days

If you leave it like this, only the first two tracers (temp, and salt) will have TNUDG set, and they will be set to 0.0d0

If you want to set all 5 tracers (temp, salt and dyes 1-3) you will need,
e.g.
TNUDG == 5*1.0d0 ! days
or
TNUDG == 2*10.0d0 3*1.d0 ! days

or whatever.

What did you use for OBCFAC?

You can check the actual nudging values that ROMS used, as opposed to what you think you used, by looking at Tobc_in and Tobc_out in the output files.

[rduran]

John, thank you very much!

You are right, I should be checking my stdOut more carefully and it does make sense it would be something to do with the bry conditions (of course!)... For some reason ROMS is only reading the bry conditions for the first dye and it is invoking ROMS/Functionals/ana_nudgcoef.h

Yes the bry values for all time are set exactly as the initial values. I thought it would make sense to let dyes flow out of domain according to the flow in the solution and to "paint incoming water" by nudging to the dye bry values according to the nudging parameters as described below.


I don't know why the bry data is not been read (except for first dye) or how to fix that.


I have attached the stdOut (.log), the cppdef options (.h) and the stdIn (.in) files for a small test run hoping somebody can help me out. Please note I undefined the open bry conditions from the cppdefs.h file because ROMS 3.6 has them defined in the .in file

Another weird thing regarding reading input information is that in my infile I have

Code: Select all

LtracerSrc == T T F F F

but in my out file I have:

Code: Select all

T  LtracerSrc(01)  Processing point sources/Sink on tracer 01: temp
T  LtracerSrc(02)  Processing point sources/Sink on tracer 02: salt
T  LtracerSrc(03)  Processing point sources/Sink on tracer 03: dye_01
T  LtracerSrc(04)  Processing point sources/Sink on tracer 04: dye_02
F  LtracerSrc(05)  Processing point sources/Sink on tracer 05: dye_03

Although the rest nudging parameters is correct in my out file:

Code: Select all

 1.0000E+00  Tnudg(01)       Nudging/relaxation time scale (days)
                               for tracer 01: temp
 1.0000E+00  Tnudg(02)       Nudging/relaxation time scale (days)
                               for tracer 02: salt
 1.0000E+00  Tnudg(03)       Nudging/relaxation time scale (days)
                               for tracer 03: dye_01
 1.0000E+00  Tnudg(04)       Nudging/relaxation time scale (days)
                               for tracer 04: dye_02
 1.0000E+00  Tnudg(05)       Nudging/relaxation time scale (days)
                               for tracer 05: dye_03
...

1.0000E+02  obcfac          Factor between passive and active
                              open boundary conditions.

thanks,

Rodrigo.

[wilkin]

Hmmm. Well that is looking suspiciously like a bug with the new version.

Three things to try:

(1)
Please try changing

Code: Select all

LBC(isTvar) ==   RadNud  RadNud  Clo     RadNud \    ! temperature
                 RadNud  RadNud  Clo     RadNud \    ! salinity
                 RadNud  RadNud  Clo     RadNud      ! dye_ 

to explicitly set the options for the other two dyes.

(2)
Set

Code: Select all

LtracerSrc = T T T T T

to see if that alters the behaviour.

(3)
If you did not update varinfo.dat with the new version you might want to do so in case changes there affect things. I've certainly made the mistake of not updating all of ocean.in, varinfo.dat, and my cppdefs when there is a big code change like this.

John.

[rduran]

John, thank you very much!

If I do svn up I get: At revision 571
The varinfo.dat I am using is the one that came with revision 571 however it reads:

Code: Select all

svn $Id: varinfo.dat 567 2011-09-19 22:43:36Z arango $

Yeah that makes sense (of course ... again!!), now it reads:

Code: Select all

LBC(isTvar) ==   RadNud  RadNud  Clo     RadNud \    ! temperature
                 RadNud  RadNud  Clo     RadNud \    ! salinity
                 RadNud  RadNud  Clo     RadNud \    ! dye_
                 RadNud  RadNud  Clo     RadNud \    ! dye_
                 RadNud  RadNud  Clo     RadNud      ! dye_

I also have

Code: Select all

LtracerSrc == T T T T T

I ran a short test run, first I got:

Code: Select all

 Model Input Parameters:  ROMS/TOMS version 3.6
                          Sunday - October 16, 2011 - 12:06:37 PM
 -----------------------------------------------------------------------------

 INP_PAR - illegal lateral boundary condition keyword: RadNud
                         RadNud  RadNud  Clo     RadNud      ! dye_

 Elapsed CPU time (seconds):


 ROMS/TOMS - Output NetCDF summary for Grid 01:

 ROMS/TOMS - Input error ............. exit_flag:   2


 ERROR: Abnormal termination: NetCDF INPUT.
 REASON: No error

But then I checked for those invisible tabs and after using my spacebar ... it did read the 3 dye boundary conditions correctly.

This is also looking ok:

Code: Select all

 T  LtracerSrc(01)  Processing point sources/Sink on tracer 01: temp
 T  LtracerSrc(02)  Processing point sources/Sink on tracer 02: salt
 T  LtracerSrc(03)  Processing point sources/Sink on tracer 03: dye_01
 T  LtracerSrc(04)  Processing point sources/Sink on tracer 04: dye_02
 T  LtracerSrc(05)  Processing point sources/Sink on tracer 05: dye_03

And after inspecting the output, the dyes are looking good now.

thank you very much John for the help (& lessons for the future)!

Rodrigo