Keith Lindsay (Feb 28 2020 at 16:27): Keith Lindsay (Feb 28 2020 at 16:27):MARBL/POP runs 2 ALT_CO2 tracers, for DIC and ALK. While we probably want the ability to disable these 2 tracers eventually, it looks to me like it is non-trivial to add such functionality to MARBL (based on a quick skim of the code). There are many lines of code scattered throughout that rely on ALT_CO2 related variables.
option 1: bite the bullet and add the ability to disable these 2 tracers
option 2: pay the computational cost of running with these 2 tracers
If we go with option 2, and the options for ATM_ALT_CO2 are the same as ATM_CO2, then the ALT_CO2 diagnostics will not be written out. That said, I think it is natural to ask if we can select options for ATM_ALT_CO2 that makes these 2 tracers useful. For example, would we gain anything by setting ATM_ALT_CO2 to 2xATM_CO2?
So option 2 splits into
option 2a: set ATM_ALT_CO2 options the same as ATM_CO2, and have no ALT_CO2 diagnostics in output
option 2b: use different ATM_ALT_CO2 options, to get some science out of these 2 tracers
Thoughts?
Michael Levy (Feb 28 2020 at 16:37):I don't have strong feelings either way. On one hand, I think disabling the alt_co2 tracers when they are redundant would be a useful feature in MARBL. On the other hand, I don't have a good initial estimate for (a) how much [person] time it would take to modify the code, or (b) how much [computational] time would be saved by reducing the tracer count.
I guess my gut reaction would be to leave the tracers in -- I like option 2b if there is some useful science to be gleaned with 2xCO2 or present day CO2 or something along those lines. I'm not going to defend that position if someone else has a better argument for doing something different.
Matt Long (Feb 28 2020 at 17:16):Thanks @Keith Lindsay, this is a very good point.
@Michael Levy, can you spend about 10-15 min to make a quick estimate of the level of effort required to turn ALT_{DIC,ALK} off in MARBL?
with option 2a, we could simply delete the extra data.
option 2b is intriguing. What about a pulse? A single year of elevated CO2, for instance?
Keith Lindsay (Feb 28 2020 at 17:36):If ATM_ALT_CO2 is configured identically to ATM_CO2 then the ALT_CO2 diagnostics will not appear in the tavg_contents file (unless there's a bug in the scripts). So no cleanup effort is required for 2a.
For 2b, I'm not sure if a sustained elevated value or a pulse is more amenable to analysis. Whatever we do, we should replicate the settings in a low-res analogue for comparison.
One could also consider a comparison to an existing low-res coupled CMIP run (e.g., 4xCO2). However, the comparison would not be clean, as we are planning on using explicit calcifiers here. So that may be a moot point.
Michael Levy (Feb 28 2020 at 18:12):@Matthew Long Barring unforeseen issues, I'd say it could be done in a day (including running tests in 3 deg or 1 deg POP). If some of the details turn complicated, it would probably add another day or two to work out? But I think it's contained enough that it shouldn't take more than that.
Longer answer: I think the process for removing the tracers would be
1. Add a new settings flag (named something like alt_co2_tracers_on) with default value of .true.
2. Modify marbl_interface_private_types:tracer_index_constructor to only define dic_alt_co2 and alk_alt_co2 if alt_co2_tracers_on == .true.
3. Modify marbl_init_non_autotroph_tracers_metadata to only define metadata if alt_co2_tracers_on == .true.
4. Grep for dic_alt_co2_ind and alk_alt_co2_ind, make sure the indices are only referenced if alt_co2_tracers_on == .true.
At that point, I would be tempted to just run a stand-alone test and see where else the alt_co2_tracers_on == .true. check needs to be made. The alt_co2 structure bleeds into the carbonate_type and some surface flux types, but I think we'd be okay allocating memory for those even if we don't access them.
Michael Levy (Feb 28 2020 at 21:58):After talking with @Keith Lindsay , he points out that the above proposal wouldn't go very far towards disentangling the alt_co2 tracers from the base tracers. A much more extreme option would be to go so far as to make alt_co2_tracers_on equivalent to ciso_on (and creating marbl_alt_co2 modules where computation is done), and a more realistic approach would be to keep the alt_co2 code in the same fortran modules as the base tracer computations but try to split apart the computations as much as possible to at least start on a path towards a truly separate tracer module. This starts to tie in with https://github.com/marbl-ecosys/MARBL/issues/154 (MARBL issue re: modularity and making it easier to turn groups of tracers on and off).
I think a less-kludgy implementation that would help us move towards a solution for #154 would take somewhere in the neighborhood of a week and a half or two weeks, and a full-fledged splitting of the fortran modules would be an additional week or so? That's just based on a cursory glance at what would be involved.
In the mean time, I'll copy some of these thoughts into a MARBL issue ticket. I think github would be an appropriate place to continue discussions on possible implementation details of turning off the alt_co2 tracers, while this channel can stick to discussing what to do in the high-res run
Matt Long (Feb 29 2020 at 04:11):Thanks Mike. I think we should probably drop consideration of optionalizing ALT_CO2 tracers for the hi-res run.
Matt Long (May 13 2020 at 21:08):@Keith Lindsay and I have discussed boundary conditions for DIC_ALT_CO2: we are leaning towards a single pulse in the atmospheric boundary condition of n (perhaps 5) years in duration.
Keith Lindsay (May 13 2020 at 21:51):The initial transient in annual air-sea CO2 flux in the CESM2 OMIP JRA run seems to be less than 10 years. Screen-Shot-2020-05-13-at-3.44.40-PM.png
The timeseries for the full run, including the historical CO2 ramp, is the blue line in spinup.POP.global_no_ms.FG_CO2.g.e21.GOMIPECOIAF.T62_g17.CMIP6-omip1.001.png
So I propose having the impulse occur during years 16-20.
Keith Lindsay (Dec 04 2020 at 20:53):Darn, we forgot to have an impulse of atm_alt_co2_const for years 0016-0020.
The run is currently in year 0027 (latest model date = 00270302).
How about we put in the impulse in years 0028-0032?
Matt Long (Dec 04 2020 at 20:53):Yes!
Michael Levy (Dec 04 2020 at 21:00):Did we decide on a value for the pulse? I think I see 2x, 4x, and present day all floated in this topic. And just to clarify, I'm going to add the following to user_nl_pop:
atm_alt_co2_const = NEWVAL ! originally 284.317
Matt Long (Dec 04 2020 at 21:01):2x seems reasonable to me.
I think you have the mechanism correct.
Michael Levy (Dec 04 2020 at 21:02):Cool, once the current year ends I'll set it to 568.634
Michael Levy (Dec 06 2020 at 15:19):I just started the 2x CO2 portion of the run; I think we have enough allocation left to get through two years and maybe four or five months before I'll need to switch account keys
Last updated: May 16 2025 at 17:14 UTC