1.1 --- a/adaptors.dox Sun Feb 21 15:07:35 2010 +0100
1.2 +++ b/adaptors.dox Sun Feb 21 15:07:59 2010 +0100
1.3 @@ -20,81 +20,106 @@
1.4 /**
1.5 [PAGE]sec_graph_adaptors[PAGE] Graph Adaptors
1.6
1.7 -\todo Clarify this section.
1.8 +In typical algorithms and applications related to graphs and networks,
1.9 +we usually encounter situations in which a specific alteration of a graph
1.10 +has to be considered.
1.11 +If some nodes or arcs have to be hidden (maybe temporarily) or the reverse
1.12 +oriented graph has to be used, then this is the case.
1.13 +However, actually modifing physical storage of the graph or
1.14 +making a copy of the graph structure along with the required maps
1.15 +could be rather expensive (in time or in memory usage) compared to the
1.16 +operations that should be performed on the altered graph.
1.17 +In such cases, the LEMON \e graph \e adaptor \e classes could be used.
1.18
1.19 -Alteration of standard containers need a very limited number of
1.20 -operations, these together satisfy the everyday requirements.
1.21 -In the case of graph structures, different operations are needed which do
1.22 -not alter the physical graph, but gives another view. If some nodes or
1.23 -arcs have to be hidden or the reverse oriented graph have to be used, then
1.24 -this is the case. It also may happen that in a flow implementation
1.25 -the residual graph can be accessed by another algorithm, or a node-set
1.26 -is to be shrunk for another algorithm.
1.27 -LEMON also provides a variety of graphs for these requirements called
1.28 -\ref graph_adaptors "graph adaptors". Adaptors cannot be used alone but only
1.29 -in conjunction with other graph representations.
1.30
1.31 -The main parts of LEMON are the different graph structures, generic
1.32 -graph algorithms, graph concepts, which couple them, and graph
1.33 -adaptors. While the previous notions are more or less clear, the
1.34 -latter one needs further explanation. Graph adaptors are graph classes
1.35 -which serve for considering graph structures in different ways.
1.36 +[SEC]sec_reverse_digraph[SEC] Reverse Oriented Digraph
1.37
1.38 -A short example makes this much clearer. Suppose that we have an
1.39 -instance \c g of a directed graph type, say ListDigraph and an algorithm
1.40 +Let us suppose that we have an instance \c g of a directed graph type, say
1.41 +\ref ListDigraph and an algorithm
1.42 \code
1.43 -template <typename Digraph>
1.44 -int algorithm(const Digraph&);
1.45 + template <typename Digraph>
1.46 + int algorithm(const Digraph&);
1.47 \endcode
1.48 -is needed to run on the reverse oriented graph. It may be expensive
1.49 -(in time or in memory usage) to copy \c g with the reversed
1.50 -arcs. In this case, an adaptor class is used, which (according
1.51 -to LEMON \ref concepts::Digraph "digraph concepts") works as a digraph.
1.52 -The adaptor uses the original digraph structure and digraph operations when
1.53 -methods of the reversed oriented graph are called. This means that the adaptor
1.54 -have minor memory usage, and do not perform sophisticated algorithmic
1.55 -actions. The purpose of it is to give a tool for the cases when a
1.56 -graph have to be used in a specific alteration. If this alteration is
1.57 -obtained by a usual construction like filtering the node or the arc set or
1.58 -considering a new orientation, then an adaptor is worthwhile to use.
1.59 -To come back to the reverse oriented graph, in this situation
1.60 +is needed to run on the reverse oriented digraph.
1.61 +In this situation, a certain adaptor class
1.62 \code
1.63 -template<typename Digraph> class ReverseDigraph;
1.64 + template <typename Digraph>
1.65 + class ReverseDigraph;
1.66 \endcode
1.67 -template class can be used. The code looks as follows
1.68 +can be used.
1.69 +
1.70 +The graph adaptors are special classes that serve for considering other graph
1.71 +structures in different ways. They can be used exactly the same as "real"
1.72 +graphs, i.e. they conform to the \ref graph_concepts "graph concepts", thus all
1.73 +generic algorithms can be performed on them. However, the adaptor classes
1.74 +cannot be used alone but only in conjunction with actual graph representations.
1.75 +They do not alter the physical graph storage, they just give another view of it.
1.76 +When the methods of the adaptors are called, they use the underlying
1.77 +graph structures and their operations, thus these classes have only negligible
1.78 +memory usage and do not perform sophisticated algorithmic actions.
1.79 +
1.80 +This technique yields convenient tools that help writing compact and elegant
1.81 +code, and makes it possible to easily implement complex algorithms based on
1.82 +well tested standard components.
1.83 +
1.84 +For solving the problem introduced above, we could use the follwing code.
1.85 +
1.86 \code
1.87 -ListDigraph g;
1.88 -ReverseDigraph<ListDigraph> rg(g);
1.89 -int result = algorithm(rg);
1.90 + ListDigraph g;
1.91 + ReverseDigraph<ListDigraph> rg(g);
1.92 + int result = algorithm(rg);
1.93 \endcode
1.94 -During running the algorithm, the original digraph \c g is untouched.
1.95 -This techniques give rise to an elegant code, and based on stable
1.96 -graph adaptors, complex algorithms can be implemented easily.
1.97
1.98 -In flow, circulation and matching problems, the residual
1.99 -graph is of particular importance. Combining an adaptor implementing
1.100 -this with shortest path algorithms or minimum mean cycle algorithms,
1.101 -a range of weighted and cardinality optimization algorithms can be
1.102 -obtained. For other examples, the interested user is referred to the
1.103 -detailed documentation of particular adaptors.
1.104 +Note that the original digraph \c g remains untouched during the whole
1.105 +procedure.
1.106
1.107 -The behavior of graph adaptors can be very different. Some of them keep
1.108 -capabilities of the original graph while in other cases this would be
1.109 -meaningless. This means that the concepts that they meet depend
1.110 -on the graph adaptor, and the wrapped graph.
1.111 -For example, if an arc of a reversed digraph is deleted, this is carried
1.112 -out by deleting the corresponding arc of the original digraph, thus the
1.113 -adaptor modifies the original digraph.
1.114 -However in case of a residual digraph, this operation has no sense.
1.115 +LEMON also provides simple "creator functions" for the adaptor
1.116 +classes to make their usage even simpler.
1.117 +For example, \ref reverseDigraph() returns an instance of \ref ReverseDigraph,
1.118 +thus the above code can be written like this.
1.119
1.120 -Let us stand one more example here to simplify your work.
1.121 -ReverseDigraph has constructor
1.122 \code
1.123 -ReverseDigraph(Digraph& digraph);
1.124 + ListDigraph g;
1.125 + int result = algorithm(reverseDigraph(g));
1.126 \endcode
1.127 -This means that in a situation, when a <tt>const %ListDigraph&</tt>
1.128 -reference to a graph is given, then it have to be instantiated with
1.129 -<tt>Digraph=const %ListDigraph</tt>.
1.130 +
1.131 +Another essential feature of the adaptors is that their \c Node and \c Arc
1.132 +types convert to the original item types.
1.133 +Therefore, the maps of the original graph can be used in connection with
1.134 +the adaptor.
1.135 +
1.136 +In the following code, Dijksta's algorithm is run on the reverse oriented
1.137 +graph but using the original node and arc maps.
1.138 +
1.139 +\code
1.140 + ListDigraph g;
1.141 + ListDigraph::ArcMap length(g);
1.142 + ListDigraph::NodeMap dist(g);
1.143 +
1.144 + ListDigraph::Node s = g.addNode();
1.145 + // add more nodes and arcs
1.146 +
1.147 + dijkstra(reverseDigraph(g), length).distMap(dist).run(s);
1.148 +\endcode
1.149 +
1.150 +In the above examples, we used \ref ReverseDigraph in such a way that the
1.151 +underlying digraph was not changed. However, the adaptor class can even be
1.152 +used for modifying the original graph structure.
1.153 +It allows adding and deleting arcs or nodes, and these operations are carried
1.154 +out by calling suitable functions of the underlying digraph (if it supports
1.155 +them).
1.156 +
1.157 +For this, \ref ReverseDigraph "ReverseDigraph<GR>" has a constructor of the
1.158 +following form.
1.159 +\code
1.160 + ReverseDigraph(GR& gr);
1.161 +\endcode
1.162 +
1.163 +This means that in a situation, when the modification of the original graph
1.164 +has to be avoided (e.g. it is given as a const reference), then the adaptor
1.165 +class has to be instantiated with \c GR set to be \c const type
1.166 +(e.g. <tt>GR = const %ListDigraph</tt>), as in the following example.
1.167 +
1.168 \code
1.169 int algorithm1(const ListDigraph& g) {
1.170 ReverseDigraph<const ListDigraph> rg(g);
1.171 @@ -102,41 +127,163 @@
1.172 }
1.173 \endcode
1.174
1.175 -<hr>
1.176 +\note Modification capabilities are not supported for all adaptors.
1.177 +E.g. for \ref ResidualDigraph (see \ref sec_other_adaptors "later"),
1.178 +this makes no sense.
1.179
1.180 -The LEMON graph adaptor classes serve for considering graphs in
1.181 -different ways. The adaptors can be used exactly the same as "real"
1.182 -graphs (i.e., they conform to the graph concepts), thus all generic
1.183 -algorithms can be performed on them. However, the adaptor classes use
1.184 -the underlying graph structures and operations when their methods are
1.185 -called, thus they have only negligible memory usage and do not perform
1.186 -sophisticated algorithmic actions. This technique yields convenient and
1.187 -elegant tools for the cases when a graph has to be used in a specific
1.188 -alteration, but copying it would be too expensive (in time or in memory
1.189 -usage) compared to the algorithm that should be executed on it. The
1.190 -following example shows how the \ref ReverseDigraph adaptor can be used
1.191 -to run Dijksta's algorithm on the reverse oriented graph. Note that the
1.192 -maps of the original graph can be used in connection with the adaptor,
1.193 -since the node and arc types of the adaptors convert to the original
1.194 -item types.
1.195 +As a more complex example, let us see how \ref ReverseDigraph can be used
1.196 +together with a graph search algorithm to decide whether a directed graph is
1.197 +strongly connected or not.
1.198 +We exploit the fact the a digraph is strongly connected if and only if
1.199 +for an arbitrarily selected node \c u, each other node is reachable from
1.200 +\c u (along a directed path) and \c u is reachable from each node.
1.201 +The latter condition is the same that each node is reachable from \c u
1.202 +in the reversed digraph.
1.203
1.204 \code
1.205 -dijkstra(reverseDigraph(g), length).distMap(dist).run(s);
1.206 + template <typename Digraph>
1.207 + bool stronglyConnected(const Digraph& g) {
1.208 + typedef typename Digraph::NodeIt NodeIt;
1.209 + NodeIt u(g);
1.210 + if (u == INVALID) return true;
1.211 +
1.212 + // Run BFS on the original digraph
1.213 + Bfs<Digraph> bfs(g);
1.214 + bfs.run(u);
1.215 + for (NodeIt n(g); n != INVALID; ++n) {
1.216 + if (!bfs.reached(n)) return false;
1.217 + }
1.218 +
1.219 + // Run BFS on the reverse oriented digraph
1.220 + typedef ReverseDigraph<const Digraph> RDigraph;
1.221 + RDigraph rg(g);
1.222 + Bfs<RDigraph> rbfs(rg);
1.223 + rbfs.run(u);
1.224 + for (NodeIt n(g); n != INVALID; ++n) {
1.225 + if (!rbfs.reached(n)) return false;
1.226 + }
1.227 +
1.228 + return true;
1.229 + }
1.230 \endcode
1.231
1.232 -Using \ref ReverseDigraph could be as efficient as working with the
1.233 -original graph, but not all adaptors can be so fast, of course. For
1.234 -example, the subgraph adaptors have to access filter maps for the nodes
1.235 -and/or the arcs, thus their iterators are significantly slower than the
1.236 -original iterators. LEMON also provides some more complex adaptors, for
1.237 -instance, \ref SplitNodes, which can be used for splitting each node in
1.238 -a directed graph and \ref ResidualDigraph for modeling the residual
1.239 -network for flow and matching problems.
1.240 +Note that we have to use the adaptor with '<tt>const Digraph</tt>' type, since
1.241 +\c g is a \c const reference to the original graph structure.
1.242 +The \ref stronglyConnected() function provided in LEMON has a quite
1.243 +similar implementation.
1.244
1.245 -Therefore, in cases when rather complex algorithms have to be used
1.246 -on a subgraph (e.g. when the nodes and arcs have to be traversed several
1.247 -times), it could worth copying the altered graph into an efficient structure
1.248 -and run the algorithm on it.
1.249 +
1.250 +[SEC]sec_subgraphs[SEC] Subgraph Adaptorts
1.251 +
1.252 +Another typical requirement is the use of certain subgraphs of a graph,
1.253 +or in other words, hiding nodes and/or arcs from a graph.
1.254 +LEMON provides several convenient adaptors for these purposes.
1.255 +
1.256 +\ref FilterArcs can be used when some arcs have to be hidden from a digraph.
1.257 +A \e filter \e map has to be given to the constructor, which assign \c bool
1.258 +values to the arcs specifying whether they have to be shown or not in the
1.259 +subgraph structure.
1.260 +Suppose we have a \ref ListDigraph structure \c g.
1.261 +Then we can construct a subgraph in which some arcs (\c a1, \c a2 etc.)
1.262 +are hidden as follows.
1.263 +
1.264 +\code
1.265 + ListDigraph::ArcMap filter(g, true);
1.266 + filter[a1] = false;
1.267 + filter[a2] = false;
1.268 + // ...
1.269 + FilterArcs<ListDigraph> subgraph(g, filter);
1.270 +\endcode
1.271 +
1.272 +The following more complex code runs Dijkstra's algorithm on a digraph
1.273 +that is obtained from another digraph by hiding all arcs having negative
1.274 +lengths.
1.275 +
1.276 +\code
1.277 + ListDigraph::ArcMap<int> length(g);
1.278 + ListDigraph::NodeMap<int> dist(g);
1.279 +
1.280 + dijkstra(filterArcs( g, lessMap(length, constMap<ListDigraph::Arc>(0)) ),
1.281 + length).distMap(dist).run(s);
1.282 +\endcode
1.283 +
1.284 +Note the extensive use of map adaptors and creator functions, which makes
1.285 +the code really compact and elegant.
1.286 +
1.287 +\note Implicit maps and graphs (e.g. created using functions) can only be
1.288 +used with the function-type interfaces of the algorithms, since they store
1.289 +only references for the used structures.
1.290 +
1.291 +\ref FilterEdges can be used for hiding edges from an undirected graph (like
1.292 +\ref FilterArcs is used for digraphs). \ref FilterNodes serves for filtering
1.293 +nodes along with the incident arcs or edges in a directed or undirected graph.
1.294 +If both arcs/edges and nodes have to be hidden, then you could use
1.295 +\ref SubDigraph or \ref SubGraph adaptors.
1.296 +
1.297 +\code
1.298 + ListGraph ug;
1.299 + ListGraph::NodeMap<bool> node_filter(ug);
1.300 + ListGraph::EdgeMap<bool> edge_filter(ug);
1.301 +
1.302 + SubGraph<ListGraph> sg(ug, node_filter, edge_filter);
1.303 +\endcode
1.304 +
1.305 +As you see, we needed two filter maps in this case: one for the nodes and
1.306 +another for the edges. If a node is hidden, then all of its incident edges
1.307 +are also considered to be hidden independently of their own filter values.
1.308 +
1.309 +The subgraph adaptors also make it possible to modify the filter values
1.310 +even after the construction of the adaptor class, thus the corresponding
1.311 +graph items can be hidden or shown on the fly.
1.312 +The adaptors store references to the filter maps, thus the map values can be
1.313 +set directly and even by using the \c enable(), \c disable() and \c status()
1.314 +functions.
1.315 +
1.316 +\code
1.317 + ListDigraph g;
1.318 + ListDigraph::Node x = g.addNode();
1.319 + ListDigraph::Node y = g.addNode();
1.320 + ListDigraph::Node z = g.addNode();
1.321 +
1.322 + ListDigraph::NodeMap<bool> filter(g, true);
1.323 + FilterNodes<ListDigraph> subgraph(g, filter);
1.324 + std::cout << countNodes(subgraph) << ", ";
1.325 +
1.326 + filter[x] = false;
1.327 + std::cout << countNodes(subgraph) << ", ";
1.328 +
1.329 + subgraph.enable(x);
1.330 + subgraph.disable(y);
1.331 + subgraph.status(z, !subgraph.status(z));
1.332 + std::cout << countNodes(subgraph) << std::endl;
1.333 +\endcode
1.334 +
1.335 +The above example prints out this line.
1.336 +\code
1.337 + 3, 2, 1
1.338 +\endcode
1.339 +
1.340 +Similarly to \ref ReverseDigraph, the subgraph adaptors also allow the
1.341 +modification of the underlying graph structures unless the graph template
1.342 +parameter is set to be \c const type.
1.343 +Moreover the item types of the original graphs and the subgraphs are
1.344 +convertible to each other.
1.345 +
1.346 +The iterators of the subgraph adaptors use the iterators of the original
1.347 +graph structures in such a way that each item with \c false filter value
1.348 +is skipped. If both the node and arc sets are filtered, then the arc iterators
1.349 +check for each arc the status of its end nodes in addition to its own assigned
1.350 +filter value. If the arc or one of its end nodes is hidden, then the arc
1.351 +is left out and the next arc is considered.
1.352 +(It is the same for edges in undirected graphs.)
1.353 +Therefore, the iterators of these adaptors are significantly slower than the
1.354 +original iterators.
1.355 +
1.356 +Using adaptors, these efficiency aspects should be kept in mind.
1.357 +For example, if rather complex algorithms have to be performed on a
1.358 +subgraph (e.g. the nodes and arcs need to be traversed several times),
1.359 +then it could worth copying the altered graph into an efficient
1.360 +structure (e.g. \ref StaticDigraph) and run the algorithm on it.
1.361 Note that the adaptor classes can also be used for doing this easily,
1.362 without having to copy the graph manually, as shown in the following
1.363 example.
1.364 @@ -147,32 +294,51 @@
1.365 // construct the graph and fill the filter map
1.366
1.367 {
1.368 - SmartDigraph temp_graph;
1.369 - ListDigraph::NodeMap<SmartDigraph::Node> node_ref(g);
1.370 - digraphCopy(filterNodes(g, filter_map), temp_graph)
1.371 + StaticDigraph tmp_graph;
1.372 + ListDigraph::NodeMap<StaticDigraph::Node> node_ref(g);
1.373 + digraphCopy(filterNodes(g, filter_map), tmp_graph)
1.374 .nodeRef(node_ref).run();
1.375
1.376 - // use temp_graph
1.377 + // use tmp_graph
1.378 }
1.379 \endcode
1.380
1.381 -<hr>
1.382 +\note Using \ref ReverseDigraph could be as efficient as working with the
1.383 +original graph, but most of the adaptors cannot be so fast, of course.
1.384
1.385 -Another interesting adaptor in LEMON is \ref SplitNodes.
1.386 -It can be used for splitting each node into an in-node and an out-node
1.387 -in a directed graph. Formally, the adaptor replaces each node
1.388 -u in the graph with two nodes, namely node u<sub>in</sub> and node
1.389 -u<sub>out</sub>. Each arc (u,c) in the original graph will correspond to an
1.390 -arc (u<sub>out</sub>,v<sub>in</sub>). The adaptor also adds an
1.391 -additional bind arc (u<sub>in</sub>,u<sub>out</sub>) for each node u
1.392 -of the original digraph.
1.393
1.394 -The aim of this class is to assign costs to the nodes when using
1.395 -algorithms which would otherwise consider arc costs only.
1.396 -For example, let us suppose that we have a directed graph with costs
1.397 -given for both the nodes and the arcs.
1.398 -Then Dijkstra's algorithm can be used in connection with \ref SplitNodes
1.399 -as follows.
1.400 +[SEC]sec_other_adaptors[SEC] Other Graph Adaptors
1.401 +
1.402 +Two other practical adaptors are \ref Undirector and \ref Orienter.
1.403 +\ref Undirector makes an undirected graph from a digraph disregarding the
1.404 +orientations of the arcs. More precisely, an arc of the original digraph
1.405 +is considered as an edge (and two arcs, as well) in the adaptor.
1.406 +\ref Orienter can be used for the reverse alteration, it assigns a certain
1.407 +orientation to each edge of an undirected graph to form a directed graph.
1.408 +A \c bool edge map of the underlying graph must be given to the constructor
1.409 +of the class, which define the direction of the arcs in the created adaptor
1.410 +(with respect to the inherent orientation of the original edges).
1.411 +
1.412 +\code
1.413 + ListGraph graph;
1.414 + ListGraph::EdgeMap<bool> dir_map(graph, true);
1.415 + Orienter<ListGraph> directed_graph(graph, dir_map);
1.416 +\endcode
1.417 +
1.418 +LEMON also provides some more complex adaptors, for
1.419 +instance, \ref SplitNodes, which can be used for splitting each node of a
1.420 +directed graph into an in-node and an out-node.
1.421 +Formally, the adaptor replaces each node u in the graph with two nodes,
1.422 +namely u<sub>in</sub> and u<sub>out</sub>. Each arc (u,v) of the original
1.423 +graph will correspond to an arc (u<sub>out</sub>,v<sub>in</sub>).
1.424 +The adaptor also adds an additional bind arc (u<sub>in</sub>,u<sub>out</sub>)
1.425 +for each node u of the original digraph.
1.426 +
1.427 +The aim of this class is to assign costs or capacities to the nodes when using
1.428 +algorithms which would otherwise consider arc costs or capacities only.
1.429 +For example, let us suppose that we have a digraph \c g with costs assigned to
1.430 +both the nodes and the arcs. Then Dijkstra's algorithm can be used in
1.431 +connection with \ref SplitNodes as follows.
1.432
1.433 \code
1.434 typedef SplitNodes<ListDigraph> SplitGraph;
1.435 @@ -183,16 +349,43 @@
1.436 dijkstra(sg, combined_cost).distMap(dist).run(sg.outNode(u));
1.437 \endcode
1.438
1.439 -Note that this problem can be solved more efficiently with
1.440 -map adaptors.
1.441 +\note This problem can also be solved using map adaptors to create
1.442 +an implicit arc map that assigns for each arc the sum of its cost
1.443 +and the cost of its target node. This map can be used with the original
1.444 +graph more efficiently than using the above solution.
1.445
1.446 -These techniques help writing compact and elegant code, and makes it possible
1.447 -to easily implement complex algorithms based on well tested standard components.
1.448 -For instance, in flow and matching problems the residual graph is of
1.449 -particular importance.
1.450 -Combining \ref ResidualDigraph adaptor with various algorithms, a
1.451 -range of weighted and cardinality optimization methods can be obtained
1.452 -directly.
1.453 +Another nice application is the problem of finding disjoint paths in
1.454 +a digraph.
1.455 +The maximum number of \e edge \e disjoint paths from a source node to
1.456 +a sink node in a digraph can be easily computed using a maximum flow
1.457 +algorithm with all arc capacities set to 1.
1.458 +On the other hand, \e node \e disjoint paths cannot be found directly
1.459 +using a standard algorithm.
1.460 +However, \ref SplitNodes adaptor makes it really simple.
1.461 +If a maximum flow computation is performed on this adaptor, then the
1.462 +bottleneck of the flow (i.e. the minimum cut) will be formed by bind arcs,
1.463 +thus the found flow will correspond to the union of some node disjoint
1.464 +paths in terms of the original digraph.
1.465 +
1.466 +In flow, circulation and matching problems, the residual network is of
1.467 +particular importance, which is implemented in \ref ResidualDigraph.
1.468 +Combining this adaptor with various algorithms, a range of weighted and
1.469 +cardinality optimization methods can be implemented easily.
1.470 +
1.471 +To construct a residual network, a digraph structure, a flow map and a
1.472 +capacity map have to be given to the constructor of the adaptor as shown
1.473 +in the following code.
1.474 +
1.475 +\code
1.476 + ListDigraph g;
1.477 + ListDigraph::ArcMap<int> flow(g);
1.478 + ListDigraph::ArcMap<int> capacity(g);
1.479 +
1.480 + ResidualDigraph<ListDigraph> res_graph(g, capacity, flow);
1.481 +\endcode
1.482 +
1.483 +\note In fact, this class is implemented using two other adaptors:
1.484 +\ref Undirector and \ref FilterArcs.
1.485
1.486 [TRAILER]
1.487 */
2.1 --- a/toc.txt Sun Feb 21 15:07:35 2010 +0100
2.2 +++ b/toc.txt Sun Feb 21 15:07:59 2010 +0100
2.3 @@ -22,6 +22,9 @@
2.4 **_own_maps
2.5 **_algs_with_maps
2.6 * sec_graph_adaptors
2.7 +** sec_reverse_digraph
2.8 +** sec_subgraphs
2.9 +** sec_other_adaptors
2.10 * sec_lp
2.11 * sec_lgf
2.12 * sec_tools