Losing tracer as time progresses

[arnem]

Dear all,

I am running ROMS with tracers included, and I am experiencing a problem:
I'm introducing the tracer in the initial conditions, and ROMS runs fine, and produces output along the lines that I anticipated. But when I examine the results for the tracer ('dye_01'), domain-wide integration reveals that the tracer is being lost at an average rate of about 0.58%/day (corresponding to a half life of approximately 4 months), inside a range of 0.5-07%/day (e.g. never temporarily re-bounding to larger values).

This happens from the very start of the simulation, i.e. long before the tracer reaches any of the open boundaries. Does anyone have an idea about what's going on?

I can add that I've also included some floats that are initialized in the same region as the tracer, and the results for floats and tracer appear to be consistent regarding circulation pathways.

Here are some specifics about the experiment:
I use ROMS v. 3.5 for an 800m x 800m model configuration.
Some relevant CPP options that are activated include
T_PASSIVE
TS_MPDATA
MIX_GEO_TS
SPLINES
GLS_MIXING / N2S2_HORAVG
Relevant CPP options that are _not_ activated include
UV_VIS2
UV_VIS4
UV_SADVECTION
TS_DIF2
TS_DIF4
TS_SVADVECTION
TS_C4VADVECTION
TS_SMAGORINSKY

I can add that I performed a short simulation (4 days) in which I replaced MPDATA by UV_SADVECTION / TS_U3HADVECTION / TS_C4VADVECTION; the evolution of the domain-wide integration of the tracer was very similar to the MPDATA case.

Finally, I should add that I'm fairly new to running ROMS, so there's definitely a chance that I've made some stupid simple mistake.

Can anyone help? Thanks in advance!

Best regards,
Arne Melsom
MET Norway

[wilkin]

Your tracer might not have reached the boundaries, but if the boundaries are open the open boundary conditions (e.g. radiation) could introduce some small amplitude noise that affects your global tracer budget.

To get a precise budget, in your vertical integral step be sure you use the time varying sea level when computing the cell thicknesses from the s-coordinate.

[arnem]

First, a general comment:
Has anyone done the same exercise, i.e. checking conservation of a passive tracer? I'd like to know what you discovered!

Next: Thanks a lot for taking the time to respond, John!

Here's a bit more about what I've done:

Regarding your second suggestion, I did take the temporal changes of the surface elevation into account when computing layer thicknesses as part of the tracer concentration integration. I used daily averaged output, so I guess there could be some impact of non-linearities between results for tracers and surface elevation. Still, I don't understand how this should lead to a near-constant removal of tracer (day-by-day). I can add that I also checked for changes in total water volume; this changes by a small fraction, but fluctuating up and down, i.e. not drifting

Regarding your first suggestion, I can add that the following:
(1) it seems to me that the only way that boundaries could affect the budget in the initial stage, and contribute towards reduction in the tracer integral, would be by introducing negative values due to the implementation of OBCs -but, with MPDATA, I don't see negative tracer concentrations anywhere
(2) in the main experiment, I had *_TRADIATION and *_TNUDGING active, but I performed a brief (4-day) test with these CPP options inactive too; with nearly the same result for the tracer integral

All suggestions are welcome!

[wilkin]

There is a note at:
https://www.myroms.org/wiki/Numerical_S ... nd_Tracers
to say

Warning: The preceeding notes on tracer advection refer to all but the MPDATA option. The MPDATA algorithm has its own predictor-corrector with emphasis on not allowing values to exceed their original range, and therefore gives up the constancy-preservation. This will be most noticeable in shallow areas with large tides.

You might want to check conservation with another advection scheme.

There are also the DIAGNOSTICS which would allow you to see a term-by-term balance and check the internal point-wise precision of conservation (and possibly reveal net tendency away from the initial condition region - like at the boundaries).

Can you close the boundaries to completely take them out of the equation?

If you're using *_TRADIATION and *_TNUDGING options then your code is a bit out-of-date. It's always good to start new projects with an up-to-date version from the repository.

[arnem]

Thanks again, John!

In particular, for pointing out the note on the implementation of MPDATA.
However, as I mentioned in my original post, I've already tried with another OBC configuration, which gave basically the same result.

