More water states and fluxes that need to be replicated for tracers

[billsacks]

Looking more closely at the older water isotope branch (branch wiso-clm5-r249 on https://github.com/ncar/water-isotopes), I realized that we're still missing a water state and a number of fluxes that need to be replicated for tracers:

• wa_col, currently defined in SoilHydrologyType.F90. This should be a straightforward matter of moving this to WaterStateType.

• Many water fluxes currently defined in atm2lndType and lnd2atmType. I'm not sure what to do here: The easiest solution would probably be to move all water fluxes out of atm2lndType and lnd2atmType and into WaterFluxType. But that means that these atm2lnd and lnd2atm variables would no longer all be together; I've particularly liked having the atm2lnd variables together because there's some complexity with respect to downscaling, and it's nice to have that all in one place. Still, my current feeling is that it's probably best to move these to WaterFluxType, but I'd like to give this more thought and here some thoughts of others. @mathewvrothstein and @mvertens - do you have any thoughts on this?

[mvertens]

@Sacks - it would be good to sit down tomorrow and hash this out a bit while looking at the code. I agree about giving this more thought.

…

On Wed, Aug 15, 2018 at 8:55 PM Bill Sacks ***@***.***> wrote: Looking more closely at the older water isotope branch (branch wiso-clm5-r249 on https://github.com/ncar/water-isotopes), I realized that we're still missing a water state and a number of fluxes that need to be replicated for tracers: - wa_col, currently defined in SoilHydrologyType.F90. This should be a straightforward matter of moving this to WaterStateType. - Many water fluxes currently defined in atm2lndType and lnd2atmType. I'm not sure what to do here: The easiest solution would probably be to move all water fluxes out of atm2lndType and lnd2atmType and into WaterFluxType. But that means that these atm2lnd and lnd2atm variables would no longer all be together; I've particularly liked having the atm2lnd variables together because there's some complexity with respect to downscaling, and it's nice to have that all in one place. Still, my current feeling is that it's probably best to move these to WaterFluxType, but I'd like to give this more thought and here some thoughts of others. @mathewvrothstein <https://github.com/mathewvrothstein> and @mvertens <https://github.com/mvertens> - do you have any thoughts on this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#479>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHlxEwWjcPyGHAOs6xLcuJPFQtAUSQ62ks5uRN8zgaJpZM4V_HkH> .

[mathewvrothstein]

happy to meet and discuss, though i'm working from home today...calling in is an option

[dlawrenncar]

FYI, I believe that wa_col is not currently used by default in CLM5, though it is used in CLM4.5. Further, it is likely that we will utilize wa_col when we introduce spatially-explicit confined aquifers.

…

On Thu, Aug 16, 2018 at 7:09 AM, mathewvrothstein ***@***.***> wrote: happy to meet and discuss, though i'm working from home today...calling in is an option — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#479 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AUAcVOY-QAkuDQsGmaAO7VB3yujeEKKSks5uRW8bgaJpZM4V_HkH> .

[billsacks]

My current thinking is that we can have two new types, water_lnd2atm_type and water_atm2lnd_type. Instances of these types would be managed by water_type, as for other water variables. This would mean that atm2lnd and lnd2atm variables now appear in multiple places, but at least the atm2lnd and lnd2atm variables would be separated from other, internal model variables.

I'm not tied to this idea, though, so am happy to discuss it further this afternoon.

[billsacks]

Okay, here's what I think should be done. I'm not sure that the distinction between tracer vs. bulk-only is right for all of these variables, but if we use the same design that we've used elsewhere, it will be easy to migrate a variable between tracer vs. bulk-only later when we realize it's in the wrong place:

Variables not in lnd2atm and atm2lnd that should be moved as part of addressing this issue:

• wa_col: move from SoilHydrologyType to WaterStateType

• qflx_drain_perched_col: move from WaterFluxBulkType to WaterFluxType: needed for qflx_rofliq_drain_perched_grc, listed below (this move should just involve moving a few lines from WaterFluxBulkType to WaterFluxType: no other modules should be affected)

• qflx_irrig_patch and qflx_irrig_col: move from WaterFluxBulkType to WaterFluxType: needed for qirrig_grc, listed below (this move should just involve moving a few lines from WaterFluxBulkType to WaterFluxType: no other modules should be affected)

lnd2atm water-related variables

As we did with waterstate, waterdiagnostic, etc.: Introduce two new types, water_lnd2atm_type and water_lnd2atm_bulk_type (where the bulk_type extends the water_lnd2atm_type). (@mathewvrothstein I'm not tied to these names if you prefer something slightly different). Then move the following variables out of lnd2atm_type (lnd2atmType.F90):

Move these into water_lnd2atm_type

• q_ref2m_grc

• h2osno_grc

• qflx_evap_tot_grc

• qflx_rofliq_grc

• qflx_rofliq_qsur_grc (Wasn't by tracer in the old water isotope branch, but I think this is a new variable, which I'm thinking may be needed for each tracer for the sake of the runoff model)

• qflx_rofliq_qsub_grc (Wasn't by tracer in the old water isotope branch, but I think this is a new variable, which I'm thinking may be needed for each tracer for the sake of the runoff model)

• qflx_rofliq_qgwl_grc (Wasn't by tracer in the old water isotope branch, but I think this is a new variable, which I'm thinking may be needed for each tracer for the sake of the runoff model)

• qflx_rofliq_drain_perched_grc (Wasn't by tracer in the old water isotope branch, but I think this is a new variable, which I'm thinking may be needed for each tracer for the sake of the runoff model)

• qflx_rofice_grc

• qflx_liq_from_ice_col (Wasn't by tracer in the old water isotope branch, but this is a new variable, which I think will be needed for each tracer)

• qirrig_grc (Wasn't by tracer in the old water isotope branch, but I think this is a new variable, which I'm thinking may be needed for each tracer for the sake of the runoff model)

Move these into water_lnd2atm_bulk_type

• h2osoi_vol_grc (Note that h2osoi_vol_col is stored per-tracer, but it looks like the coupling only needs this for bulk)

However, since there's only one variable in this list, I'd be okay with its being in water_lnd2atm_type for now, doing away with the need for water_lnd2atm_bulk_type for the time being.

atm2lnd general cleanup

Before moving stuff in atm2lnd_type, here's some general cleanup that can be done: All of the "anomaly forcing" variables can be removed:

https://github.com/ESCOMP/ctsm/blob/354ee027cfe4df411d931ce4093e602a46764865/src/main/atm2lndType.F90#L120-L129

From spot-checking a few of them and talking with @swensosc it looks like these are no longer used.

atm2lnd water-related variables

As we did with waterstate, waterdiagnostic, etc.: Introduce two new types, water_atm2lnd_type and water_atm2lnd_bulk_type (where the bulk_type extends the water_atm2lnd_type). (@mathewvrothstein I'm not tied to these names if you prefer something slightly different). Then move the following variables out of atm2lnd_type (atm2lndType.F90):

Move these into water_atm2lnd_type

• forc_q_not_downscaled_grc

• forc_rain_not_downscaled_grc

• forc_snow_not_downscaled_grc

• forc_q_downscaled_col

• forc_rain_downscaled_col

• forc_snow_downscaled_col

• forc_flood_grc

Move these into water_atm2lnd_bulk_type

• forc_rh_grc

• volr_grc

• volrmch_grc

• prec365_col

• prec60_patch

• prec10_patch

• rh30_patch

• prec24_patch

• rh24_patch

[billsacks]

@davidnoone @swensosc - total qflx_rofliq (forcing to the runoff model) has been split into a number of different components (positive or negative): qflx_rofliq_qsur_grc, qflx_rofliq_qsub_grc, qflx_rofliq_qgwl_grc, qflx_rofliq_drain_perched_grc, qirrig_grc. I'm assuming that we'll want tracer-by-tracer (e.g., isotope) versions for each of these individual fluxes between CTSM and the runoff model, in addition to the overall qflx_rofliq_grc (in case the different components of the overall flux are routed differently). Do either of you have any thoughts on this?

[billsacks]

@mathewvrothstein I think this is ready for you, based on my big comment above. I think the changes needed based on my last question would be very limited, so you can probably move ahead even before we have an answer to that question.

[davidnoone]

@billsacks without thinking deeply about this, "yes".
Usually in the code if it is not broken out and only the net is give, we'd end up having a bunch of logical blocks "if (positive) then do A, else (negative) do B.". Splitting into the the gross parts up front is likely to keep it cleaner by avoiding the need for some of the logical blocks to account for direction and source pools, etc.

[billsacks]

Thanks, @davidnoone - we'll put in place placeholders for the tracer versions of these broken-out fluxes for now.

[swensosc]

I think we will want tracer versions, b/c these fluxes are treated differently by mosart.

…

On Mon, Aug 20, 2018 at 3:16 PM, Bill Sacks ***@***.***> wrote: @davidnoone <https://github.com/davidnoone> @swensosc <https://github.com/swensosc> - total qflx_rofliq (forcing to the runoff model) has been split into a number of different components (positive or negative): qflx_rofliq_qsur_grc, qflx_rofliq_qsub_grc, qflx_rofliq_qgwl_grc, qflx_rofliq_drain_perched_grc, qirrig_grc. I'm assuming that we'll want tracer-by-tracer (e.g., isotope) versions for each of these individual fluxes between CTSM and the runoff model, in addition to the overall qflx_rofliq_grc. Do either of you have any thoughts on this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#479 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AaLe_C-aIluJ7vF1bT_6UgSJGjivpYf9ks5uSydFgaJpZM4V_HkH> .