Canopy resistance (rca) in Noah-MP for AQM.

[drnimbusrain]

This PR includes a commit to add initial total canopy resistance (rca) calculation in Noah-MP, which is needed for coupling to the Air Quality Model (AQM) component. The rca calculation is based on Bonan et al. (2011) from the CLM4, and is used in the WRF version of the Noah-MP model.

[grantfirl]

@drnimbusrain I'd like to combine this PR with others to save effort in the UFS merge queue. My understanding from NOAA-EMC/fv3atm#830 is that RT baselines don't change, making this combination straightforward. Is it OK with you if I do this?

[drnimbusrain]

@drnimbusrain I'd like to combine this PR with others to save effort in the UFS merge queue. My understanding from NOAA-EMC/fv3atm#830 is that RT baselines don't change, making this combination straightforward. Is it OK with you if I do this?

Sounds fine to me, thanks!

[barlage]

@drnimbusrain @grantfirl @cenlinhe My preference would be to not change the noahmplsm code here. The main reason laisun/laisha and rs_sunlit/rs_shaded are in the call to noahmp_sflx is to support this RS calculation at the noahmpdrv_run level. The calculation added in the physics code isn't used in the physics code. See this WRF code.

[cenlinhe]

@drnimbusrain @grantfirl @cenlinhe My preference would be to not change the noahmplsm code here. The main reason laisun/laisha and rs_sunlit/rs_shaded are in the call to noahmp_sflx is to support this RS calculation at the noahmpdrv_run level. The calculation added in the physics code isn't used in the physics code. See this WRF code.

I agree with Mike @barlage that it would be better to keep the total RS calculation in the noahmp driver interface as a diagnostic output variable, unless it is needed as a prognostic variable for other quantity calculations.

[drnimbusrain]

Thanks for comments Mike and Cenlin. I can move the rca calculation to the driver if you prefer.

…

On Mon, May 6, 2024, 12:41 PM Cenlin_He ***@***.***> wrote: @drnimbusrain <https://github.com/drnimbusrain> @grantfirl <https://github.com/grantfirl> @cenlinhe <https://github.com/cenlinhe> My preference would be to not change the noahmplsm code here. The main reason laisun/laisha and rs_sunlit/rs_shaded are in the call to noahmp_sflx is to support this RS calculation at the noahmpdrv_run level. The calculation added in the physics code isn't used in the physics code. See this WRF code. <https://github.com/NCAR/noahmp/blob/3be0b2860dab167006a0b3c4822e234ca253c3df/drivers/wrf/module_sf_noahmpdrv.F#L1307> I agree with Mike @barlage <https://github.com/barlage> that it would be better to keep the total RS calculation in the noahmp driver interface as a diagnostic output variable, unless it is needed as a prognostic variable for other quantity calculations. — Reply to this email directly, view it on GitHub <#204 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGLFYNT4IULF4CMLTQCAZR3ZA6XCJAVCNFSM6AAAAABHEPMXIGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJWGQ3TANZSGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[grantfirl]

@barlage @cenlinhe @drnimbusrain I can do this in #205. Don't worry about changing it in this branch. I'll be sure to add @barlage and @cenlinhe as reviewers to #205 and notify you that it has been moved.

[drnimbusrain]

Thank you Grant! I'll leave it to you. Patrick

…

On Mon, May 6, 2024, 1:09 PM Grant Firl ***@***.***> wrote: @barlage <https://github.com/barlage> @cenlinhe <https://github.com/cenlinhe> @drnimbusrain <https://github.com/drnimbusrain> I can do this in #205 <#205>. Don't worry about changing it in this branch. I'll be sure to add @barlage <https://github.com/barlage> and @cenlinhe <https://github.com/cenlinhe> as reviewers to #205 <#205> and notify you that it has been moved. — Reply to this email directly, view it on GitHub <#204 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGLFYNVETVAVKS34I3XNYNTZA62NDAVCNFSM6AAAAABHEPMXIGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJWGUZDAMZYHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[drnimbusrain]

@grantfirl @barlage @cenlinhe I'd like to ask another question on this topic of LSM parameters important for AQM coupling:

To confirm with Noah-MP in CCPP for UFS, the Leaf Area Index (LAI) coming out to FV3 for coupling to downstream models like our AQM is called "xlaixy", correct? I understand this based on its definition in FV3 GFS_typedefs and in CCPP.

For some reason in the AQM it seems to pull the following state variable, e.g., "xlai"

