Compositing z0 for fractional grid

[benwgreen]

Refer to Issue #578

In GFS_surface_composites.F90, the momentum roughness length zorl is currently composited (for frac_grid = .true.) by taking the arithmetic mean of zorl_lnd, zorl_wat, zorl_ice. A more physically realistic method is to composite based on the logarithms of the component zorls, which can be done in sfc_diff.f to produce self-consistent composite values of ustar, cd, cdq, rb, stress, fm, fh, fm10, and fh2.

NOTE: skin temperature has NOT been composited based on longwave radiation; it still takes weighted average of component temperatures.

@JongilHan66 @shansun6 @SMoorthi-emc @junwang-noaa @yangfanglin (weizhong.zheng@noaa.gov)

[climbfuji]

A couple of questions on this PR. I see that the calculation of certain composite variables is turned off in GFS_surface_composites_post when frac_grid is true. But the calculation of these variables in sfc_diff is added for both cases, frac_grid true and false. Why?

It's also concerning that the compositing of the variables is now "hidden" in sfc_diff.f instead of being kept separate in GFS_surface_composites.F90. The latter can be shared with other surface schemes, but sfc_diff.f for example is not used with MYNN sfc. This seems detrimental to physics interoperability and putting together physics suites.

It would be much better if the compositing could stay in GFS_surface_composites.F90. If necessary, create additional interstitial variables in sfc_diff.f (and MYNN sfc etc.) that can be used in GFS_surface_composites_post.

But, admittedly, my understanding is limited and I might be off entirely.

[benwgreen]

@climbfuji you make excellent points. I will plead ignorance (not as an excuse -- just as an explanation). I think the best solution is to create extra interstitial variables, because the key is that we need to use sfc_diff an extra time for the frac_grid=.true. , but not when frac_grid=.false.

The issue of what to do when other surface routines are used instead of sfc_diff is something that needs to be considered as well. I would think first that coming up with a more elegant and ccpp-compliant solution to the case of sfc_diff would hopefully allow for more interoperability.

I welcome suggestions from those mentioned on how to improve this.

[yangfanglin]

Moorthi/Jongil/Mike/Weizhong, Please help review this PR and provide your comments. It appears, to get consistent PBL and surface variables, the compositing section cannot be moved up to GFS_surface_composites.F90. Maybe the compositing has to be treated differently for different PBL/sfc schemes ? Thanks Fanglin

…

On Thu, Feb 25, 2021 at 8:40 PM benwgreen ***@***.***> wrote: @climbfuji <https://github.com/climbfuji> you make excellent points. I will plead ignorance (not as an excuse -- just as an explanation). I think the best solution is to create extra interstitial variables, because the key is that we need to use sfc_diff an extra time for the frac_grid=.true. , but not when frac_grid=.false. The issue of what to do when other surface routines are used instead of sfc_diff is something that needs to be considered as well. I would think first that coming up with a more elegant and ccpp-compliant solution to the case of sfc_diff would hopefully allow for more interoperability. I welcome suggestions from those mentioned on how to improve this. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#579 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKY5N2LEJHAK54JDKT7CUETTA33W7ANCNFSM4YG7ADLA> .

-- *Fanglin Yang, Ph.D.* *Chief, Model Physics Group* *Modeling and Data Assimilation Branch* *NOAA/NWS/NCEP Environmental Modeling Center* *https://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/ <https://www.emc.ncep.noaa.gov/gmb/wx24fy/fyang/>*

[climbfuji]

@climbfuji you make excellent points. I will plead ignorance (not as an excuse -- just as an explanation). I think the best solution is to create extra interstitial variables, because the key is that we need to use sfc_diff an extra time for the frac_grid=.true. , but not when frac_grid=.false.

The issue of what to do when other surface routines are used instead of sfc_diff is something that needs to be considered as well. I would think first that coming up with a more elegant and ccpp-compliant solution to the case of sfc_diff would hopefully allow for more interoperability.

I welcome suggestions from those mentioned on how to improve this.

Thanks, Ben, for your explanation. I am happy to work with you on this in the next week, hopefully I can be of help.

[barlage]

Related to this PR: The log-weighted compositing is the approach we are taking in Noah-MP to deal with the sub-grid land tiles, which is essentially the same issue as fractional grid. I can see having the compositing of a common field like z0 be done higher in the code, where different options of compositing could be used. I don't think this completely solves the consistency issue.

Perhaps off-topic but related to the original purpose of self-consistency of ustar, etc.: To the point @yangfanglin made about different schemes, I think scheme-specific approaches to compositing need to be used, especially since all PBL schemes do not necessarily require the same inputs. And all surface layer schemes do not use the same approximations. I likely don't understand the code structure enough to make an informed suggestion here on the placement of the compositing code.

For example, a question is how to average the surface temperatures for use in this extra call to sfc_diff. (Note: this is also the same approach we are taking for compositing Noah-MP tiles.) The current approach is linear, but should it be weighted toward sensible heat or heat exchange coefficient(Ch), similar to the note re: radiative temperature, to make the average temperature more consistent with the sensible heat flux? (Note: this is what we are working on for Noah-MP compositing) A linear weighted temperature might imply a stable regime while at the same time a flux/Ch weighted might imply an unstable regime. I am not yet familiar enough with the sfc_diff stability calculations (I need to read Office Notes 321 and 356, links below) to understand the assumptions, but my current understanding is that these are linearized assumptions to avoid iteration and that the temperature should likely be consistent with the sensible heat flux because the linearization is done to avoid iterating the sensible heat calculation.

