Skip to content
New issue

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

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

Already on GitHub? # to your account

Suggestion for reducing SFR input #548

Closed
emorway-usgs opened this issue Aug 14, 2020 · 1 comment
Closed

Suggestion for reducing SFR input #548

emorway-usgs opened this issue Aug 14, 2020 · 1 comment

Comments

@emorway-usgs
Copy link
Contributor

When entering PERIOD data in SFR, which takes on the form:

### FOR ANY STRESS PERIOD

BEGIN PERIOD <iper>
<rno> <sfrsetting>
<rno> <sfrsetting>
...
END PERIOD

The parameter sfrsetting can take on the following values;

STATUS <status>
MANNING <manning>
STAGE <stage>
INFLOW <inflow>
RAINFALL <rainfall>
EVAPORATION <evaporation>
RUNOFF <runoff>
DIVERSION <idv> <divflow>
UPSTREAM_FRACTION <upstream_fraction>
AUXILIARY <auxname> <auxval>

For transient models with thousands of reaches, the burden for specifying rainfall, runoff, evaporation values can quickly add up. For example, the input may look something like the following (though thousands of lines longer), where sw_rain_rate and sw_evap_rate are time series:
betterway

I was thinking it might be an enhancement to allow the user to instead specify a boundname in place of the reach number rno, then all reaches associated with that boundname could be provided a RAINFALL value with one line. So for example, if I had a group of reaches with the boundname 'mainRiv', the input could be reduced to the following:

BEGIN period 1
  1       INFLOW      main
  mainRiv RAINFALL    sw_rain_rate
  mainRiv EVAPORATION sw_evap_rate
END period

and spare the input size. I think this would be a nice way to further leverage the boundname functionality.

@langevin-usgs
Copy link
Contributor

Added to list of requested features.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants