Change in shelf freshwater budget

[adele-morrison]

How does the freshwater budget, and its components, integrated over the shelf change? There will be changes due to the input salinity of the basal melt, changing salinity restoring, changing sea ice formation/melt, other air-sea FW fluxes (evap), and cross-slope transports of fresh/salty waters.

[claireyung]

Some plots of relevant variables (I think) using the last 5 years of each simulation

Also, can I have some help with the salt budget? I don't understand whether the output (in kg/m^2/s) is masses of salt or water? @adele157

[adele-morrison]

The salt fluxes are in kg of salt and the freshwater fluxes are in kg of freshwater, so you need to convert between to compare them. e.g. see how it's done in the SWMT notebook: salt_transformation = haline_contraction*(SSS*pme_river-(sfc_salt_flux_ice + sfc_salt_flux_restore)*1000)

So to convert a salt flux to a freshwater flux you divide by SSS (in g/kg), then multiply by 1000 (to convert from g to kg of salt). Note also you need to consider the signs - a positive freshwater flux increases buoyancy, while a positive salt flux decreases buoyancy.

[adele-morrison]

Might be helpful to compare the same years for each simulation and maybe do some integrals over the shelf?

[claireyung]

Year 2155 (sixth year) freshwater fluxes integrated over the shelf

Using sign conventions and code from https://github.com/COSIMA/cosima-recipes/blob/master/DocumentedExamples/Surface_Water_Mass_Transformation.ipynb

Edit: note iceberg and basal are slightly wrong as I should be using the haline expansion coefficient in 3D, not just the surface. Will update when I get it to compute.

[adele-morrison]

Ok, here's an attempt to explain what is going on here:

• pme_river is the freshwater flux from precip, evap, runoff and sea ice formation/melt. I'm guessing this is dominated by removal of freshwater from the ocean to form sea ice. So this becomes more negative because we have more sea ice formation, so we're removing more FW from the ocean over the shelf. There's also a contribution to this term from the runoff - in the control the runoff is positive, but in the basal and iceberg runs this runoff term decreases and then goes to zero as it's replaced by the basal and iceberg terms. Might be useful to split this term into 1) runoff (or equivalently, river), 2) melt, and 3) the rest?
• ice is the salt flux from sea ice - so we're getting more brine rejection when there's more sea ice formation. It would make sense to combine this with melt from the previous term.
• restore is salt restoring - that doesn't change much, which is good to see.
• basal and iceberg are the the FW fluxes that are replacing the runoff term. These could be merged with the runoff term split off from the first term, which then should be constant across all experiments.

[PaulSpence]

Good ideas. But most of those steps involve making the shelf saltier (e.g. more sea ice formation) ... why does DSW formation decrease with icebergs if the shelf gets saltier? e.g. https://github.com/pedrocol/basal_mom5-collaborative-project/issues/28#issuecomment-1473187838

[adele-morrison]

Yes, good question, and not sure @PaulSpence.

@claireyung what's the net change in freshwater fluxes over the shelf (i.e. sum of bar plot above)? Looks to my eye like the sum is negative, i.e. the change in surface fluxes in iceberg and basal runs should increase salinity of the shelf.

I guess we also need to look at advection of salt by the ocean across the slope, or compute this as a residual from the salt volume budget change.

[claireyung]

We discussed in yesterday's meeting that the salt content budget and mass of water budget should each close and that salt content is maybe easier than freshwater.

I am able to close the global ocean salt content budget for the control with the change in salt content (in kg) over a time period being equal to the time-and-surface-area-integral of sfc_salt_flux_ice and sfc_salt_flux_restore, the latter of which is small (there is a tiny bit left over which maybe has to do with salt in the ice?)

For the basal and iceberg experiments, to close the global ocean salt budget I need to include salt_basalmix and salt_icbmix. What do these terms mean? (If it helps, the long name/units of salt_basalmix is basalmix*rho_dzt*tracer for salt | kg/(sec*m^2)) They are negative -- does this mean the basal melt removes salt?

We can then find the residual between salt change on the shelf (which is negative, i.e. shelf freshens in both experiments) and salt change created by these fluxes. This residual should be the transport of salt onto the shelf over the time period. Below is a figure for the shelf for first 10 years which suggests that the transport of salt onto the shelf increases in the perturbation experiments compared to the control. (This should be checked with a cross-contour salt transport analysis)

However, pme_river is significant (freshwater flux, see above comment), and changes the amount of water I assume. So, the resultant salinity is not just from salt content. How do we/do we need to include freshwater in this analysis?

[aekiss]

Nice work @claireyung. I don't understand how basal and iceberg melt could alter the global salt content though - yes, they displace salt with freshwater locally, but this should just move the salt somewhere else, not change the total mass of salt in the ocean, right?

[pedrocol]

Nice work Claire, thank you! Salt_basalmix is the salt flux due to basal. As in ocean_rivermix, the tendency in salt is calculated as a salt mass balance. If the input salinity of basal/ice/runoff is zero, the result will be a dilution and therefore a negative trend in salt. The variable that saves the runoff salt flux is called salt_rivermix, but so far hasn't been saved. It would make sense if we talk about salinity, but I'm not sure if it is the case if we talk about salt content (Andrew's comment). In fact the budget is closed considering this zero salinity (in 'tracer_change') and not the negative trend (runoff/basal/icb). So, don't know what to say, I think there is a definition problem for all three river, basal, icb.

[StephenGriffies]

I am admittedly a distant participant here and might be stating the obvious. So my apologies. But I wish to point to an important issue that often confuses the discussion of salt budgets. Namely, we need to not confuse "salt" with "salinity".

"Salt" is the mass of ocean salt matter that is measured in kg. "Salinity" is the mass of salt per mass of seawater: it is dimensionless or in ppt.

When fresh water is added to the ocean, salt does not change while salinity is reduced through dilution. Conversely, when fresh water leaves the ocean then salt stays the same yet salinity increases.

There is no sense to performing a "salinity budget" since that conflates to budgets for matter (fresh water and salt) to produce a salinity budget that has sources. Instead, when doing a budget analysis it is more useful to consider budgets for matter (or potential enthalpy) that satisfy conservation equations without source terms. Yea, we can study equations with sources (e.g., vorticity equations, momentum equations), but they are tougher than scalar equations written for conservative tracers.

The MOM5 prognostic equations and diagnostic budget equations were written with the above notions in mind. If you wish to instead study the salinity equation rather than the salt equation, then that enters into murky waters both so far as code is concerned and interpretation.

[adele-morrison]

This seems quite problematic! I just talked over @claireyung's salt budget diagnostics with her and it looks all correct to me. In the global budget, the control closes nicely (i.e. salt flux to ice matches ocean salt content change). The basal case also closes nicely for a global budget when salt_basalmix is included.

From @pedrocol's description of how we're putting in the basal melt, I thought the input water had a non-zero (positive) salinity, to ensure it follows the Gade line. But salt_basalmix is definitely negative and the global integral of salt content in the ocean is declining, which means we must be putting in basal melt with a negative salt content? @pedrocol can you link us to the lines of code where you specify the salinity / salt content of the input basal meltwater?

[pedrocol]

The code can be found in https://github.com/pedrocol/basal_routines/blob/master/MOM_routines/easterlies/ocean_basal_tracer.F90, lines 620 to 626. In this code the negative trend added to T_prog('salt') is obtained with a mass balance: (QS_insitu + qS_basal)/(Q+q), where Q is the mass of the cell, q is the FW flux, and S_basal is zero (therefore dilution). Since the cell volume is kept constant over time (at depth), the only way to represent a dilution is with this negative trend.

In 'tracer_change' the budget is closed in the following way. First a tendency is calculated (th_tendency below) and then different sources are subtracted (included basal). Since the total salt contribution is zero, the total trend is included in th_tendency (https://github.com/pedrocol/basal_routines/blob/master/MOM_routines/easterlies/ocean_tracer_diag.F90 line 2218).

In the tracer budget : ----Single time step diagnostics for tracer salt---- Total tracer in ocean at time (tau) = 4.76678284824040899E+19 kg Total tracer change in system for (taup1-taum1) = -3.61572315447549438E+09 kg Total tracer input to ocean = -2.40388356407042456E+09 kg Tracer input via surface fluxes = -2.40388356407042456E+09 kg Tracer input via bottom fluxes = 0.00000000000000000E+00 kg Tracer input via open boundaries = 0.00000000000000000E+00 kg Tracer input via precip-evap+melt = 0.00000000000000000E+00 kg Tracer input via river runoff = 0.00000000000000000E+00 kg Tracer input via basal (runoff) = 0.00000000000000000E+00 kg Tracer input via icb (runoff) = 0.00000000000000000E+00 kg Tracer input via calving land ice = 0.00000000000000000E+00 kg Tracer input via sources in source array = 0.00000000000000000E+00 kg Tracer input via sources in th_tendency, or errors = -1.21183950971595764E+09 kg Tracer input via eta_t smoother = 0.00000000000000000E+00 kg Tracer input via pbot_t smoother = 0.00000000000000000E+00 kg .001d(SrhodV) = -3.63332087906832647E+09 kg Tracer mismatch: 0.001d(rhodVT)-input = -8.10818260954432475E+01 kg Mismatch converted to a surface flux = -4.16690889631324091E-16 kg/(m^2 sec)

Regarding the gade line, the input value of S_basal can be any value, we chose zero since is fresh water. Once obtained the negative trend in salinity with the mass balance, the gade line formulation is used to calculate the resulting temperature.

Perhaps the negative trend in salt content can be explained by the extra production of sea-ice. Can you please show the trends?

[claireyung]

Demonstrating the ocean salt content budget closure with these salt_basalmix and salt_icbmix terms and the negative salt content trend (calculated here), here are global sums of ocean salt content change and total salt flux x time for 10 years, years 2150-2159. The control has a much smaller magnitude so is shown on a different plot. The numbers of total flux x time vs salt content change in 10^12 kg are also shown below in the output to demonstrate closure (at least to 4sf).

@pedrocol, the salt input into sea ice is very small compared to the basal and iceberg fluxes.

[pedrocol]

I see, it has the effect of a really large negative salt trend, I'll take a look

[StephenGriffies]

The tracer cell volume is time dependent for all cells throughout the water column. That is because the thickness of a cell is time dependent. MOM5 is a generalized vertical coordinate model, and we are using z* as the vertical coordinate. So any assumption of constant cell volume is problematic. I am referring to the phrase

"Since the cell volume is kept constant over time (at depth),"

which is not correct.

[pedrocol]

The tracer cell volume is time dependent for all cells throughout the water column. That is because the thickness of a cell is time dependent. MOM5 is a generalized vertical coordinate model, and we are using z* as the vertical coordinate. So any assumption of constant cell volume is problematic. I am referring to the phrase

"Since the cell volume is kept constant over time (at depth),"

which is not correct.

Indeed, that was the case in NEMO's z*. No assumption regarding the cell volume was done in MOM5's code

[pedrocol]

@StephenGriffies I think I need a bit of help here. In the rivermix code, the contribution to the tendency (T_prog(n)wrk1) is calculated in the first level including the term river(i,j)*dtime and then in the subsequent levels without considering this contribution.

In my basal code I just calculate the tendency change as it is done in the loop, and I think the problem we are having is related with the missing basal(i,j,k)*dtime in the tendency.

Can you please explain me why the tendency in the first level is calculated in that way? In my mind the way it is calculated in the loop makes complete sense.

[pedrocol]

I've been taking a deeper look to the code, this is probably done in this way to counterpart the dilution due to the increase in eta tendency (by river/basal)

[StephenGriffies]

Sorry not to have time to dive into code att. I am swamped with teaching. In the meantime, please take a look at the documentation of the algorithm written in the MOM5 manual

https://mom-ocean.github.io/assets/pdfs/MOM5_manual.pdf

See the chapters in Part V. There are many ad hoc schemes formulated in that part of the manual, each based on mass and tracer conservation equations.

Note that some of the documentation is focused on MOM4.0, which only has a free surface and does not have a generalized vertical coordinate option. For MOM4.0 we only insert rivers at k=1. Enhancements to MOM5 allow for insertion of mass and tracers at any k-level.

I hope that by reading through some of these chapters you will get a sense for the basic formulation. Please ping me again in a day, when I will have a brief resbit before preparing for next week's lectures...

[pedrocol]

After discussion with Adele and Claire we arrived to the conclusion that the problem comes from the scheme implemented, since it doesn't conserve tracer.

The present scheme

The following scheme is the one implemented for rivermix, which conserves tracer

In both cases the FW flux happens in the top cell as an addition in eta tendency. This is because the rivermix scheme was inherited from MOM4, which considers a free surface and does not have a generalized vertical coordinate.

As the schematic shows, there are two processes happening at the same time, mixing with fresh water (qS_fw) and mixing of the volume displaced in the lower cell with its corresponding salinity (q(k+1)S_insitu(k+1)). With a resulting salt flux going from the bottom to the top. Another problem with this scheme when implementing it at depth, is that there is an inconsistency, since the upper mixing cell is at the shelf front and the volume change happens in the first vertical level.

We ended up with two alternatives: a) Make a new scheme that allows for an insitu cell thickness change (to avoid the vertical salt flux)
b) Keep the rivermix scheme as it is, but connect all the vertical cells up to the surface, by playing with the factor (delta(k)) that distributes the fw tracer at depth.

