You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
possibly subclass of Surface would make more sense
or a subclass of Storage or a subclass of Demand with varying capacity (e.g., TimevaryingDemand in Lea_GW setup)
The text was updated successfully, but these errors were encountered:
If you are implementing RainwaterHarvesting (RWH) separately and just want to create a timeseries of demand then TimevaryingDemand seems appropriate.
If you want an explicit representation within your WSIMOD model that you can dynamically change - something else is needed. I'd probably be inclined to make a subclass of Surface since a land node already has access to precipitation and ImperviousSurface with which there will be interactions.
If it is just for garden irrigation then it makes sense to be linked with GardenSurface and can probably be handled entirely in that subclass.
If there are indoors uses - you probably want the following:
Subclass of Land that introduces the handler - self.push_set_handler[("Demand", "RWH")] = <new_function>.
New_function should pull from ImperviousSurface. You will probably need some state variable to track amount pulled, since Land.run is called after Demand.create_demand in default orchestration.
Subclass of ResidentialDemand - with a Tank object, that calls pull for RWH to the Land.
Though possibly if you move the RWH Tank into the new Land node, you don't need to worry as much about tracking/interfering with orchestration etc.
possibly subclass of
Surface
would make more senseor a subclass of
Storage
or a subclass ofDemand
with varying capacity (e.g.,TimevaryingDemand
in Lea_GW setup)The text was updated successfully, but these errors were encountered: