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).

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.

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

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?

cc @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.

@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!

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

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.

@billsacks, @ekluzek and @lkemmons, is there more from CTSM that needs to happen for integration with CAM-chem? or is this issue done effectively (aside from documentation)?

Most of this is done thanks to work by @adrifoster a few months ago. Everything should work correctly now when running with CAM-chem, where we have prognostic ozone values every time step. The main remaining piece – which @adrifoster started but hasn't completed – is applying diurnal anomalies to smoothed ozone values to get better ozone forcings when running with either DATM or CAM without chemistry.

Seems like it may be time to revisit this. How much of a priority is this for CESM3?

It would be nice to complete this - I know of users wanting it.

Thanks, @lkemmons. I'm not really clear what it would take to get this wrapped up for CESM3, we can discuss at an upcoming CTSM software meeting.

From the CAM-Chem group, how does prioritization stack up compared to the soil NOx work, #2290?

We think this only matters for offline I cases at this point so we don't think this matters for CAM-Chem.

But, @wwieder will setup a meeting to discuss with @lkemmons and @adrifoster to discuss.

We think this only matters for offline I cases at this point so we don't think this matters for CAM-Chem.

That matches my recollection, too.

Is the CAM connection on by default for B-cases?

The notes above state that the temporal downscaling of ozone streams for I-cases is something that @lkemmons will help with, although that was 2 years ago! Is this something you're still interested / willing to do? I'd assume this would be something we'd want to generate from cplhist files of CESM3 simulations. Maybe we need to make sure this output is generated in cplhist output next time we generate these data?

I think it is only on when you use the ozone-specific namelist options for any case, but I can check on this.

@wwieder I think @lkemmons already helped by providing the downscaling data, so we/I just need to put it in CTSM. I started this a long time ago so I think it could be fairly straightforward to finish.

Oh, that would be great if this is relatively straightforward to wrap up, @adrifoster.

I even wrote a design doc about it!

We think this only matters for offline I cases at this point so we don't think this matters for CAM-Chem.

That matches my recollection, too.

Replying to my own comment as well as some of the other recent comments: Actually, I now think / remember that it's more subtle than this: I think that, in F/B cases with CAM-Chem – so with prognostic ozone – the work @adrifoster did before she went on maternity leave put everything needed in place. I think the coupling is already set up so that ozone is always being passed from CAM to CTSM, so I think all that's needed in those cases is to turn on the ozone damage namelist option. (Though I'm not sure if we ever got to the bottom of #962.) But the application of diurnal anomalies is needed both for offline (I) compsets and for F/B compsets without chemistry, in which case CAM passes smoothed ozone concentrations without diurnal variability.

@billsacks Do we still want to do this?

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

I believe it's the last thing to do in the list at the top of this issue. I'm not sure what is involved in this.

also are we still worried about #962 above?