Variable sinking rates in WOMBAT-lite

[pearseb]

Add a spatially variable sinking rate into WOMBAT-lite, although alternatives may need to be found, such as instead adding an explicit DOC (dissolved organic carbon) tracer.

[pearseb]

Starting this now.

I was going to use BLING as the format to introduce the variable sinking scheme that has been used in the development of WOMBAT. However, it looks like BLING has variable sinking rates but does this implicitly rather then explicitly. They do not carry actively sinking tracers that are affected by the ocean circulation, which is what we want for WOMBAT.

This is a problem. There are two solutions as I see:

1. We may need to introduce a new tracer, called dissolved organic carbon (DOC), which accumulates in the gyres and in a sense is what the variable sinking scheme was originally designed to emulate. Low sinking rates in the gyres in the development of WOMBAT was intended to emulate the high amounts of suspended organic matter that exist in the gyres and is rapidly recycled by the plankton community here.
2. We make sinking speed constant, but we develop a complex representation of the remineralisation term that (i) increases with nutrient limitation (emulating bacteria outcompeting phytoplankton, or alternatively commensalism/mutualism between phytoplankton and bacteria) and (ii) decreases linearly with depth to emulate the increase in sinking speeds with depth.

[dougiesquire]

Another option could be to extend the generic tracer vertical diffusion routines to allow spatially varying sinking rates

[pearseb]

But vertical diffusion is not sinking right? Or is this where the sinking is handled by MOM?

If it is possible to extend the vertical diffusion routines to allow variable sinking rates, this would be really good going forward because there is a lot of theory and research about how the size and excess density of particles controls sinking speeds in seawater and it would be good to tap into this for developments/research in the future.

[dougiesquire]

Yeah, the sinking is handled as part of the vertical diffusion routines in generic tracers. I can't say off the top of my head how easy it would be, but worth looking in to.

[pearseb]

Hmmm... I will need help with this stuff. Can we talk to someone who is at work currently at ACCESS-NRI to help with this part of the dev? I can also reach out to people at CSIRO who are more numerically gifted than me or more familiar with the vertical tracer routines.

[pearseb]

I found something. This is in generic_tracers_utils.F90

I don't fully understand what's happening in this piece of code, but it's potentially where we would include variable sinking.

[dougiesquire]

@chrisb13 maybe could help?

The (constant) sinking is handled in the g_tracer_vertdiff_ routines.

I haven't looked in detail, but it looks like there's already the ability to specify a 3D "vertical movement" field for prognostic tracers. I think the intended application is for migration, but perhaps we could use this for spatially variable sinking in WOMBAT?

[dougiesquire]

Snap!

[pearseb]

Okay I'm going to move onto some revisions and writing, but this looks promising. I'd like to meet with you @dougiesquire and @chrisb13 at some point to see whether it would be possible to modify the generic_tracer_utils.F90 file so that we can implement variable sinking in MOM.

Specific questions I have are:

1. How do we implement this so it is uploaded to the GFDL trunk with WOMBAT? We want WOMBAT to be included in GFDL's Git right?
2. How do we ensure that this works with MOM5 and MOM6? Particularly since the vertical spacing is so wacky in MOM6 with those µm thick layers.

[dougiesquire]

I'd like to meet with you @dougiesquire and @chrisb13 at some point to see whether it would be possible to modify the generic_tracer_utils.F90 file so that we can implement variable sinking in MOM.

If we calculate the vertical movement from sinking within WOMBAT, I'm not sure we'd need to modify generic_tracer_utils.F90 at all. But yes, happy to meet and chat.

[chrisb13]

Also happy to meet and chat.

[pearseb]

Let's go tomorrow? When's good for you Dougie?

[chrisb13]

Flexible for @dougiesquire but might have a meeting with the US, likely morning here. Afternoon is mostly safe (except for 2:15-4pm)

[dougiesquire]

Apologies I can't do today and I'm away next week. Could do the week after

[pearseb]

Okay let's leave this for a moment and come back to it when Dougie's back. I have plenty to get on with in the meantime, although I am a bit nervous about the end of November coming up and having WOMBAT-lite working properly in generic tracers by the end of year.

[pearseb]

Update @dougiesquire @chrisb13.

I've managed to the get the "move_vertical" functionality working with WOMBATlite. My detritus tracer is now sinking using this function.

However, the sinking tracer is not being deposited to the sediments at the bottom grid cell, and so it is accumulating to unrealistic values in the water column just above the sediments. Due to the complexity of the code, I might need some help figuring this out. I will continue to work on it in the meantime though.

Below is figure of what I'm talking about. You can see the accumulation of detritus in the bottom grid cell on shallow shelves. Note that the scale is a log10 scale, so the peak value there is 200 mmol/m3 of organic carbon, when typical values in productive waters are < 3.

[pearseb]

Looks like two different tri-diagonal solvers are called in MOM...

When move_vertical is set to .false., MOM uses GOLDtridiag to solve the vertical diffusion of the tracers and the vertical sinking according to a constant sinking speed via the sink_rate option. However, when move_vertical is set to .true., MOM uses IOWtridiag to solve for the vertical diffusion and the vertical movement of the tracer.

The code snippet that shows this decision tree is here in the generic_tracers_utils.F90 file:

GOLDtridiag calls the g_tracer_vertdiff_G subroutine, which takes sink_rate and move_vertical into account, but in reality never uses the move_vertical functionality because when this is true, MOM solves vertical tracer movement via IOWtridiag. This function does solve for the passing of tracer out of the deepest grid cell into a bottom reservoir if the btm_reservoir option is set to .true..

IOWtridiag calls no additional functions or subroutines. It solves the vertical movement of tracers without any consideration of sink_rate, only move_vertical via the g_tracer%vmove(i,j,k) array. It does not have any consideration of btm_reservoir, so it does not pass any tracer into the sediments.

TLDR: I will need to build a consideration of btm_reservoir into the IOWtridiag solver, extending the g_tracer_vertdiff_M subroutine within the generic_tracers_utils.F90 file.

[pearseb]

I've implemented the change to the g_tracer_vertdiff_M subroutine within the generic_tracers_utils.F90 file. It looks like this:

NOTE that most of the changes above are just syntax repositioning of the lines. The actual changes in code are

and

These changes compiled successfully and I'm running tests.

[pearseb]

Success!

The bottom reservoir is accumulating and detritus is moving from the ocean into the sediments through the bottom of the ocean model.

[pearseb]

Takes ~40 minutes to run 1 year.

======================================================================================
Resource Usage on 2024-11-14 15:04:00:
Job Id: 128602083.gadi-pbs
Project: p66
Exit Status: 0
Service Units: 371.04
NCPUs Requested: 288 NCPUs Used: 288
CPU Time Used: 153:18:21
Memory Requested: 1000.0GB Memory Used: 202.77GB
Walltime requested: 10:00:00 Walltime Used: 00:38:39
JobFS requested: 600.0MB JobFS used: 8.16MB

Variable sinking rates working well. Passing detritus into bottom reservoir. All looking well. Will create a pull release.