Test same node ID for different node types

[visr]

With #1113 we theoretically support having e.g. both Basin #5 and Pump #5 in the same model. Now that #1110 is merged, we should test that this works properly.

Related to #1256.

[SouthEndMusic]

I suggest adapting the main_network_with_subnetworks model for this as it covers a lot of ground.

A Question about a crashing simulation by Josje van Houwelingen (does she have a Github account to tag? EDIT: @JvanHouwelingen) also pointed out that the sparse capacity matrix (see mainly allocation_init.jl) uses node ID numbers as indices directly, which isn't valid anymore already since the introduction of the MetaGraph. Would a dictionary be a good replacement here, or is there some sparse matrix object which allows generic index sets?

[visr]

would a dictionary be a good replacement here, or is there some sparse matrix object which allows generic index sets?

It's worth checking if we can use this:

https://jump.dev/JuMP.jl/stable/manual/containers/#SparseAxisArray
https://jump.dev/JuMP.jl/stable/api/JuMP.Containers/#JuMP.Containers.SparseAxisArray

[SouthEndMusic]

would a dictionary be a good replacement here, or is there some sparse matrix object which allows generic index sets?

It's worth checking if we can use this:

https://jump.dev/JuMP.jl/stable/manual/containers/#SparseAxisArray https://jump.dev/JuMP.jl/stable/api/JuMP.Containers/#JuMP.Containers.SparseAxisArray

Why is this worth using? What is useful about the SparseAxisArray wrapper around a dictionary that cannot be achieved by just using a dictionary? Especially since there is no direct interaction between the capacity object and the other JuMP objects in our code.

[SouthEndMusic]

@visr I also have to make a get method which calls get on the wrapped dictionary, because accessing missing values is not supported on SparseAxisArray.

[visr]

Oh yeah I just assumed it may be easier if it supports the array interface, but if that isn't the case, a dictionary is simpler.

[SouthEndMusic]

I realized that I don't actually need that get method after all, see 0229364. Keeping the use of the array interface in allocation_init.jl is nice 👍