Option to use Rain-Snow Elevation curve to determine form of precipitation?

[pdmich]

Paul Micheletty from RTI here-

Question

Is there going to be an option to use the rain-snow elevation curve to determine the form of the precipitation rather than just using the temperature to determine the precipitation form in this version of SNOW-17?

This would require having an option to pass in a rain-snow elevation time series and use the areal extent vs elevation curve (AVSE) as parameters to aid in calculating the form of precipitation. The default in SNOW-17 is just to use the temperature, which is appears to be currently implemented.

I saw this comment in the source code C...RAIN-SNOW ELEVATION CURVE FLAG TO 0 (ASSUME NEGLIGIBLE INFLUENCE) which leads me to believe that there is no plan to add other options.

Issue

Some NWS offices (e.g., CBRFC) use rain-snow elevation curve option operationally, so if we were to try to mimic those operations with this version of SNOW-17, there would be some (maybe very small?) differences in SNOW-17 output.

Mostly just curious - I don't know if others think this is necessary.

Here's some more documentation on options in the NWSRFS version of SNOW-17 if others are unfamiliar: https://www.weather.gov/media/owp/oh/hrl/docs/533snow17.pdf

[andywood]

Hi Paul, I think that's a good option to add and if you're able to add it as an issue in the repo, that would be great. It definitely has operational significance especially to current practice (also with CNRFC). Similar to the way we have dynamic PET as a module in Nextgen, modules for other dynamic inputs, such as rain/snow threshold, are possible. BMI can allow for setting that versus having snow17 read it from a file. Thanks for bringing it up.

On Thu, May 25, 2023 at 6:18 PM Paul Micheletty @.***> wrote:

Paul Micheletty from RTI here- Question

Is there going to be an option to use the rain-snow elevation curve to determine the form of the precipitation rather than just using the temperature to determine the precipitation form in this version of SNOW-17?

This would require having an option to pass in a rain-snow elevation time series and use the areal extent vs elevation curve (AVSE) as parameters to aid in calculating the form of precipitation. The default in SNOW-17 is just to use the temperature, which is appears to be currently implemented.

I saw this comment in the source code C...RAIN-SNOW ELEVATION CURVE FLAG TO 0 (ASSUME NEGLIGIBLE INFLUENCE) which leads me to believe that there is no plan to add other options. Issue

Some NWS offices (e.g., CBRFC) use rain-snow elevation curve option operationally, so if we were to try to mimic those operations with this version of SNOW-17, there would be some (maybe very small?) differences in SNOW-17 output.

Mostly just curious - I don't know if others think this is necessary.

Here's some more documentation on options in the NWSRFS version of SNOW-17 if others are unfamiliar: https://www.weather.gov/media/owp/oh/hrl/docs/533snow17.pdf

— Reply to this email directly, view it on GitHub https://github.com/NOAA-OWP/snow17/issues/32, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABIKARJ3LGIDZCJI4MHAUXTXH7ZGHANCNFSM6AAAAAAYPQ4PT4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[SnowHydrology]

@andywood Can you point to a Snow-17 version with the rain-snow elevation curve implemented?

[andywood]

Funnily enough -- that repo I was just asking about including in the OWP git space has the code for this although our test case example doesn't use it. I can check some other RFC basins to see if they include a RSNELEV implementation and how it's specified. I assume that's what you're looking for? I have the source code from OHD about 10 years ago, and we could implement it. It's not part of snow17 in nws-rfs versus a separate utility procedure/subroutine, but it could be made an option in the nextgen version of snow17.

ex42.f.txt

[andywood]

btw, the phrasing 'rain snow elevation curve' makes me wonder if Paul is asking about something different than RSNELEV. probably RSNELEV prepares the timeseries to be passed to snow17 which then uses the option he mentioned. This might be a better question for CBRFC to get the exact details, but whatever it is, we can implement it.

[SnowHydrology]

Thanks @andywood. I think we could integrate that code as a submodule here. I'm assuming "curve" refers to the area-elevation curve, but I agree it's worth double-checking. Do you have a contact at CBRFC you'd like to ask.

I also noted in the documentation @pdmich provided there's an option for forcing Snow-17 with a time series of % snowfall. We could easily make a precipitation phase module for NextGen. Let me know what you're thinking.

[pdmich]

Yeah I was referring to the RSNELEV operation. Currently, the RFC's are just running that operation , and then passing in the output to snow17. Currently, the PACK19 subroutine has the logic to use the RSNELEV output (see comment on line 104 in PACK19.f) but the EXSNOW19 subroutine that is being used is hardcoded to not use that option based on the comment in line 131.

I think a new RSNELEV subroutine could be a good option since this operation would probably never get used outside of SNOW17, but a separate precipitation phase module for NextGen could be interesting as well.

If you want some example inputs for a subbasin let me know. I can try to provide something based on some configurations we have from CBRFC.

[andywood]

@pdmich if you send your example inputs that would be helpful. I also have a few old RFC CHPS configs I can look through but it might be easier if you have it at your fingertips. We could put the subroutine into ioModule (where forcings are read), or create a new utilities module. Or the idea of a separate generic precip phase model that has it as an option that can be connected through BMI is interesting, though perhaps a bit more work.

[pdmich]

Example_RSNWELEV_Inputs.zip

Alright, see attached for some inputs. Note that these are used in the old NWSRFS MCP3 models that used card files. I reformatted the inputs to csv files so they are more readable though. There are a few funny things with these inputs such as daily PET inputs and 6-hourly temperature and precipitation. Those are old limitations of the MCP3 software.

The primary inputs that are important are in the RSNWELEV_Parameters.csv, which are used for the RSNWELEV operation. And then there are additional "SNOW17" parameters that are used if the RSNWELEV operation is used. Those are the AEC_Elev and AEC_Below values which are paired data that correspond to the area-elevation curve. The AEC_Elev# is an elevation and the AEC_Below# is the area below the specified elevation. The document referred to above shares some more details.

So, we could reformat these input to replace the example, or you could just add some of the needed RSNWELEV related parameters to current example (which might be easier).