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?

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.

Sorry for my terribly delayed reply to this! Yes, I think we still want to add ozone as a cpl hist field, so that cplhist-forced I compsets can have ozone forcing. To do this, see the various variables labeled "histaux_atm2med_*" in https://github.com/ESCOMP/CMEPS/blob/main/cime_config/namelist_definition_drv.xml. I think ozone should be added to either file 4 or file 5, based on looking at what's in the various files, but I'm not sure which is correct.

also are we still worried about #962 above?

As far as I know, that was never resolved... at the very least I feel like it should be re-checked before doing science with the ozone code.

I think ndep also still needs to be added to cplhist output in these auxiliary history files.

Here is an email I sent Sept 2, 2022 on this; my sense is that these things were never done:

Mariana:

(M1) Change the defaults for cmeps histaux so that both ndep and o3 are in the daily average file.

(M2) Do a short F compset to write out new histaux files. However, it may be that cdeps expects full years of data, in which case you may need a full year. You probably know this better than I do.

(M3) Test to ensure that we can run CTSM's cplhist test case from Adrianna's CTSM branch for ozone pointing to these new files.

(M4) Move these files into the inputdata repository.

Adrianna:

(A1) On your branch change the cplhist testmods directory to point to the new files generated by Mariana (only make the change in the nuopc branch of the conditional; keep the mct branch the same as before)

(A2) Add the cplhist test to the alpha test list.

(A3) In the ChangeLog, we should add a caveat for users: can't run cplhist-forced cases with old cplhist files.

One other issue for these cplhist-forced runs: Do we want a way to distinguish between whether the fields on cplhist were generated from a CAM run with or without diurnal cycle already included? If so, we may need a way to signal that in metadata on the file, and also a way to read that in datm and set the flag appropriately. But since (I think) the flag is needed at build-namelist time, I'm not sure how to do this....

One "solution" may be to write ozone to a daily-average auxhist file. Then we can always assume that there is no diurnal cycle in the DATM cplhist-forced runs. However, there currently isn't a daily-average auxhist file for the atm2lnd fields so that would require adding a new file, which would be somewhat more work (I'm not sure how extensive the changes would need to be for that).