Receive ozone from atmosphere

[billsacks]

(Moved from https://trello.com/c/fHXntN8l/150-ozone-receive-from-atmosphere)

• add ozone stream to datm (Danica had diffs in datm_comp_mod in SourceMods, as well as some things she did for adding a new stream for her cases)

• add coupling hooks; to do this, incorporate diffs from clm_atmlnd.F90, clm_cpl_indices.F90, lnd_comp_mct.F90 in Danica's original branch (o3_amax_pft); also add coupling field seq_flds_mod (Danica had diffs in SourceMods)

• See bug report 2294 (now Receive surface ozone in CLM #134)

• determine how coupling to CAM will happen (see wjs comments below - 10-11-2016 and 12-27-16)

  • (2022-03-25) This is done: see cam6_3_045: Pass surface ozone concentrations to coupler CAM#404 and Add ozone field from atm -> lnd CMEPS#212 and Add module to read ozone_coupling_nl CESM_share#4. Briefly: the atm component will always send some ozone concentration. It will set a flag saying whether it's providing subdaily ozone values or a multi-day average. If the latter, CTSM will apply anomalies on top of the provided values, which CTSM will read from an anomaly file.

• add a forc_ozone history field (O3CONC_IN): see histFldsMod in Danica's original branch (o3_amax_pft)

• make ozone a required field from atm.

  • (2022-03-25) This is done: see Add ozone field from atm -> lnd CMEPS#212 and cam6_3_045: Pass surface ozone concentrations to coupler CAM#404

• Work with Francis for getting from CAM

  • (2022-03-25) This is done: see cam6_3_045: Pass surface ozone concentrations to coupler CAM#404

• add ozone as a cpl hist field (written by coupler, and then read by datm when running in cplhist mode)

• Read and apply diurnal ozone anomalies if the atmosphere forcing is smoothed

[billsacks]

Original comment from @billsacks 2016-10-11

For coupling to CAM: It seems like ozone will only be available when running with chemistry. I can see a few options here:

Have CAM (and datm) set a flag like atm_provides_ozone in the coupler in initialization (in seq_infodata?). Then, if ozone is on in CLM, then CLM checks whether this flag is set; if not, aborts. (This would depend on atm init happening before lnd init, I think.) This would be simple if it works, but probably isn't the most robust solution.

Can we use the drv_flds_in functionality? CAM can add ozone to its list of fields if running with chemistry; datm can always add ozone to its list of fields. Then CLM can abort if use_ozone is true but the ozone field index isn't set.

Have ozone controlled via an xml variable. Set USE_OZONE=TRUE to turn on ozone; this (a) turns on the CLM use_ozone namelist variable; and (b) tells CAM/DATM to send ozone. CAM should check at build-namelist time to confirm that USE_OZONE is only true if it is running with chemistry.

@ekluzek thinks that it makes sense to use drv_flds_in (i.e., option 2). CAM will add the ozone field if it's running with a chemistry configuration that supports it. When running CLM offline, we'll either (a) have CLM add ozone to drv_flds_in when use_ozone is .true., or (b) have datm add ozone to drv_flds_in always. Then CLM should check at runtime: if use_ozone is true, but the ozone field has index = 0, then abort.

But upon further reflection, I think it makes sense to require CAM to always send some ozone concentration, even when it's running without chemistry. If it's running without chemistry, it could just send a global, constant value for now (as has been the case in CLM up until now). This seems important so that you can at least run some flavor of ozone in CLM when running without CAM-chem. That would also simplify the coupling logic - because we wouldn't need to anything with drv_flds_in, etc.

(12-5-16) In talking with Danica: She'd prefer if you got an error message if you're running CAM in a configuration without ozone. But she'd be okay with CAM sending a constant - she suggests it just sends 0 (an alternative would be for it to send some garbage value that's obviously bad).

[billsacks]

Original comment from @billsacks 2016-10-11

Currently Danica is using an hourly "mask" (8760 values on the file - one for each hour of the year) that is added to the monthly values. She does the addition in CLM. If we wanted to use that functionality, then we'd want to:

1. Move the addition to datm, rather than doing the addition in CLM

2. Probably we'd want to turn off the ozone read unless it's needed (e.g., see the idea of a USE_OZONE xml variable in my recent comment), because reading those hourly data could have significant performance overhead.

For the first pass, we'll probably skip the hourly "mask", just supporting monthly-average ozone values.

[billsacks]

Original comment from @billsacks 2016-11-30

Mariana has done the necessary xml and buildnml mods for datm on this branch:

https://github.com/ESMCI/cime/tree/mvertens/datm_ozone

[billsacks]

Original comment from @billsacks 2016-12-27

Update on the hourly "mask", from Danica: It turns out that CAM, when run without CHEM, can supply monthly average ozone values. So we'll probably want to apply the "mask" in CLM after all, rather than in datm - since this "mask" will be applied both when running with datm and when running with CAM without CHEM. But in order for this to work right, CLM will need to know when it's being given monthly values, and when it's being given hourly / half-hourly data already. Maybe have datm and CAM set a field in seq_infodata to communicate this to CLM?

[billsacks]

cc @danicalombardozzi

[danicalombardozzi]

That sounds good to me if it's a viable option. I should probably recalculate the mask after the new CAM-CHEM simulations are complete so that we are using the most up-to-date chemistry.

[billsacks]

@danicalombardozzi to be honest: I just moved this over blindly from trello without even re-reading some of this. Hopefully once the never-ending release crunch is done, we can finally get this in!

[billsacks]

See also #134 , which may be a duplicate of this.
Edit: #134 is a piece of this, not a duplicate.

[wwieder]

Notes from @danicalombardozzi's email on updating this for CESM3.

CAM folks have put the pieces in place to send ozone from CAM to the coupler. We need to connect the pieces in CLM. The outstanding tasks include:

1. Connect O3 from the coupler into CLM (for coupled simulations)
2. Add a new forcing stream to datm (for land-only simulations)
3. Generate files for hourly ozone concentrations (needed for both datm and coupled simulations without chemistry) (Louisa)

Please note that @lkemmons has agreed to help with generating the appropriate files for 3, and @mvertens still help with 1 and 2. There are two university groups who are actively trying to do this for their own needs, and incorporating this capability into CLM will save time and energy for future users.