Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AWSM roadmap #71

Open
scotthavens opened this issue Jul 17, 2020 · 2 comments
Open

AWSM roadmap #71

scotthavens opened this issue Jul 17, 2020 · 2 comments

Comments

@scotthavens
Copy link
Contributor

scotthavens commented Jul 17, 2020

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
Copy link
Contributor Author

scotthavens commented Jul 17, 2020

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

This was referenced Sep 16, 2020
scotthavens added a commit that referenced this issue Sep 21, 2020
… which will greatly reduce the awsm codebase
This was referenced Oct 1, 2020
@scotthavens
Copy link
Contributor Author

scotthavens commented Oct 14, 2020

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.

This was referenced Oct 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants