Need to pass Precip and ET to mizuRoute for dynamic lake work

[ekluzek]

We will need to pass at least (P-E = Precipitation minus Evapotranspiration) to the coupler for the dynamic lake work with mizuRoute.

On the mizuRoute side this is.

ESCOMP/mizuRoute#157

With the correct names I don't think we will need to add this explicitly in the CMEPS nor in nuopc version of cime. We'll need to use the same name in CTSM as in mizuRoute..

[ekluzek]

Seems like this should be an option field, that we trigger with a namelist item, and normally only turn it on when we are coupled to mizuRoute. Possibly it should also only be turned on when dynamic lakes are being exercised.

[ekluzek]

We talked to @mvertens about this and I've setup an issue in CMEPS for what needs to be done there. CTSM will need to respond to the xml variable: FLDS_LAKE_SURF_H2O_BAL that CMEPS provides, and send it if it's sent. So probably the buildnml will need to check if that variable is set and then trigger a namelist item that will be set for CTSM to export it.

[ekluzek]

We met as a group and decided we'd send this as separate fields which will enable more analysis inside of mizuRoute. We also clarified that this should be masked so that it's only precipitation and ET over lake areas.

[ekluzek]

I think these two new fields belong in Waterlnd2atmType.F90 as follows...

+     real(r8), pointer :: qflx_lake_evap_tot_grc(:)! Over Lake: qflx_evap_soi + qflx_evap_can + qflx_tran_veg
+     real(r8), pointer :: qflx_lake_prec_tot_grc(:)! Over Lake: total precipitation

that means the tracer and bulk amount will be tracked (as other fields sent to ROF are like irrigation). The name is a bit of a misnomer since it's not really being sent to atm, but it's sent to rof.

@billsacks does this sound right to you?

[billsacks]

Yeah, that sounds right. And yes, this name is definitely a misnomer... it is a historical relic, because the similarly-misnamed lnd2atmMod deals with fluxes to rof as well as atm.

[ekluzek]

@nmizukami @dlawrenncar and I talked about this today. We realized that when lakes are on, we'll need to adjust the QGWL field to exclude lakes (since the lake part of this is lake Precip and ET). Possibly we should have a different array QGW for this purpose to distinguish the two. But, that will require more logic to flip between the two and add additional arrays.

[ekluzek]

We talked about this morning, we feel that overloading the purpose of the QGWL data is probably the right thing to do. The code will be simpler this way. And should be able to be implemented faster. A bit-for-bit refactoring could be done later, if we decide the other way is the right way. The way to think about it is just that QGWL has the lake part of it set to zero if Lake P and ET are being sent. So it probably just needs some documentation around this.