Changes to derive snow height from snow water equivalent

[thomasuhoh]

Changing the conversion from snow water equivalent to physical snow depth using ECMWF data

TYPE: enhancement

KEYWORDS: snow water equivalent, snow height, real.exe

SOURCE: Thomas Schwitalla (UHOH)

DESCRIPTION OF CHANGES: Problem: When calculating physical snow height from ECMWF snow water equivalent, very high values of 50 m occur over glaciers (e.g, over Iceland or the Alps).

Solution: Changed the conversion from snow water equivalent to snow height following Hill et al., (2019) (https://tc.copernicus.org/articles/13/1767/2019/; eq. 2) when only snow water equivalent is present. This reduces the maximum snow height to approx. 24 m and the other values by about a 40 %.

LIST OF MODIFIED FILES: M dyn_em/module_initialize_real.F

TESTS CONDUCTED:

RELEASE NOTE: Changed the conversion from snow water equivalent to physical snow depth in case only snow water equivalent is available.

[weiwangncar]

@thomasuhoh Do you know if this method also works for GFS data?

[weiwangncar]

Jenkins tests have passed:

Test Type              | Expected  | Received |  Failed
= = = = = = = = = = = = = = = = = = = = = = = =  = = = =
Number of Tests        : 23           24
Number of Builds       : 60           58
Number of Simulations  : 158           156        0
Number of Comparisons  : 95           92        0

Failed Simulations are: 
None
Which comparisons are not bit-for-bit: 
None

[thomasuhoh]

@weiwangncar I haven't tested it with GFS data as we do only use ECMWF data for our simulations. I took a quick look of a sample data set and there the ratio between water equivalent and physical snow depth seems to be often very close to 100. If one would use the same formula for GFS, it will lead to much lower values compared to the physical snow height available directly from GFS.

[jimbresch]

This change should not be made in real. The snow/snowh conversions are handled in WPS, specifically in ungrib/src/rrpr.F lines 882 to 908. Different models use different ratios and only ungrib knows the source model information. Ungrib supplies a snowh to real that assumes a 200:1 ratio which is what WRF (and NOAH) expects. The ECMWF calculation can be changed in rrpr.F if necessary. If ECMWF changed the way they compute snowh, then we will need the date of the change so we can handle the pre- and post-change input files correctly.

[thomasuhoh]

Jim, Thank you for pointing this out. Seems that I overlooked this. ECMWF also provides snow density (grib code 33 in their table) so that it's necessary to add this field to Vtable.ECMWF and Vtable.ECMWF_sigma as "SNOW_DEN" to obtain a correct calculation for SNOWH. I tried this rather quickly, and it seems that "SNOWH" needs to be included in the Vtable.ECMWF in addition as a derived field.

[dudhia]

I would add that the liquid water equivalent is the key variable for the LSM input. It probably immediately computes its own SNOWH in the first call to it, so you might see it quickly change regardless of input value. Jimy

On Wed, Feb 23, 2022 at 7:45 AM Thomas Schwitalla @.***> wrote:

Jim, Thank you for pointing this out. Seems that I overlooked this. ECMWF also provides snow density (grib code 33 in their table) so that it's necessary to add this field to Vtable.ECMWF and Vtable.ECMWF_sigma as "SNOW_DEN" to obtain a correct calculation for SNOWH. I tried this rather quickly, and it seems that "SNOWH" needs to be included in the Vtable.ECMWF in addition as a derived field.

— Reply to this email directly, view it on GitHub https://github.com/wrf-model/WRF/pull/1685#issuecomment-1048857825, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEIZ77GNJ4ZA5RLS53PTEI3U4TXHJANCNFSM5O2L5M2Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you are subscribed to this thread.Message ID: @.***>

[thomasuhoh]

If I see it correctly, NOAH+NOAHMP uses both liquid water equivalent and SNOWH as input as the logical "FNDSNOWH" is set to true in module_physics_init.F

[dudhia]

I would defer to the LSM experts for its use. (Cenlin).

On Wed, Feb 23, 2022 at 10:06 AM Thomas Schwitalla @.***> wrote:

If I see it correctly, NOAH+NOAHMP uses both liquid water equivalent and SNOWH as input as the logical "FNDSNOWH" is set to true in module_physics_init.F

— Reply to this email directly, view it on GitHub https://github.com/wrf-model/WRF/pull/1685#issuecomment-1049006630, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEIZ77FLMYLETDZSLRBAYKDU4UH25ANCNFSM5O2L5M2Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[dudhia]

@cenlinhe this has been in our queue for 2 years. Can we remove it, or is it something to consider? It is only making a change to real.exe to the snowh calculation. I am not sure if it is a better calculation than the one there already.

[cenlinhe]

I would prefer this is done in WPS, since this only applies for ECMWF data and should not be added as a general solution in real.exe for all datasets. So probably we could remove it.

[dudhia]

Closed noting comment from @cenlinhe