Orienting the network

4.5.1 Orienting the network

Since the input network could be not completely directed, first of all we had to modify it in order to define a direction for each arc. Before starting the phase in which the direction

Organization Code:

UMD and UOB

European Commission

Classification:

Unclassidied

Sixth Framework Programme

of the arcs with attribute arc_dir equal to 0 is defined, another important check is performed. Let us consider a node whose degree (input or output) is not equal to 1: all the arcs connected to that node should have a direction definition in the input file. If this is not the case, a modification of the input data is needed because the direction of the arcs linked to that node is not uniquely defined. In this case, the user would receive a message with the identifier of the arcs that must be modified. At this point, the problem must be solved manually defining a direction for these arcs. The “manual definition” of the direction of these arcs should be very accurate, since one has to avoid incoherences, also taking into account the fact that our graph must be acyclic. After performing the check described above, we run a procedure that, taking as input the network data, propagates the direction to all the non-directed arcs.

The propagation of the directions starts identifying an arc a 1 whose direction is defined and an adjacent non-directed arc a 2 . In addition, starting from the common extreme of a 1 and a 2 , a sequence of adjacent nodes of input and output degree equal to 1 is identified. The sequence stops when a node connected to a directed arc a 3 is found. At this point the direction of the arcs connecting the sequence of nodes is uniquely identified propagating the

direction of a 1 . This should be coherent with the direction of a 3 and, in order to guarantee this, a check is performed. If the check is positive, we iteratively repeat this procedure

identifying another arc with defined direction, and continue until all the arcs have a direction, otherwise the user receives an error message with the identifiers of the arcs that could not be oriented because of incoherence. The procedure stops when it is not possible to identify directed arcs to propagate the direction to other arcs. Then, if one or more arcs are not oriented, an error occurs. In Figure 4-3, an example is presented. On the left, the non-directed

European Commission UMD and UOB Sixth Framework Programme

Organization Code:

arc (denoted with a dotted line) of the graph can be oriented propagating the direction of the adjacent arcs. On the right, the non-directed arc could not be oriented because of the incoherence of the direction of the adjacent arcs.

Once all arcs of the graph are directed, we want to be sure that the directed graph obtained is acyclic. This check is postponed, and performed just before the solution phase. Since in our algorithm we assume that the nodes are topologically ordered, we define this order through the procedure described in section 4.5.4. This procedure allows also to identify possible cycles in the graph.

Figure 4-3. On the left: on the top there is a graph partially directed, the only arc without direction is the one denoted with the dotted line, but the direction can be defined extending the one of the adjacent arcs. On the right: on the top there is a graph partially directed, the direction of the arc denoted with

a dotted line in this case cannot be defined extending the one of the adjacent arcs because there is an incoherence between the two adjacent arcs.

Organization Code:

UMD and UOB

European Commission

Classification:

Unclassidied

Sixth Framework Programme