river salinity overshoot

[px123]

My salinity around the river often shows very high values over 40. And this high value only exists in the bottom layer. One layer up, salinity goes normal. So far, I have tried (1) smooth the grid (2) put river in top layers (3) activate both temperature and salinity or only salinity (4) tune bottom stress (5) change PSOURCE position. None of them can resolve this issue. Any one has the experience of dealing with it? Thanks in advance!

[linzhenhua]

I vaguely remembered some flags such as MPDATA (or TS_MPDATA) could alleviate such problems, try search the forum and check if it helps.

Or you may try initializing a smooth transition zone between the low (river) and high salinity (ocean).

[shchepet]

I vaguely remembered some flags such as MPDATA (or TS_MPDATA) could alleviate
such problems

This sounds like a fairly standard answer in ROMS comminity (and, in fact, in general
oceanographic comminity), however, it should be noted that contrary to a very popular
belief MPDATA is not a monotonicity-preserving, total-variation-diminishing (TVD) scheme.

The only special property MPDATA has is sign preservation, i.e., all-non-negative tracer
field remains all non-negative, and vice-versa about all-non-positive.

MPDATA can, in principle, create a new extremum or amplify an existing extremum in the
vicinity of a sharp transition. Nevertheless, much of positive experience with MPDATA
is due to its relatively low numerical dispersion (similar to that of Lax-Wendroff scheme)
combined with some left-over numerical diffusion which makes it very robust.

...Try to avoid sharp front in your initial condition by spreading in across three grid points.

[pmaccc]

In my experience you can help with this problem by making your rivers longer, so that non-zero salinity doesn't penetrate up to the river source cells. This naturally avoids the problem of having very sharp gradients which can lead to numerical inaccuracy.

[px123]

Sasha, does ucla ROMS have MPDATA option?

I vaguely remembered some flags such as MPDATA (or TS_MPDATA) could alleviate
such problems

This sounds like a fairly standard answer in ROMS comminity (and, in fact, in general
oceanographic comminity), however, it should be noted that contrary to a very popular
belief MPDATA is not a monotonicity-preserving, total-variation-diminishing (TVD) scheme.

The only special property MPDATA has is sign preservation, i.e., all-non-negative tracer
field remains all non-negative, and vice-versa about all-non-positive.

MPDATA can, in principle, create a new extremum or amplify an existing extremum in the
vicinity of a sharp transition. Nevertheless, much of positive experience with MPDATA
is due to its relatively low numerical dispersion (similar to that of Lax-Wendroff scheme)
combined with some left-over numerical diffusion which makes it very robust.

...Try to avoid sharp front in your initial condition by spreading in across three grid points.

[feroda]

As can been seen from the attached figure, both temperature and salinity reach abnormally high values in the river channel. This also causes the model blowing up, and end up with all NaN.

As suggested by Prof. MacCready, the Mekong River has been extended northward by ~200km artificially. However, this seem not the real source of the problem.

Any more suggestions or comments? Thanks!

[susonic]

What happen if you give sources at whole vertical layer?

[feroda]

What happen if you give sources at whole vertical layer?

Thanks. Actually, the rive discharge was given along the whole vertical layers with a constant river_Vshape.

I also tried to use TS_A4HADVECTION and TS_A4VADVECTION as suggested in one of Hernan's post. It could not improve the situation here either.

[susonic]

Well, actually I experienced that kind of problem many moons ago.

1. At that time I was giving only salinity on and the problem was fixed when I give both temperature and salinity on. But in your case, you already tried that before right?
2. Is your model including tide? If so, what happen if you undefine the tide?
3. Just in case, did you check out the river source point position and direction?

[feroda]

1. At that time I was giving only salinity on and the problem was fixed when I give both temperature and salinity on. But in your case, you already tried that before right?

Right now, I have both temperature and salinity on. The temperature is sampled from a location within the river estuary, while the salinity is set to zero.

2. Is your model including tide? If so, what happen if you undefine the tide?

There is no tide in this case. This is a climatological run, and I want to get a quasi-stable state and open tidal forcing in the inter-annual simulation thereafter.

3. Just in case, did you check out the river source point position and direction?

Yes. I am pretty sure that I did not mess up either the river position or direction. This could be verified by the middle panel in my first post.

The problem here is that the temperature and salinity gradient is way too large in the river channel. It seems to me that the artificial channel is not long enough to damp down the signal from the ocean.
Or, a boundary condition should be considered on the source point to let the signal go out of the channel in a RADIATION way or beyond.

This problem causes my model blowing up. Any further suggestions would be much appreciated. Thanks.

[susonic]

1. What about the depth from the river source point to the river mouth?
Does it vary?
2. How about change the river starting point?(ie. masking above the curving point and starting from it)

[kate]

2. How about change the river starting point?(ie. masking above the curving point and starting from it)

Yes, it looks like the model doesn't like that sharp bend in the river. I would try leaving out that northern part of the river.