urbs icon indicating copy to clipboard operation
urbs copied to clipboard

Implicit assumption: time steps are numeric and consecutive

Open ojdo opened this issue 9 years ago • 2 comments

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)

ojdo avatar Mar 04 '16 12:03 ojdo

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?

sonercandas avatar May 21 '16 18:05 sonercandas

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)

ojdo avatar Aug 18 '16 13:08 ojdo