We obviously prefer the first option, what do you think @StephenGriffies ? How difficult to implement would this be?

[StephenGriffies]

Would you be able to do a Zoom evening of 3 April my time, say 9pm? That might be the simplest way for me to offer feedback. I can do another night this week if this does not work for you.

[pedrocol]

Yes, that would be great, thanks! it is New York time, right? Here is my zoom link https://unsw.zoom.us/j/9809108891

[StephenGriffies]

Yes, NY time. See you soon.

[adele-morrison]

I'll join too. For others who might be interested, this is 11am today. @claireyung @AndyHoggANU @aekiss

[adele-morrison]

Are we meeting now? I'm in your waiting room @pedrocol.

[pedrocol]

To summarise the discussion, the dilution should be coded as an increase in the cell volume (thickness), by adding the FW flux to the Thickness%mass_source array (valid for both salt and age). The negative heat flux is correct to coded it as a change in T_prog(index_temp)%th_tendency(i,j,k), as it was previously done. The gade line formulation gives a resulting temperature due to the change in salinity, so there shouldn't be any issue for the heat flux. The resulting salinity will have to be calculated inside the basal module as S_resulting = T_prog(index_salt)%field(i,j,k,tau) / (Q+q dt delta(k)).

@StephenGriffies Can you please point me to where in the code the change in Thickness%mass_source translates to a change in Thickness%rho_dzt? I can't find it