ftp://ftp.library.noaa.gov/noaa_documents.lib/NWS/National_Meteorological_Center/NMC_Office_Note/NMC_Office_Note_321.pdf
ftp://ftp.library.noaa.gov/noaa_documents.lib/NWS/National_Meteorological_Center/NMC_Office_Note/NMC_Office_Note_356.pdf

[benwgreen]

Bug: chh = rho * cdq * wind (cmm = cd*wind is still correct)

[SMoorthi-emc]

This is incomplete. There needs to be composite between water and ice even in non-fractional grid case.

[benwgreen]

@SMoorthi-emc currently the only composited variables in the non-frac case (Lines 579-601 of original GFS_surface_composites.F90) are: zorl, tsfc, evap, hflx, stress, qss, ep1d. This portion of the proposed code change probably won't survive as-is given Dom's comments, but if it were to survive, then the water/ice composite here would only be done for z0rl and stress?

[SMoorthi-emc]

I haven't looked carefully, but depending on lake or ocean, some of that will have to survive.
I have not seen Dom's comment

[wzzheng90]

The use of the arithmetic mean of the momentum roughness length in this PR is a more physically realistic method, compared to the original linear relationship. And then this variable is used to produce self-consistent composite values of ustar, cd, cdq, rb, stress, fm, fh, fm10, and fh2 in "sfc_diff". I like this method and it should improve the previous composition method.

However, I would like to give some comments. My understanding is that these parameters are used to provide to the PBL scheme (TKE-EDMF), and this does not mean to completely solve the consistency issue as Mike mentioned above. These composited parameters are still inconsistent with the total surface fluxes (land/ocean/ice), although the composited fields would be more reasonable than old ones.

Thanks, Ben. Very good job!

[benwgreen]

I spoke with @climbfuji yesterday afternoon. We agreed that the structure of the changes in this PR need to be redone to allow for physics suite interoperability. He has volunteered to come up with a way to do so (thanks, Dom!) so that is why he put up the "do not merge" and "work in progress" tags. Stay tuned...

[wzzheng90]

One more comment: Please check if the "frac_grid=.false." section can be removed, for it is supposed that frac_grid=.true. conditions should cover all cases including 100% land or water or ice.
Thanks,
--- Weizhong

[benwgreen]

@barlage would we need to change composite formula here also, or just simply use your composite straight from sfc_diff?

[barlage]

@benwgreen for now, using the composite here should be sufficient; I have to admit I'm ignorant on what tsfc is used for after this point, i.e., PBL, radiation, both? @yangfanglin might be able to comment; I will state here that this is where I think we need two surface temperatures, one for fluxes and one for radiation. This does depend on what the PBL/radiation use for a boundary condition (flux vs. temperature) but to be as general as possible, we probably should have two temperatures.

[benwgreen]

@barlage After thinking more about @climbfuji's comments on what to do if sfc_diff isn't called, for the immediate term it is probably best to leave this line as-is. Once we come up with a way to better generalize the solution, it could very well be that a value from sfc_diff (via meta) ends up here. We will keep you posted as we work through the problem.

[climbfuji]

Instead of passing all the composite variables to sfc_diff_run, call stabilty from GFS_surface_composites_post_run for the composite variables?

[climbfuji]

We just need to think about what to do if sfc_diff is not used, i.e. for example for MYNNSFC. Maybe call the same stability function for the moment and then work with @joeolson42 to call the appropriate function from MYNNSFC in GFS_surface_composites_post_run?

[joeolson42]

I think in the long run, we will want to develop towards a design in which the surface layer scheme is called within the LSM, so if we really want to make a big structural change, I suggest going all in on that design.

…

On Tue, Apr 13, 2021 at 8:51 AM benwgreen ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In physics/GFS_surface_composites.F90 <#579 (comment)>: > @@ -441,6 +445,8 @@ subroutine GFS_surface_composites_post_run ( qss(i) = txl*qss_lnd(i) + txi*qss_ice(i) + txo*qss_wat(i) gflx(i) = txl*gflx_lnd(i) + txi*gflx_ice(i) + txo*gflx_wat(i) endif + +! BWG, 2021/02/25: Need to change composite skin temperature base on ULW (Fanglin) tsfc(i) = txl*tsfc_lnd(i) + txi*tice(i) + txo*tsfc_wat(i) @barlage <https://github.com/barlage> After thinking more about @climbfuji <https://github.com/climbfuji>'s comments on what to do if sfc_diff isn't called, for the immediate term it is probably best to leave this line as-is. Once we come up with a way to better generalize the solution, it could very well be that a value from sfc_diff (via meta) ends up here. We will keep you posted as we work through the problem. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#579 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADLRR3QV2LXER3OYSEVF753TIRK67ANCNFSM4YG7ADLA> .

-- Joseph Olson Meteorologist Environmental Prediction Advancement Division Global Systems Laboratory NOAA-Earth System Research Labs Boulder, Colorado

[climbfuji]

This PR has been pulled into #627 and will be automatically merged as part of it.

[climbfuji]

For some reason, this PR didn't get flagged as merged when #627 was merged.