I must admit that I can't comprehend that the tracer from the open boundaries has an impact, since (a) visual inspection of results show values of 0 extending from the boundaries and a long way into the interior of the domain; (b) tracer concentrations at the boundary are set to 0 in the bry-file.

There's however a boundary issue that may be of relevance: This is a region with strong tides. Over the week end, I'll set up an experiment where I turn off tidal ssh forcing at the open boundaries, and check whether or not that has an impact.

(I agree that it would be best with the latest ROMS version; there's a reason for my choice -which admittedly is not a very good one.)

[jcwarner]

i posted a reply, and it did not seem to show up so i will try this again.
We have conducted tests in the past with sediment to make sure the total amount of tracer is conserved, and the tests worked with MPDATA and other schemes. I suggest you make your calculations on the history files as the averages can be a bit tricky for mass conservation. Use the get_roms_grid to compute the Hz values as that will take into account the vtransform and vstretch params.

[arnem]

John, JC,

Thanks again. I believe I've discovered where my problem is. First, the attempts to run without tides and to examine history files (and not averaged results) didn't help.

However, you made another suggestion -switching to a more recent ROMS version- which pointed me in the right direction: In v. 3.6, users may specify to which tracer variables (if any) that surface restoration is to be applied.

My v. 3.5 experiment was configured with a weak surface restoration (e-folding time scale of 180 days). When I switch this off, my problem goes away. So I guess I was wrong in assuming that this feature was one for which 'active' and 'passive' tracers were treated differently -'passive' is not so passive after all.

I had no "dye_01" variable in my clim-file, so it seems that ROMS decided to restore surface concentrations using a climatology of 0.

Arne
MET Norway

[krysten]

Hi Arne,

I was wondering how you turned off this surface restoration in v 3.5 - we are also using v 3.5 and I've noticed a similar problem with our passive tracer conservation.

Thanks!
Krysten

[wilkin]

The logic of the climatology nudging is explained in this release note from 2014:
https://www.myroms.org/projects/src/ticket/627 (scroll down about half way to the climatology information - after the sponges).

In a nutshell, the LtracerCLM switch controls whether ROMS needs to read climatology (for nudging) from a netcdf file (or analytical function). This was introduced because the old configuration demanded that if a user wanted to nudge to any tracer (say, only one tracer out of all the tracers in an ecosystem model) then all tracers had to be present in the file. The LnudgeTCLM switch controls whether the nudging is actually applied. The LnudgeTCLM switches for biological and sediment tracers are specified in their respective input scripts. The switches for passive tracers are in the main ocean.in. If you don't explicitly specify them, you might get an unexpected result.

As always, if you're not sure what is going on look in the stdout ("log" file). The values of all switches are reported there and that is the definitive word on what you actually did, versus what you thought you did, in configuring ROMS.

[arnem]

Hi Krysten,

Sorry, I forgot to post how I ended up dealing with this issue!
(Word of warning: I'm fairly new to ROMS, so be skeptical...)

I had actually looked at this the way John just suggested, by looking for 'TNUDG' in the output log file.
I found a list of values for each tracer (active and passive), so I tried successfully to change the
nudging of passive tracers, and not active ones. If you have two active tracers (T,S) and one passive
(dye_01), the following statement in the ROMS input file works:
TNUDG == 2*180.0d0 0.0d0

In the log file, I then find
1.8000E+02 Tnudg(01) Nudging/relaxation time scale (days)
1.8000E+02 Tnudg(02) Nudging/relaxation time scale (days)
0.0000E+00 Tnudg(03) Nudging/relaxation time scale (days)

One might think that a nudging time scale of 0 days would imply instant application of a prescribed
condition, but it turns out that this is coded as a special case; in Functionals/inp_par.F I find
IF (Tnudg(itrc,ng).gt.0.0_r8) THEN
Tnudg(itrc,ng)=1.0_r8/(Tnudg(itrc,ng)*86400.0_r8)
ELSE
Tnudg(itrc,ng)=0.0_r8
END IF

Hope this helps!

Arne
MET Norway