Do not create two CO2 tracers

[gold2718]

• Only create one total CO2 tracer when a CO2 chemistry is running and co2_cycle is on
• When sharing total CO2 between co2_cycle and chemistry, do not create duplicate CO2 diagnostic fields
• The co2_cycle code will use the chemistry CO2 tracer (if it exists) as it's total CO2 quantity. The other tracers (for land, ocean and fossil fuel) are still locally created.

Addresses #1580

[gold2718]

While I tried to make this change relatively robust, I think there are a couple of weak points.

• The current solution suggestion is dependent on chem_register being called before co2_register.
• I am not currently making sure that CO2 is not on the non-transported list. I am not sure what to do about that potential case (i.e., throw an error).

[gold2718]

At a meeting about this, we decided that the diagnostic name for CO2 should be CO2 if the chemistry has CO2 as an active constituent and CO2esm if the constituent is created by the co2_cycle module.

However, I think it we would end up with two output fields for the same quantity. Currently, we already output all 3D constituent fields in diag_phys_writeout_dry (I think that is what is happening on line 972).

I think the same issue would affect the surface flux since those are also output using sflxnam in diag_srf.

Did I miss something or forget a detail? @klindsay28, @fvitt, @jimmielin, @nusbaume

[gold2718]

I can think of a couple of ways to implement the change above, however, we are not going to do this for NorESM (as among other things, it complicates post-processing and analysis) so I leave it up to someone from the CAM group to pick this up.

Some ideas for implementing CO2ems

• Change the name of the constituent from CO2 to CO2ems in co2_cycle.F90. I think this would effect the change but I'm not sure there is nowhere in CAM that would still look for or try to set CO2.
• Add a new array at the top of co2_cycle.F90. This could be called c_diag_names which would be the same as c_names except for CO2 ==> CO2ems. This new array would be used for addfld and add_default calls in co2_cycle and for outfld calls in cam_diagnostics.

[fvitt]

While I tried to make this change relatively robust, I think there are a couple of weak points.

• The current solution suggestion is dependent on chem_register being called before co2_register.
• I am not currently making sure that CO2 is not on the non-transported list. I am not sure what to do about that potential case (i.e., throw an error).

Probably should error out if CO2 is not transported. CO2 is a long-lived tracer and may never happen.

[gold2718]

Probably should error out if CO2 is not transported. CO2 is a long-lived tracer and may never happen.

Is this only if co2_cycle is on? It seems to me that it should also error out for GHG chemistry (which is a bit beyond the current scope of this PR).

[fvitt]

Probably should error out if CO2 is not transported. CO2 is a long-lived tracer and may never happen.

Is this only if co2_cycle is on? It seems to me that it should also error out for GHG chemistry (which is a bit beyond the current scope of this PR).

Yes only if co2_cycle is active.

[fvitt]

@lkemmons and @tilmes
Are you okay with the proposed changes in this PR for BGC compsets? This get around advected constituents naming clash when the chemical mechanism includes CO2. One issue I see with this is that CO2 could have chemical sources and sinks (reactions in the upper atmosphere) while the advected tracers CO2_OCN, CO2_FFF, and CO2_LND will not since they are not included the chemical mechanism.

[lkemmons]

@lkemmons and @tilmes Are you okay with the proposed changes in this PR for BGC compsets? This get around advected constituents naming clash when the chemical mechanism includes CO2. One issue I see with this is that CO2 could have chemical sources and sinks (reactions in the upper atmosphere) while the advected tracers CO2_OCN, CO2_FFF, and CO2_LND will not since they are not included the chemical mechanism.

I am not sure I do not fully understand the problem, but this sounds reasonable. You should ask Ben Gaubert - he has done more with CO2.

[cacraigucar]

FYI - At today's CSEG meeting today, it was pointed out that this PR needs to come in for the emission driven runs. We are targeting it for the next CAM CESM alpha tag. Please try to have reviews done soon - there is one CESM alpha tag in front of the CAM one (so maybe next week will be our turn)?

