AWSM roadmap

[scotthavens]

AWSM is due for a little TLC and perhaps an overhaul. We've been using it for 3+ years now and have begun to dial in the likes, dislikes and the what were we thinking's. This issue aims to try and capture some of the ideas

Types of runs

• Research. Run a single year or multiple at one shot.
• Operational. Run in real time in a daily mode or custom.
• Forecasts. Run the model forward in time.
• Point model. Run Snobal in a point mode which is good for debugging.
• Ensemble. The holy grail 🏆 but may be an add on to AWSM that can spawn multiple instances of AWSM.

Data assimilation

• Snow depth update scheme from Hedrick et al 2018 which is already in AWSM.
• Placeholder for albedo
• Placeholder for cloud factor
• Placeholder for streamflow DA (once hydrology component is implemented).

Outputs

Right now there are 3 different ways that AWSM outputs simulation results:

• wyhr for water year hour which will produce folders like data_0000_1020
• start_end for the dates of start and end of the simulations like data_20200401_20200501
• day Each simulation is broken into daily folders, which is what the operational runs use

Propose to get rid of the wyhr as this isn't used.

ops and devel folders

The simulations are broken down into the following path format:

<basin>/<ops or devel>/<water year>/<project name>

This can lead to an incredible deep folder structure. Propose to drop the ops and devel split and instead use a descriptive project name or a new basin name like tuolumne_ops or king_devel.

Other features

• pip install
• restarting procedure for iSnobal crashes
• Remove the init4b and smrfOutputs folders which are legacy IPW hold overs
• remove the reporting features as snowav should be ran independently and is already done this way in the real time runs
• Use the Lakes for testing of the gridded data set capabilities like SMRF
• Use the SMRF API more fluidly rather than copy and paste aspects from SMRF.

New package structure

awsm
|____ framework
|     |    config and recipies
|     |    framework.py
|
|____ models
|     |    pysnobal
|     |    streamflow
|
|____ assimilation
|     |    snow depth
|     |    others 

[scotthavens]

Issues to address either as part of above or just because.

• [x] #33 more testing
• [x] #41 changing some of the output variable names in the snow and em netcdf
• [x] Combine snow and em netcdf?
• [ ] #43 using NaN instead of the IPW lower limit like -75 for snowpack temperature
• [x] #47 to output the forcing data when using pysnobal
• [ ] #52 restart automation
• [ ] #55 operational simulations running more time than needed which can save some processing time in the end
• [ ] #56 renaming the config options, many will go away
• [ ] #63 better error handling

[scotthavens]

Add to the documentation:

When using the following options, ensure that the restart period is prior to a storm.

• Marks2017 new snow density model
• smrf_ipysnobal model with or without threading
• restarting ipysnobal

The Marks2017 method will calculate the total storm mass to use in the calculations. If the restart date is during a storm, the total storm mass will not be the same and will result in different results. To test this, change the new snow density model in awsm.tests.restart.test_rme.TestSMRFiPysnobalRestart to marks2017 and the test will fail due to the restart date being within a storm.