[adele-morrison]

Pedro, previously weren't we doing the weird 'bubbling up' thing with the temperature tracer? We don't need to do that now right?

[StephenGriffies]

Hi @pedrocol : Here is the algorithm in a nutshell.

--Fill the array Thickness%mass_source(i,j,k) wherever there is a source of mass per area: units are rhovelocity = kg/(m^2 sec). There are many places in MOM5 where this array is filled.

--Inside ocean_barotropic.F90, Thickness%mass_source(i,j,k) is summed over depth to get the net mass going into an (i,j) column. That sum then placed inside Ext_mode%source(i,j). Ext_mode%source(i,j) is used to time step the free surface.

--Inside ocean_thickness.F90, we update rho_dzt according to the updated free surface. This update is a function of the vertical coordinate. See the subroutine update_tcell_thickness. For example, with zstar we know how to update a cell thickness once we have the updated free surface.

--Note that the array Thickness%rho_dtz_tendency(i,j,k) is used for diagnostics to track what mass tendency was used as a function of (i,j,k). I recommend saving this diagnostic while developing the algorithm to be sure you are adding mass in the right manner. Add "rho_dzt_tendency" to the diagnostic table. This array is only for diagnostics, as it is not used prognostically time step the thickness (unless one chooses the "blob" method, which you are not using).

I hope that helps, but please follow up with more questions if needed.

[pedrocol]

Thanks for your detailed answer Steve. If I understood correctly, in that case the FW mass will be evenly distributed along the vertical column, from the free surface until the bottom. Since in our case we want to distribute the FW between two specific levels (i,j,k), I think we need to modify the update_tcell_thickness function directly, and affect Thickness%rho_dtz_tendency(i,j,k) with the value of basal3d(i,j,k).

[pedrocol]

Pedro, previously weren't we doing the weird 'bubbling up' thing with the temperature tracer? We don't need to do that now right?

In the previous case we were just extracting heat from each specific cell, the MOM4 scheme was not used. So we are ok from this side, no need to change how the heat is extracted.

[StephenGriffies]

Ok, so I had a bit more think on what is desired.

Alas, I said yesterday that MOM5 is akin to a layered model, in which we can place mass arbitrarily at depth. That is true. But since the model uses quasi-Eulerian layers, they are constrained to evolve only via the free surface (or bottom pressure for the non-Boussinesq cases). That sort of evolution means that layer thickness only changes by the manner I indicated; i.e., via the distribution of the free surface undulations throughout the depth via zstar. A terrain following coordinate model has the same approach. Consequently, there is no Eulerian method to evolve the layer thickness directly with the rho_dzt_tendency array. So I was wrong in conveying that message yesterday. Sorry.

There is a non-standard way to evolve according to rho_dzt_tendency. That approach is via the "blobs" code inside MOM5. The blobs is a Lagrangian model embedded in MOM5. Michael Bates did his thesis developing this code (he was a student with Matt England and me, and now teaching high school in Queensland). The code has not been exercised since Bates and then Kate Snow. My guess is that with some modifications that code could do what we want, and it would be a rather novel approach to doing the insertion. But it will take work, mostly to digest the code and then make the necessary modifications.

I am sorry that I only now appreciate the limitations of the standard MOM5 vertical coordinates for this melt task. We might need to consider suitable strategies...

[aekiss]

No worries @StephenGriffies, thanks for the clarification.

Let me know if this reasoning makes any sense:

It sounds like with z* it's unavoidable to distribute the FW uniformly into all depths in the column, even if we just inject at one level. If we inject M kg of FW at level k, the FW mass at level k will only increase by M.Hk/H (where Hk is the thickness of level k and H is total thickness), since the rest is redistributed to other cells in the column, increasing their FW mass in proportion to their thickness. So if each cell retains its salt mass, salinity is also reduced at all levels (ie both above and below k) and salinity at level k is higher than it should be, because the level k FW mass was not increased as much as it should have been.

If this picture is correct, would it be reasonable to redistribute salt mass from level k to levels above and below, like the 'bubble up' but in both directions, in proportion to the redistribution of FW mass? This is, to redistribute salt (and other tracer) mass from level k to the other levels in the same way as FW mass, immediately after your third step above:

--Inside ocean_thickness.F90, we update rho_dzt according to the updated free surface. This update is a function of the vertical coordinate. See the subroutine update_tcell_thickness. For example, with zstar we know how to update a cell thickness once we have the updated free surface.

[adele-morrison]

Thanks @StephenGriffies!

Is it worth discussing the merits of: a) doing this through the artificial vertical movement of salt in MOM5 as suggested above, or b) doing it in the MOM6 PanAntarctic config instead, where we could correctly insert FW at depth with no salt movement required?

[StephenGriffies]

I concur with @aekiss interpretation. We are hitting the limitations of the vertical coordinate, so that a change at one level that effects the free surface will, in turn, be felt throughout the column. Again, this sort of non-local effect is inherent in the quasi-Eulerian layered approach.

I am unsure of the best strategy...pursuing the salt redistribution in MOM5 or a true water insertion approach in MOM6. I am happy to have a strategy chat to assess. I can do Wed or Thur night my time if that suits (nights of 5 or 6 April in Princeton).

[pedrocol]

@StephenGriffies we are meeting tonight (night of April-5) at 19h30 (New York time), normally until 21h. Let me know if you are available, otherwise we can find another time slot.

[StephenGriffies]

I will plan to be there.

[pedrocol]

I also agree with @aekiss, just wanted to mention that in the control run, this mass distribution in all levels is also done, so for comparison ends we may want to keep it that way. Another possibility, is to make the salt extraction as we did, but put the tracer displaced (tracer_extra) entirely in the first cell, as it is done in the control run. In that way we would have an experiment which can be directly compared with the control one.

[adele-morrison]

@StephenGriffies, we have a question for you:

We have been thinking about how a basal flux compares to a surface precipitation flux and are very confused. When freshwater is added to the surface (or upper ocean) for precipitation and runoff, this would also cause an increase in the height of the water column and increased thickness of all z* cells over full depth. This would result in reduced salinity over the whole water column, not just in the surface grid cell. But clearly there is something wrong here, because we know that adding precipitation to the surface impacts the surface buoyancy, but not the deep buoyancy.

What's wrong in our thinking here? And can we apply this same method as used for precip to our basal flux?

[StephenGriffies]

Thanks for this question!

It prompted me to write some notes on the budget equations. As a result of this exercise, I am now confident that MOM5 is a suitable venue to do the melt insertion experiments, and no algorithm changes are needed.

The key point we missed in our Zoom call is that when one inserts mass into a k-cell, there is an associated divergence of the velocity that is induced by this mass source. The velocity divergence, combined with the change in cell volume, keep the salinity unchanged even while the salt content is changed. It is a very nice balance that is, as you suggest, just the same as for the P-E flux. The thought experiment I worked through is to start with a constant salinity ocean and add P-E so see that salinity is altered only at the k=1 grid cell, even though all grid cells have their volume changed. The same notion holds for an interior mass source. Turns out that I used this thought experiment in a paper in 2000 to introduce P-E to MOM4 with free surface.

So...I am back to thinking that no fundamental changes are needed for the code. We just need to sort out the mass source by removing all sources for the salt equation. Yet there must be a source to the heat equation since the fresh water has a heat content.

I will share the Overleaf for those interested in the details. But for those wanting just the highlights, the key point is to remember that a positive mass source induces a velocity divergence. We missed that in our Zoom, and only focused on the changes to the cell volume, which then led us to incorrectly conclude MOM5 is unable to do the melt insertion.

[aekiss]

Many thanks @StephenGriffies for this very clear and careful explanation, and it's great to know that we can proceed with MOM5. I've made a couple of very minor comments on Overleaf - should the PDF be shared here for future reference?

[StephenGriffies]

Thanks @aekiss for your edits. I accepted all of them.

I am happy to share on Github if you wish. Perhaps wait a few more days in case others have edit suggestions.

[pedrocol]

If I understood correctly, the change in tracer concentration is a consequence of the change of the vertical advection in the vertical (Adv_vel%wrho_bu). The vertical advection change affects the advective tendency of dzt rho tracer concentration (advect_tracer_mdppm, line 6189). Please correct me if I'm wrong.

In the previous version, I was adding the contribution of basal to the vertical advection (apart from the salt negative flux). ocean_advection_velocity.F90 (line 645) tmp(:,:) = Thickness%rho_dzt_tendency(:,:,k) - Thickness%mass_source(:,:,k) - L_system%conv_blob(:,:,k) - basal3d(:,:,k) Adv_vel%wrho_bt(:,:,k) = (tmp(:,:) + Adv_vel%diverge_t(:,:,k) + Adv_vel%wrho_bt(:,:,k-1)) & *Grd%tmask(:,:,k)

So we had two sources of tracer change: the negative trend and the vertical advection.

[StephenGriffies]

Hi @pedrocol .

Yes, tracer content changes from the mass source arise through the advection velocity, Adv_vel%wrho_bt.

There are many places in the code where Thickness%mass_source can be modified. All you need to focus on is modifying Thickness%mass_source.

Note that hickness%mass_source has units (kg water)/(m^2 * sec). Hence, when multiplied by the horizontal area of a grid cell, it gives the transport of water into that cell (kg/sec).

[pedrocol]

Thanks Steve, the document was great. I implemented the changes and ran it for 3 months, it seems to be working, below salt and temperature change averaged between 300 and 1000m (3 months time average)

The code is way simpler now, it mainly works with the new basal module. The main part of the code is below. I performed a heat balance using tbasal = - L_f / c_p to calculate the resulting temperature, and then I just add basal3d(i,j,k) to mass_source(i,j,k).

