tum-ens/rivus

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

  1. 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
  2. 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.
  3. (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.