Does spreading sea ice freshwater flux over multiple layers reduce sensitivity to resolution?

[adele-morrison]

@pedrocol has been finding strong sensitivity of his basal freshwater runs to what depth range the freshwater flux for sea ice formation is extracted from.

Check out this paper that experiments doing the sea ice brine rejection in NEMO over a fixed depth instead of just the top layer, Barthélemy et al. 2015: https://www.sciencedirect.com/science/article/pii/S1463500314001966

I think this could be worth testing. @pedrocol has already implemented this scheme to distribute the sea ice freshwater fluxes over depth, so we could rerun the control in ACCESS-OM2-01 with this vertical distribution, and then repeat the 1m, vs 5m top layer vertical thickness experiments. If the DSW is no longer sensitive to the top vertical thickness when sea ice fluxes are spread over depth, then this could be a nice recommended solution for future model configs to avoid this spurious behaviour we've been seeing.

[adele-morrison]

This paper (Sidorenko et al. 2018) is also relevant.

[pedrocol]

After conversation we decided to implement the distribution at depth of wfiform array uniformly in the first 5 meters.
Should we limit this in latitude? In my experiments I limit the extent to 60S, which is where the iceberg array is inserted

[pedrocol]

I think I've seen some Arctic plots, so I didn't limit this to 60S. The executable is

/home/552/pc5520/access-om2/bin/brine5m_wilton/fms_ACCESS-OM_97e3429-modified_libaccessom2_1bb8904-modified.x

You'll need to include these two lines in your diag_table file, 2d and 3d brine rejection arrays.

"ocean_model","brine_fwflx","brine_fwflx", "ocean_monthly_3d_basal","all",.true.,"none",2
"ocean_model","brine_fwflx2d","brine_fwflx2d", "ocean_monthly_2d_basal","all",.true.,"none",2

[willaguiar]

That was fast - Thanks! I believe the important regions would be along the coast, where DSW is formed, so 60S would be alright ( I imagine FWF on the northern boundary of the SO sea ice would have very low impact here.

[adele-morrison]

I reckon no latitude limit is good Pedro. So fast!!

[pedrocol]

Give it a try for a few months, if you see any differences in the Equator (far from sea-ice formation regions), we should use the exact same code version you are using

[willaguiar]

@pedrocol , the model has been looking for the file INPUT/ocean_month_output_GPC010_calving_365_final.nc. I imagine that if this is a prescribed FWF from calving (vertically/horizontally distributed) then we don't want these fluxes in our simulations, so we can match them with our OM2 previous case?

[pedrocol]

They were set to zero, but I forgot to comment the import of the files, it should work now. Still the same filename for the exe file:

/home/552/pc5520/access-om2/bin/brine5m_wilton/fms_ACCESS-OM_97e3429-modified_libaccessom2_1bb8904-modified.x

[willaguiar]

Thanks! Looking for INPUT/basal_fw.nc (U might have to comment that one too :) )

[pedrocol]

Sorry for this, I double checked the logicals and they work fine now, you just need to add the following lines to your ocean namelist:
&ocean_basal_tracer_nml
use_basal_module = .false.
use_icb_module = .false.
use_brine_module = .true.
/
It should work now

[willaguiar]

No worry - and thanks!

[pedrocol]

I just tested the new module and is fine now, there was still a problem in reading the namelist in get_ocean_sbc

         Control                                      -                          Control+brine

As we can see control pme (-2.6e11) = pme (8.86e11) + brine (-1.14e12), this means that the part of the code that splits pme and fills the brine array works correctly
Also, in Control+brine, Mass from sources = brine, this means that the brine module works fine and no other sources (like basal or icb) are accounted.
Note as well that basal and icb = 0.

Sanity checks:

• Check that wfiform = brine2d
• Check that sum in the vertical of brine3d = brine2d
• Check that brine3d is uniform in the first 5 meters (plot a vertical profile of brine3d for a single point)
• Last, check that the sst in the control+brine run equals the control run in regions far from sea-ice formation (check that the code version is the same)

[pedrocol]

I tested this for 1 month, sum(brine2d)=sum(wfiform)=-177.17 kg m2/s

However, sum(basal3d) = 183.2 kg m2/s (3% difference). The reason for this may be that we are dealing with very small numbers (10e-4) and that the output precision is simple precision (8 digits) or that python handles by default simple precision.
Moreover, most of the differences seem to be coming from places where numbers are smaller:

Then I checked brine3d/dz for a specific point, and the profile is linear and it only concerns the first 3 points

I checked the brine3d ncfile, and it only has values for the first 3 vertical levels.

So, I think this is validated and ready to run, @willaguiar you just have to check sst or sss far from sea-ice formation regions to check that the code version is the same.

[willaguiar]

I tested this for 1 month, sum(brine2d)=sum(wfiform)=-177.17 kg m2/s...
So, I think this is validated and ready to run, @willaguiar you just have to check sst or sss far from sea-ice formation regions to check that the code version is the same.

Hi Pedro, thanks for checking that... I did some analysis after running the model for a few months, and it doesn't seem to me that the difference of brine2d and brine3d drifts along the time, so the precision explanation seems reasonable to me.

One thing I notice tho is that the brine is distributed over the first 3 levels, which makes reach down to 3.6 m (interface depth) instead of 5.06m that we wanted. So the ideal would be to make it distributed into the upper 4 levels. ( Sorry if I wasn't cleat that the limit was 5.06m instead of hard 5m). Could we change that?

[pedrocol]

Cool that everything works as expected.

I changed the code so it distributes brine over the first 4 levels, instead of setting a depth threshold, the executable is in

/home/552/pc5520/access-om2/bin/brine_kmax4_wilton