struggling for sharp halocline

[jacopo]

Dear all,

I’m searching for the correct representation of mixed layer with stable stratification and (generally) moderate to low wind condition in a realistic basin/application. I would like to hear from you any useful comment, if any.

Application:
The sea is enclosed, with two straits at opposite sites. Depths range from coastal to very deep (1000m).



The vertical distribution of salinity show a very sharp halocline at 20 m, from say 20+ PSU in the surface layer to 39 right below the halocline (‘abrupt’ change in a couple of meters). This is a stable feature throughout the year, maintained by incoming low salinity flows from an adiacent sea, although actual values have some intraannual and interannual variability.
During summer-autumn the vertical structure is clearly statically stable and my simulation didn’t hit winter yet, when indeed some high wind condition and double diffusion processes may be found.

After 1 month after a realistic initial field (with sharp halocline/picnocline) and realistic forcing I got from ROMS a gentle halocline with surface salinity higher than what it should be (say, 2-3 PSU) and lower salinity below the haloocline down to 100m. In other words, my application is not able to maintain the sharp transition from the surface layer to the waters below.
Yep, I know, this is not really surprising. . .



My vertical resolution is [theta_s theta_b Tcline Nlevels] = 7 0.3 20 40 , so fairly stretched at the surface with reasonable number of levels.



I'm running with

default advection scheme
#define DJ_GRADPS
#define TS_U3HADVECTION
#define TS_C4VADVECTION
#define TS_DIF2 (very low TNU2)
#define MIX_GEO_TS

#define GLS_MIXING (k-e)
#define KANTHA_CLAYSON
#define N2S2_HORAVG

Is there any way to get rid of the smooth, gentle halocline?
I suppose that if using z-level in the first 100-200m and terrain following below would help. But ROMS doesn't have that.
Also, it can be the turbulence closure scheme that mixes too much across the picnocline.
Any hint?

Thanks

Jacopo

[rsignell]

Jacopo,
I think you are right that the vertical stretching in this case will cause numerical mixing of the pycnocline over time. Rob Hetland and I saw the same thing with shallow surface trapped river plumes moving back and forth across the sloping shelf under repetitive upwelling/downwelling cycles. As you say, this case cries out for sigma-over-z, or z-over-sigma, or something different than what we've got currently. I know that Hernan is actively thinking about making the vertical coordinate more general, so perhaps the timing is good for a broader discussion on this topic.
-Rich

[jcwarner]

Maybe even the composed grid method might help.I did not see a fig for a plan view of the application, but perhaps several grids could be put together. This would require interpolation in the vertical at the grid connections.

[jivica]

Jacopo,
have you checked your sigma layer angle with the respect to "z", and hydrostatic stability among rx0 and rx1 at the region?
We have made some experiments with regions that have big slope of sigmas and result was plaque by HPG a lot, giving unrealistic velocity which after some time went to artificial equilibrium with "not so physical" density field (which was affected with the unphysical velocity fields) so at the end you end up in wrong staate...
just a thought...
ivica

[jacopo]

Guys,

thanks for replying.

The idea of composed grid is nice, even if a little bit tricky given the morphology of the basin.
thanks for suggesting. I might consider this if I fail with simpler approaches.

Ivica, you don't want to know the actual rx0, rx1 values. As Kate said somewhere in this forum, Sasha would call them 'insane'. I agree this is an issue, and I'm trying to keep rxs as small as possible. A workaround can be to set minimum H deeper than the picnocline in order to push the PG error below. I'm still skeptical about the physical implications of that.
I understand I have to live with what I have at hand, but z-over-s coordinate would be probably the smartest way to approach this. In that case you can also definitely make lower the stiffness factors where s-levels are used. And you don't have PG errors where z-levels are.

[jivica]

Jacopo,
sure I do agree that hybrid vertical could be thing that improve many thinks, BUT
you should know how rx* looks like (for the ALL POINTS of your domain!) not just max value.
So you can pcolor it and see where it is 'insane' and believe me, at the regions HPGE is devel!
you'll get your real solution (if I can call it real) spoiled with errors which will make possible appearance of vertical velocities (due to HPGE) which can make
mixing as well... So what I would do is to use what is easy to do, and see how bad sigma is and where it is bad, and than try to fix it as much as I can..
(we can provide you LP stuff developed for ROMS). If all of that gives no result or still poor and not satisfactory than modify depth.f90
ivica

[jacopo]

It is intriguing to see the results from this experiment.

I used the 'workaround' cited before: set minimum depth 30 m and insane stretching at the surface of the s-levels. The vertical grid in the surface layer is now this:

[/url]

This comes at a cost, however. Shallower region are dumped out from the domain, bottom layers are poorly represented and probably Hernan is having a heart-attack reading about this stretching.



The results are amazing. The black line is the new ROMS solution. Before discarding everything because the interior flow might be broken, one outcome is very welcome: GLS mixing is fairly doing its job, provided that the upper layer is well represented ...

[rsignell]

That is pretty amazing, and shows that having some way to represent the shallow region and deep region with a different number of vertical levels (sigma-over-z, z-over-sigma) would pretty much solve your problem. Clearly your workaround is not a viable solution for your 10 m shallo shelf region, which is now 30 m deep! John Warner and I were brainstorming this issue and John was wondering whether we could have masking of s-coordinates just like we have masking of horizontal curvilinear coordinates. That would make it possible to not have to follow the bottom exactly. But that would be bring up a number of other complications.

[arango]

Yes, we know about this. This is associated with grid steepness and advection discretization. The default upstream-bias advection may induce excessive diapycnal mixing in highly stretched vertical coordinates. Check my presentation at the Grenoble workshop last year. Try TS_MPDATA in the old grid to see if that reduces the diapycnal mixing.

We implemented the split advection scheme but it is still unstable and more work is needed. I need to back to this when I have the time.

[jacopo]

I have been running MPDATA in the last days as well. Indeed, results are much better compared to UH3/C4V.





I think I can finally converge now to a solution with some adequate stretching somewhat in between the two grids considered.

Clearly your workaround is not a viable solution for your 10 m shallo shelf region, which is now 30 m deep!

Actually I realized that this affects really a negligible part of the domain in this application. It's damned steep. But yes, I wouldn't suggest to use this 'workaround' in the Northern Adriatic 'swimming pool'

thanks for your feedbacks

Jacopo