call ESMF_FieldGet(field, localDe=localDe, farrayPtr=stateIn % xlai, rc=rc

While this works OK for the Noah LSM because I think there is a "xlai" form of the variable, when coupling AQM to Noah-MP LSM, the LAI is now getting populated with only missing/fill values, and maybe why I am seeing some errors with AQM. I thought it may be because Noah-MP only uses "xlaixy", not "xlai".

Any suggestions are much appreciated! Patrick

[barlage]

@drnimbusrain @cenlinhe @grantfirl In my understanding, in FV3ATM xlaixy is the Sfcprop state variable for noah, noahmp or ruc.

at the CCPP interface this is assigned to the ccpp variable leaf_area_index

in the land models, leaf_area_index takes the names (from the land meta files): xlaixy(noahmp), laixy(ruc), lai(noah) (but these names are not relevant above CCPP)

I don't understand much when it comes to component model interfaces, but I see this, which seems to indicate that xlaixy is being used in the AQM component, and in AQM it is named xlai

tagging @HelinWei-NOAA @sanatcumar for the LAI conversation

[drnimbusrain]

@drnimbusrain @cenlinhe @grantfirl In my understanding, in FV3ATM xlaixy is the Sfcprop state variable for noah, noahmp or ruc.

at the CCPP interface this is assigned to the ccpp variable leaf_area_index

in the land models, leaf_area_index takes the names (from the land meta files): xlaixy(noahmp), laixy(ruc), lai(noah) (but these names are not relevant above CCPP)

I don't understand much when it comes to component model interfaces, but I see this, which seems to indicate that xlaixy is being used in the AQM component, and in AQM it is named xlai

tagging @HelinWei-NOAA @sanatcumar for the LAI conversation

Thank you Mike for clarification, and where it is renamed xlai in the GFS coupling (from xlaixy) for AQM. Thus, it should work as xlai from either Noah or Noah-MP LSM since xlaixy is the Sfcprop state variable for both. However, when using the GFSv17_p8 physics (with Noah-MP LSM) all of the coupled xlai after AQM import are now missing causing model errors. Everything works fine for AQM with the Noah LSM when coupling.

I am trying a test to change the name inside AQM to get the sfcprop name, xlaixy:

call ESMF_FieldGet(field, localDe=localDe, farrayPtr=stateIn % xlaixy, rc=rc

[drnimbusrain]

@barlage As far as I can tell, when using Noah-MP, the xlaixy (or similarly xlai) is coming out as missing values from FV3 when coupling to AQM:

xlaixy= 9.990000000000000E+020 9.990000000000000E+020

Will need to figure out why this is as AQM needs the Noah-MP LAI values when coupling to future physics (e.g., GFSv17, RRFS, etc.).

Thanks!

[drnimbusrain]

@barlage As far as I can tell, when using Noah-MP, the xlaixy (or similarly xlai) is coming out as missing values from FV3 when coupling to AQM:

xlaixy= 9.990000000000000E+020 9.990000000000000E+020

Will need to figure out why this is as AQM needs the Noah-MP LAI values when coupling to future physics (e.g., GFSv17, RRFS, etc.).

Thanks!

After further checking of the CCPP Noah-MP driver, it appears that not all the LAI values are missing when coupling to AQM. Rather, there appears to be some grid cells that have these erroneously large LAI values from Noah-MP driver directly:

xlaixy_noah_mp_drv= 9.990000000000000E+020
leaf_area_index_noah_mp_drv= 0.000000000000000E+000
xlaixy_noah_mp_drv= 9.990000000000000E+020
leaf_area_index_noah_mp_drv= 0.000000000000000E+000
xlaixy_noah_mp_drv= 9.990000000000000E+020

Indeed, this is what causes the new crash in AQM when coupling to GFSv17_p8 physics. Adding a simple condition to AQM is a temporary workaround at this point to avoid the erroneously large values for LAI from Noah-MP (at least until we understand why these are coming out of Noah-MP).

[grantfirl]

Combined into #205

[barlage]

For completeness, I'll add this response from an email chain:

What you are likely seeing are missing values for xlaixy over glacier grids. Vegetation states over glaciers are the only location in noahmpdrv where missing values are assigned. Is AQM doing an interpolation or is it running on the model grid? Does AQM use LAI over permanent snow/ice (i.e., glacier) grids?

There are certain states over glacier grids that could be set to 0, like LAI, canopy water, etc. but we are using missing values in particular for states like temperature, where setting it to 0 or some other default values can cause other problems.

In noahmpdrv, the value is named "undefined". One of the issues here is that there is no global UFS (or CCPP as far as I know) definition of "missing value", which would help to determine if a value is missing or erroneous.

[grantfirl]

Thanks, @barlage. Having a "missing value" functionality could be a useful feature of the CCPP, although I imagine that it makes most sense to grab such a value from a host model because they also use it for, e.g., I/O.

[barlage]

@grantfirl when I brought up this missing_value issue to the WRF atmospheric community years ago, the response seemed to be "we don't have missing values in the atmosphere"

[barlage]

@grantfirl probably not the place to have this conversation, but it would be helpful to have the parent model consistently initialize variables with some undefined_ or missing_value so that we could check them in the physics, e.g., at initialization

[grantfirl]

@grantfirl when I brought up this missing_value issue to the WRF atmospheric community years ago, the response seemed to be "we don't have missing values in the atmosphere"

If only our models were perfect representations of the atmosphere!

[grantfirl]

@grantfirl probably not the place to have this conversation, but it would be helpful to have the parent model consistently initialize variables with some undefined_ or missing_value so that we could check them in the physics, e.g., at initialization

Good point. From the CCPP side, we're basically trusting the host to have initialized all interface variables, but there is no standard for doing so and it can certainly be implemented in many different ways. The UFS, of course, does most of this through CCPP_typedefs and GFS_typedefs and chooses initialization values that are appropriate on an individual variable basis, but I can see that it might be useful for the physics schemes to have something like the compiler flag that has default initialization to NaN or something.

[dustinswales]

One could add a parameterized missing/reference/fill_value, analogous to how we do parameterized working precision. It would be just another "hook" between the host model and the physics.

Ultimately both of these could, and should from an organizational standpoint, be handled by the framework. Capgen is going this way to handle the precision (i.e. autogenerate the physics/hooks/machine.F file instead of having the host modify this file in the physics for it's needs.)