doc/lgf.dox
author Peter Kovacs <kpeter@inf.elte.hu>
Fri, 17 Apr 2009 18:04:36 +0200
changeset 601 e6927fe719e6
parent 313 64f8f7cc6168
child 757 b1b534ddb539
permissions -rw-r--r--
Support >= and <= constraints in NetworkSimplex (#219, #234)

By default the same inequality constraints are supported as by
Circulation (the GEQ form), but the LEQ form can also be selected
using the problemType() function.

The documentation of the min. cost flow module is reworked and
extended with important notes and explanations about the different
variants of the problem and about the dual solution and optimality
conditions.
alpar@209
     1
/* -*- mode: C++; indent-tabs-mode: nil; -*-
alpar@156
     2
 *
alpar@209
     3
 * This file is a part of LEMON, a generic C++ optimization library.
alpar@156
     4
 *
alpar@440
     5
 * Copyright (C) 2003-2009
alpar@156
     6
 * Egervary Jeno Kombinatorikus Optimalizalasi Kutatocsoport
alpar@156
     7
 * (Egervary Research Group on Combinatorial Optimization, EGRES).
alpar@156
     8
 *
alpar@156
     9
 * Permission to use, modify and distribute this software is granted
alpar@156
    10
 * provided that this copyright notice appears in all copies. For
alpar@156
    11
 * precise terms see the accompanying LICENSE file.
alpar@156
    12
 *
alpar@156
    13
 * This software is provided "AS IS" with no warranty of any kind,
alpar@156
    14
 * express or implied, and with no claim as to its suitability for any
alpar@156
    15
 * purpose.
alpar@156
    16
 *
alpar@156
    17
 */
alpar@156
    18
alpar@156
    19
namespace lemon {
alpar@156
    20
/*!
alpar@156
    21
alpar@156
    22
alpar@156
    23
ladanyi@236
    24
\page lgf-format LEMON Graph Format (LGF)
alpar@156
    25
alpar@156
    26
The \e LGF is a <em>column oriented</em>
alpar@156
    27
file format for storing graphs and associated data like
alpar@156
    28
node and edge maps.
alpar@156
    29
alpar@156
    30
Each line with \c '#' first non-whitespace
alpar@156
    31
character is considered as a comment line.
alpar@156
    32
alpar@156
    33
Otherwise the file consists of sections starting with
alpar@156
    34
a header line. The header lines starts with an \c '@' character followed by the
alpar@156
    35
type of section. The standard section types are \c \@nodes, \c
alpar@156
    36
\@arcs and \c \@edges
alpar@156
    37
and \@attributes. Each header line may also have an optional
alpar@156
    38
\e name, which can be use to distinguish the sections of the same
alpar@156
    39
type.
alpar@156
    40
alpar@156
    41
The standard sections are column oriented, each line consists of
alpar@156
    42
<em>token</em>s separated by whitespaces. A token can be \e plain or
alpar@156
    43
\e quoted. A plain token is just a sequence of non-whitespace characters,
alpar@156
    44
while a quoted token is a
alpar@156
    45
character sequence surrounded by double quotes, and it can also
alpar@209
    46
contain whitespaces and escape sequences.
alpar@156
    47
alpar@156
    48
The \c \@nodes section describes a set of nodes and associated
kpeter@192
    49
maps. The first is a header line, its columns are the names of the
alpar@156
    50
maps appearing in the following lines.
alpar@156
    51
One of the maps must be called \c
alpar@156
    52
"label", which plays special role in the file.
alpar@156
    53
The following
alpar@156
    54
non-empty lines until the next section describes nodes of the
alpar@156
    55
graph. Each line contains the values of the node maps
alpar@156
    56
associated to the current node.
alpar@156
    57
alpar@156
    58
\code
alpar@156
    59
 @nodes
kpeter@212
    60
 label  coordinates  size    title
kpeter@212
    61
 1      (10,20)      10      "First node"
kpeter@212
    62
 2      (80,80)      8       "Second node"
kpeter@212
    63
 3      (40,10)      10      "Third node"
alpar@156
    64
\endcode
alpar@156
    65
alpar@156
    66
The \c \@arcs section is very similar to the \c \@nodes section,
kpeter@192
    67
it again starts with a header line describing the names of the maps,
alpar@156
    68
but the \c "label" map is not obligatory here. The following lines
alpar@156
    69
describe the arcs. The first two tokens of each line are
alpar@156
    70
the source and the target node of the arc, respectively, then come the map
alpar@156
    71
values. The source and target tokens must be node labels.
alpar@156
    72
alpar@156
    73
\code
alpar@156
    74
 @arcs
kpeter@212
    75
         capacity
alpar@156
    76
 1   2   16
alpar@156
    77
 1   3   12
alpar@156
    78
 2   3   18
alpar@156
    79
\endcode
alpar@156
    80
kpeter@313
    81
The \c \@edges is just a synonym of \c \@arcs. The \@arcs section can
deba@201
    82
also store the edge set of an undirected graph. In such case there is
deba@201
    83
a conventional method for store arc maps in the file, if two columns
deba@201
    84
has the same caption with \c '+' and \c '-' prefix, then these columns
deba@201
    85
can be regarded as the values of an arc map.
alpar@156
    86
alpar@156
    87
The \c \@attributes section contains key-value pairs, each line
deba@201
    88
consists of two tokens, an attribute name, and then an attribute
deba@201
    89
value. The value of the attribute could be also a label value of a
deba@201
    90
node or an edge, or even an edge label prefixed with \c '+' or \c '-',
deba@201
    91
which regards to the forward or backward directed arc of the
deba@201
    92
corresponding edge.
alpar@156
    93
alpar@156
    94
\code
alpar@156
    95
 @attributes
alpar@156
    96
 source 1
alpar@156
    97
 target 3
alpar@156
    98
 caption "LEMON test digraph"
alpar@156
    99
\endcode
alpar@156
   100
deba@162
   101
The \e LGF can contain extra sections, but there is no restriction on
deba@162
   102
the format of such sections.
deba@162
   103
alpar@156
   104
*/
alpar@156
   105
}
alpar@156
   106
alpar@156
   107
//  LocalWords:  whitespace whitespaces