Define workflow for Baltic boundary

[jpolton]

Nico's method is in James' head.
Extract knowledge and document here.

That then feeds into the domain_cfg.nc build.

[jdha]

Quick c&p of old emails to add to the discussion:

From: Bruneau, Nicolas P.R.
Sent: 04 April 2018 08:08:26

Hi all,

Brief update about the Baltic sea conditions. I think we should probably catch-up when I'm back from holidays next week and decide best solution to implement and move on to validation on long-term simulations and eventually some science and physics...

1 - I created a straight channel (see Fig01_*) and forced using sign(Ux) |U| at the border so only velocity across the section. I also smoothed AMM15 bathymetry to GETM bathymetry near the border (and switched to a rim width of 5)

2 - I moved to James interpolated on-the-fly lateral boundary conditions. This unfortunately leads to even weaker transport than the original run but I think this choice is better in term of physics as from computation at the Baltic border, using initial stretching or using the stretching at each time step can change the average transport by up to 15%.
ORIGINAL salinity transport : 0.27 psu.m/s
NEW transport : 0.20 psu.m/s
GETM transport : 0.80 psu.m/s

3 - I smoothed the shallow bathymetry (< 110m) to reach a max roughness of 0.6 - this mostly affects coastal individual points but we might want to discuss and not change the roughness in some areas like the German bight which is significantly affected.

4 - I enlarged some channels near Denmark as they could be very narrow. For example, the West one is, at some point, only 1 cell wide associated with a deep bathymetry going in diagonal preventing transport (see Fig02_*). This increases the transport by about 10%.

5 - As James pointed, the enveloping bathymetry could create some unrealistic bottom friction due to saw tooth succession of elements. As AMM15 is setup with a Rmax of 0.1, I smoothed the Baltic with this threshold in order to use the full 51 sigma level there. This has the most impact, almost doubling the transport.
NEW transport : 0.44 psu.m/s

6 - We might want to consider looking at deep channel that are only one element wide through the diagonal meaning "bottom water" is trapped (see Fig03_*). Having a hard smoothing as in this figure might not be ideal though.

7 - Finally, I also did a test where I changed the correction of the water level at the Baltic border as the free-ssh runs shows that the water level wants to adjust 25cm higher than the forced-SSH one. So I added 15cm and it leads to a transport of 0.67 psu.m/s (see Fig04_*)

8 - However, looking at ssh anomalies data from CMES products, it seems the model already has a gradient similar (even higher) than data and it does not make sense to increased it (see Fig05_*).

Cheers,
Nico

PS: these changes lead to creation of new restart. After changing it, I run few days with a small time step to adjust the conditions before re-increasing it. Enda reaches the same conclusion and methodology independently on his side.

[jdha]

Hi Nico,

Just to clarify point 5: when you've smoothed (I'm guessing you've either took hbatt from the code or used the ROMS tools) did the cross sectional area of the pinch points (i.e. the channels) change much? I think from memory there's an option to perform a volume correction in ROMS code, but this will be area-wide. My point being that the increase in transport may not just be down to removing the saw-tooth, it may also be down to an increase in the x-sectional area through the straits ... would be interesting to check.

James

[jdha]

Hi James,

It's a good point. It might be the expected behaviours but it puzzles me a bit (might have done something wrong in processing...)

It seems the bathymetry is almost exactly the same between the two cases (hbatt variables differs by something like precision 10^-6). The bathymetry fed to NEMO is very different from original one as the new bathymetry is a smoothing of the original one (via ROMS tools) with the same Rmax as the one defined in namelist_cfg meaning the algo in python is similar to the one in NEMO.

The only differences is that the mbathy (in new case) is systematically equal to 51 levels while before it was ranging from 25 to 51 levels in Baltic sea.

If there is no error in this processing, it means the effect is only due to the saw teeth elements...

Does this make sense ?
Cheers,
Nico

[jdha]

Hi all,

While ago we had this open discussion and I might have an hint.

It seems that 50-60% of the transport reduction in my case / setup is due to the saw teeth effects, the left over coming from the change of section and volume.

So removing the saw teeth and correcting the volume as less effect than both cumulated. Good to keep in my for future choices in AMM15

Cheers,
Nico