Implicit assumption: time steps are numeric and consecutive

tum-ens / urbs

A linear optimisation model for distributed energy systems

GNU General Public License v3.0

177 stars 132 forks source link

Implicit assumption: time steps are numeric and consecutive #53

Open ojdo opened 8 years ago

ojdo commented 8 years ago

The storage state equation def_storage_state (and an upcoming PR #52 for demand side management) assume(s) that time step labels are numeric and allow for arithmetic operations like:

def def_storage_state_rule(m, t, sit, sto, com):
    return (m.e_sto_con[t, sit, sto, com] ==
            m.e_sto_con[t-1, sit, sto, com]

However, nothing in the input prevents time steps to have textual or (in future preferably) datetime type. The code should be changed to remove that assumption.

[ ] Find out how to idiomatically rewrite the code
[ ] Roll out change
[ ] Document it (could be the stem for a future contributor's guide doc/contributing.rst)

sonercandas commented 8 years ago

A new numeric, "timestep indexer" pyomo.Set can be introduced such as: m.timestepsnum = range(1,len(timesteps)) m.tnum= pyomo.Set(initialize=m.timestepsnum,ordered=True)

and then the required storage/DSM rules and corresponding pyomo variables such as m.e_sto_con can be defined over m.tnum rather than m.tm, regardless of the input timesteps are numeric or not?

ojdo commented 7 years ago

This first needs a minimal prototype that examines which "ripple" effects a change of t = [1, 2, 3, ...] to t = [2001-01-01 00:00, 2001-01-01 01:00, ...] would have on the different model steps:

data I/O (guess: positive)
model generation (between 'no effect' to 'one more abstraction layer necessary' everything seems possible. Time step weights w and m.dt must be derived and could possibly change per time step. Or not, then this should trigger warnings/errors.)
plotting (guess: automagic labelling of x-axis ticks)
reporting (guess: should just work)