I think it will not be easy to implement the gade line, since we need to calculate the salt change due to the change in vertical advection, but I'm still thinking about this.

Thanks again!

[adele-morrison]

Thanks so much Steve for your efforts on this; it's nice to have such a clean solution rather than the salt shuffling compromise we were considering last week!

Pedro, can we still implement the gade line by computing the salinity change in each k cell just due to the input freshwater volume combined with the salt that was there before (i.e. before any vertical advection changes)?

On Wed, 12 Apr 2023 at 05:21, Pedro @.***> wrote:

Thanks Steve, the document was great. I implemented the changes and ran it for 3 months, it seems to be working, below salt and temperature change averaged between 300 and 1000m (3 months time average)

[image: middepth_salt] https://user-images.githubusercontent.com/23285319/231263758-967a9d07-dc71-4092-bb6e-89911d014e45.png

[image: middepth_temp] https://user-images.githubusercontent.com/23285319/231263767-a97fd504-2b55-4ad3-a95f-dfce97f146bb.png

The code is way simpler now, it mainly works with the new basal module. The main part of the code is below. I performed a heat balance using tbasal = - L_f / c_p to calculate the resulting temperature, and then I just add basal3d(i,j,k) to mass_source(i,j,k). [image: Screenshot from 2023-04-11 16-07-39] https://user-images.githubusercontent.com/23285319/231264430-427ec5fa-397c-4108-87d4-f8a079e7f14d.png

I think it will not be easy to implement the gade line, since we need to calculate the salt change due to the change in vertical advection, but I'm still thinking about this.

Thanks again!

— Reply to this email directly, view it on GitHub https://github.com/pedrocol/basal_mom5-collaborative-project/issues/36#issuecomment-1503972099, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACA44U37X6CZBZK2U6CYCZ3XAWVLTANCNFSM6AAAAAARKVEBHY . You are receiving this because you were mentioned.Message ID: @.*** com>

[pedrocol]

@adele157 The mass_source array affects the vertical velocity, and then the vertical velocity differential affects the tendency of the tracer. I think this happens in ocean_tracer_advect.F90 line 6470 (wkm1 = Adv_vel%wrho_bt(i,j,k-1)), and corresponds to equation 17 of Steve's document.

Now, we are only interested in the FW impact on Adv_vel%wrho_bt, which is Thickness%mass_source. So, I believe that \Delta S = dtime Tracer_field(i,j,k) / Thickness%rho_dzt(i,j,k,tau) ( Thickness%mass_source(i,j,k) - Thickness%mass_source(i,j,k-1)). In words, the salt change is a function of the volume change (FW flux differential), which make sense to me. But, I would need someone to corroborate this, the schemes are quite complex and is hard to follow.

[StephenGriffies]

I will try to give this a think on Thursday, after my lecture on baroclinic instability (not an easy lecture)...

[StephenGriffies]

Thanks to @aekiss for ongoing fixes to the Overleaf document.

In response to the question from @adele157 about computing salinity changes from fresh water, I added a few sentences to the end of the Overleaf that details the calculation. In a nutshell, at the point where we compute mass_source from the fresh water, we can compute the associated salinity tendency via

salinity tendency due to mass source(i,j,k) = -S(i,j,k,tau)*mass_source(i,j,k)/rho_dzt(i,j,k,tau).

That tendency can then be used for the Gade line calculation.

Make sense?

[pedrocol]

Hi Steve, sorry, but I think I'm missing something here. If we would input a mass_source(i,j,k) = rho_dzt(i,j,k,tau), this is a FW volume equivalent to the cell volume, the salinity tendency would be - S, and therefore the resulting salinity in that grid cell would be zero. With no salt advection to the surrounding cells (and therefore not conserving tracer).

While if we apply the formulation that is in the code \Delta S = dtime Tracer_field(i,j,k) / Thickness%rho_dzt(i,j,k,tau) ( Thickness%mass_source(i,j,k) - Thickness%mass_source(i,j,k-1)), the salinity in that grid cell (k) would still be zero, but all the salt content would be advected to the cell below (k+1, following the direction of integration from the top to the bottom).

I read the document many times, but it all make sense from the formulation point of view, so I don't know, maybe I'm missing something here.