+As an example of the "nested" nature of the variables, we can consider the problem above. There is a set of nodes called `grid` (that contain `nt` $\times$ `nx` nodes) for each `pipeline` OptiGraph, and each of these nodes contain a variable called `px` and `fx`. To access the `px` variable at $t = 1$ and $x = 2$ on the first pipeline subgraph of the vector, we can call `gas_network[:pipelines][1][:grid][1, 2][:px]`. Here, `[:pipelines]` acesses the vector of pipelines, `[1]` accesses the first subgraph of that vector, `[:grid]` accesses the set of nodes called "grid", `[1, 2]` accesses the node at time $t = 1$ and $x = 2$, and `[:px]` accesses the variable called `px`. Alternatively, instead of calling `gas_network[:pipelines][1]`, the same pipeline subgraph could be accessed by calling `getsubgraphs(gas_network)[26]`. Subgraphs appear in `getsubgraphs(::OptiGraph)` in the order they were added to the OptiGraph; as the junctions are added to `gas_network` first, followed by pipelines and then compressors in the above code, the first 25 entries of `getsubgraphs(gas_network)` will correspond to junctions and entries 26 - 38 will contain the pipelines. With the variable references, a user can query solutions to these variables after calling `optimize!(gas_network)` by using `JuMP.value`, such as calling `value(gas_network[:pipelines][1][:grid][1, 2][:px])`.
0 commit comments