[cacraigucar]

@adamrher - Could you please take a look at this? Thanks

[tilmes]

@lkemmons and @tilmes Are you okay with the proposed changes in this PR for BGC compsets? This get around advected constituents naming clash when the chemical mechanism includes CO2. One issue I see with this is that CO2 could have chemical sources and sinks (reactions in the upper atmosphere) while the advected tracers CO2_OCN, CO2_FFF, and CO2_LND will not since they are not included the chemical mechanism.

Hi all, could you clarify: are CO2_FFF, CO2_LND, and CO2_OCN inert advected species in the atmosphere, and is CO2 advected and considered the sources and sinks of CO2 from land and ocean that sees also atmospheric chemistry? Just not suer if I understand this either.

[fvitt]

@tilmes
The co2_cycle module will add 'CO2_OCN', 'CO2_FFF', and 'CO2_LND' to the advected constituents array external to chemistry and thus will not experience any chemical tendencies that could be applied to CO2.

[tilmes]

@tilmes The co2_cycle module will add 'CO2_OCN', 'CO2_FFF', and 'CO2_LND' to the advected constituents array external to chemistry and thus will not experience any chemical tendencies that could be applied to CO2.

CO2 will change in the atmosphere due to chemical reactions (production of CO2) and loss through photolysis. Will the ocean and land "see" CO2 to derive new tendencies?

[gold2718]

@tilmes The co2_cycle module will add 'CO2_OCN', 'CO2_FFF', and 'CO2_LND' to the advected constituents array external to chemistry and thus will not experience any chemical tendencies that could be applied to CO2.

CO2 will change in the atmosphere due to chemical reactions (production of CO2) and loss through photolysis. Will the ocean and land "see" CO2 to derive new tendencies?

@tilmes, CO2_OCN and CO2_LND are updated from the surface. Those fluxes are also added to CO2. After that, they are inert tracers, useful for understanding emissions over time.

The fossil fuel flux (CO2_FFF) is entered from a file (in co2_cycle.F90) and that is also added to CO2.

When CAM communicates back to the surface, only CO2 is used so the ocean and land will "see" any changes due to chemistry and due to fossil fuel fluxes.

Something that came up in our meeting over this issue is that there is currently no mechanism to apply any CO2 tendencies back to CO2_LND, CO2_OCN, or CO2_FFF. I have no idea how this would or should be done (from a science point of view, a technical implementation would not be difficult).

[tilmes]

@tilmes The co2_cycle module will add 'CO2_OCN', 'CO2_FFF', and 'CO2_LND' to the advected constituents array external to chemistry and thus will not experience any chemical tendencies that could be applied to CO2.

CO2 will change in the atmosphere due to chemical reactions (production of CO2) and loss through photolysis. Will the ocean and land "see" CO2 to derive new tendencies?

@tilmes, CO2_OCN and CO2_LND are updated from the surface. Those fluxes are also added to CO2. After that, they are inert tracers, useful for understanding emissions over time.

The fossil fuel flux (CO2_FFF) is entered from a file (in co2_cycle.F90) and that is also added to CO2.

When CAM communicates back to the surface, only CO2 is used so the ocean and land will "see" any changes due to chemistry and due to fossil fuel fluxes.

Something that came up in our meeting over this issue is that there is currently no mechanism to apply any CO2 tendencies back to CO2_LND, CO2_OCN, or CO2_FFF. I have no idea how this would or should be done (from a science point of view, a technical implementation would not be difficult).

Thanks for the explanation. That sounds good to me. Yes, it will not be easy to map CO2 back to CO2_LND or CO2_OCN, but I suppose these variables give some way to get an idea of contributions from the different components.

[cacraigucar]

When everyone is happy with the changes, could someone please move it out of draft? The next CESM alpha tag containing CAM changes is waiting for this PR