Smaller and variable step-size for solver about wntr HOT 9 CLOSED

from wntr.

Thanks a lot for the quick response. This sounds like exciting news, I am looking forward to the updates!
I understand the limitation of the step-size for the EPANET Simulator, but does the same apply to the WNTR simulator? Maybe there are some restrictions I don't see.

from wntr.

@Stormyend, both simulators use the TimeOptions class for time-based simulation options. The hydraulic_timestep attribute is required to be an integer>=1, which represents the number of seconds for the timestep. For more information, check out the API docs for the mentioned class.

from wntr.

Hi @kbonney , thanks for your response! I understand that the requirement for the timestep is to be >=1, however I was wondering where this limitation comes from, as it is no limitation given by the solver or the equations, but given by the WNTR framework. When I rewrite the modulo-statements to work with floats/timesteps < 1 and bypass the if-statements, the simulation results still seem to be correct.
However I was wondering what the reason for the limitation is in the first place.
I hope my question is clear, thank you very much in advance!

from wntr.

@Stormyend - Are you using the EPANET simulator or the WNTR simulator?

from wntr.

Sorry for being vague, I am using the WNTR simulator.

from wntr.

This is not a "real" limitation. You are absolutely right. I think we just never considered going less than 1 second. I think there is some logic in there that relies on the time step being an integer (which is why we make sure it is an integer), but that is just an implementation detail. It could certainly be updated.

from wntr.

@Stormyend for reference EPANET-MSX now allows microsecond timesteps but as ints (which limits the total duration of a simulation to about 595 hours for extended period simulations). The one consideration when using a float is precision, so will 0.1 or 0.01 timesteps always yield 10 or 100 intervals per second because of machine precision? An alternative approach would be to include a subsecond loop with another range of ints to avoid that possible edge case.

from wntr.

Thank you both for the comments! I will keep the float precision problem in mind when implementing it! :)

from wntr.