Redundancy constraints
Opened this issue · 0 comments
ojdo commented
Transfer the redundancy feature from model dhmin.
Feature overview in dhmin
The relevant section in function dhmin.create_model
, lines 111-126:
# timestep preparation
if timesteps:
# extend timesteps with (name, duration, scaling factor) tuples and
# add a near-zero (here: 1 hour) legnth, nominal power timestep 'Pmax'
timesteps = [('t{}'.format(t[0]), t[0], t[1]) for t in timesteps]
timesteps.append(('Pmax', 1 , 1))
# now get a list of all source nodes
# for each source, add a non-availability timestep ('v0', 1, 1)
# and set availability matrix so that 'v0' is off in that timestep
availability = np.ones((len(timesteps) + len(source_vertex),
len(source_vertex)),
dtype=np.int)
for i, v0 in enumerate(source_vertex):
availability[len(timesteps), i] = 0
timesteps.append(('v{}'.format(v0), 1, 1))
This introduces 1 additional timestep for each source vertex, in which the source
The other notable change happens in the source vertex constraint, lines 302-306:
def source_vertices_rule(m, i, t):
if i in m.source_vertex:
return m.Q[i,t] <= m.vertices.ix[i]['capacity'] * m.availability[i,t]
else:
return m.Q[i,t] <= 0
Implementation details
- Automatic creation of the availability timesteps/parameters/constraints might be not desirable in the case of rivus. Where/how to specify, which process/vertex/edge/...model entity might be subject to a redundancy
- Instead of redundancy source vertices, rivus might benefit more from a redundancy feature that governs vertex processes. It might be inefficient (a.k.a. too many constraints) though if availability parameters would be generated for all vertices in a dataset. This feature might therefore require the introduction of an explicit vertex subset process vertices, similar to that of source vertices.
- (Optional, possibly a future issue) Reporting and plotting of results might require some thought, too. Right now, only a single instant (peak load, capacities and flows) are plotted.