BUG: Hub process is used in a vertex

[lnksz]

From @ojdo's thesis (page 109):

Hub processes H ⊆ P are defined on edges and represent small-scale energy conversion
processes. These include all technologies that are installed within buildings, like boilers or
small-scale CHP units

If my understanding is right, the hub like 'Gas heating domestic' should not appear after
an optimisation in kappa_process, right? @ojdo @KSchoenleber

from rivus.main.rivus import create_model, get_constants
...
prob = create_model(data, vertex, edge)
solver = setup_solver(solver)
solver.solve(prob, tee=True)
_, _, _, kappa_process = get_constants(prob)

But it does. I will check my setup again and post the parameter set for reproducibility.

[lnksz]

a notebook analyzing the phenomenon on a "clean" branch.

git checkout master
git checkout -b test-process
git merge linelength_bug
# or for interactive selection (avoiding re-entry of unused imports)
git checkout -p linelength_bug -- rivus/main/rivus.py

zip with prob.pgz and an HTML plot

[KSchoenleber]

I am taking a look at it. I am a little unhappy with the chosen naming convention. since hub_processes are located on edges and I always think of hubs as nodes.

[lnksz]

So I changed the way the model sets are initialized.
Mainly m.process, m.process_input_tuples, m.process_output_tuples get a filtered version of process where the hub processes are not present.
Also, the cross-product for the within parameter had to be filtered as it uses the r_in and r_out MultiIndexed Series. Which contains the hubs.

As such, the optimum was found, and no hubs were used in any vertex.

But my solution time jumped from ~30s to ~30min !
--- UPDATE ----
That was something odd phenomena, as with other parameters, the bug-fix works and the solution time is around 30s

[ojdo]

Just my 2ct: yes, it is intentional that hub processes may be installed in vertices, and thus can appear in solutions. This simply means, that it is cheaper for the conversion product (e.g. heat) to be distributed through a dedicated (local or wide-spanning) network. Having 'Gas heating domestic' appear in a vertex thus means that having a (local or wide-spanning) heat transmission network is cheaper than having the gas being distributed to each hub, and have the heat generated there.

In short: from my point of view, this is no bug, but a (potentially interesting, or boring) result that can be fully explained by the parameter values (process and transmission costs).

@KSchoenleber: sorry for the confusing naming convention. I had read about "energy hubs" when naming processes in rivus. The hubs were meant to be the "light" version of full-blown, integer-variable-bearing vertex processes.

[lnksz]

Thank you for your reply @ojdo.

Just to clarify:

Did you plan Process.cap-max to keep this idea realistic (1)? I mean, to avoid distortion, that a possibly cheap hub gets favoured instead of a full-fledged process during the decision of building a network?

I am contemplating, how realistic this is. Like I know, the available pipe diameters are estimated as linear functions, but somehow my instinct goes against the phenomenon, that a domestic process would feasible to be the cornerstone of a network.

(1) in the haag15 data-set, all hubs have 50 MW maximum capacity. Which is kind of generous for one installation (But that is, what comes in mind if it is applied in a vertex, isn't it?) But could be realistic, if it is the maximum capacity of an edge (where demand is accumulated, and so the max-cap can also be regarded as a "scaled parameter".)

Note:

This should be documented. Now the cited part of the thesis is rather misleading.

Hub processes H ⊆ P are defined on edges and represent small-scale energy conversion
processes. These include all technologies that are installed within buildings, like boilers or
small-scale CHP units

Furthermore, the implemented switch in PR #37 could ensure that everybody can decide for himself, how the problem shall be formulated in this aspect.