Replace hard-coded figure numbers with cross-references (modelica#551)

docs/1___overview.adoc

@@ -95,14 +95,15 @@ On the other hand,
 some functionality requires source code.
 - Additional FMU data (such as tables or maps) in FMU specific file formats.
 
-A schematic view of an FMU is shown in Figure 1:
+A schematic view of an FMU is shown in <<figure-data-flow>>:
 
 .Data flow between the environment and an FMU.
+[#figure-data-flow]
+image::images/enclosing_model.svg[width=60%, align="center"]
+
 For details, see <<fmi-for-model-exchange>> and <<fmi-for-co-simulation>>.
 [blue]#Blue# arrows: Information provided by the FMU.
 [red]#Red# arrows: Information provided to the FMU.
-[caption="Figure 1: "]
-image::images/enclosing_model.svg[width=60%, align="center"]
 
 Publications for FMI are available from https://fmi-standard.org/literature/,
 specially Blochwitz et.al. http://www.ep.liu.se/ecp/063/013/ecp11063013.pdf[2011] and http://www.ep.liu.se/ecp/076/017/ecp12076017.pdf[2012].

docs/3_1_model_exchange_math.adoc

@@ -82,10 +82,10 @@ that is, a variable that changes its value only at an event instant latexmath:[t
 |A set of *continuous-time* and *discrete-time* variables
 |====
 
-At every event instant latexmath:[t_i], variables might be discontinuous (see Figure 3).
+At every event instant latexmath:[t_i], variables might be discontinuous (see <<figure-piecwise-continuous-variables>>).
 
 .Piecewise-continuous variables of an FMU: continuous-time (latexmath:[v_c]) and discrete-time (latexmath:[v_d]).
-[caption="Figure 3: "]
+[#figure-piecwise-continuous-variables]
 image::images/PieceWiseContinuousVariables.svg[width=60%]
 
 An [underline]#event instant# latexmath:[t_i] is defined by one of the following conditions that give the smallest time instant:
@@ -100,14 +100,14 @@ All the following events are internal events.
 . At a predefined time instant latexmath:[t_i=(T_{next}(t_{i-1}, 0)] that was defined at the previous event instant ti-1 by the FMU.
 Such an event is called [underline]##time event##.
 
-. At a time instant, where an [underline]#event indicator# latexmath:[z_j(t)] changes its domain from latexmath:[z_j > 0] to latexmath:[z_j \leq 0] or from latexmath:[z_j \leq 0] to latexmath:[z_j > 0] (see Figure 4 below).
+. At a time instant, where an [underline]#event indicator# latexmath:[z_j(t)] changes its domain from latexmath:[z_j > 0] to latexmath:[z_j \leq 0] or from latexmath:[z_j \leq 0] to latexmath:[z_j > 0] (see <<figure-events>> below).
 More precisely: An event latexmath:[t = t_i] occurs at the smallest time instant "min t" with latexmath:[t>t_{i-1}] where "latexmath:[(z_j(t)>0) \ne (z_j(t_{i-1}) >0)]".
 Such an event is called [underline]#state event# footnote:[This definition is slightly different from the standard definition of state events: "latexmath:[z_j(t) \cdot z_j(t_{i-1}) \leq 0]".
 This often used definition has the severe drawback that latexmath:[z_j(t_{i-1}) \ne 0] is required in order to be well-defined and this condition cannot be guaranteed.].
 All event indicators are piecewise continuous and are collected together in one vector of real numbers latexmath:[\mathbf{z(t)}]. +
 
 .An event occurs when the event indicator changes its domain from latexmath:[z>0] to latexmath:[z\leq 0] or vice versa.
-[caption="Figure 4: "]
+[#figure-events]
 image::images/Event.svg[width=60%, align="center"]
 
 [start=4]
@@ -208,10 +208,10 @@ In order to solve such systems of equations over FMUs efficiently, the dependenc
 This data is optionally provided in the XML file under element `<ModelStructure>`.
 If this data is not provided, the worst case must be assumed (for example, all output variables depend algebraically on all input variables).
 
-_[Example: In Figure 5 two different types of connected FMUs are shown (the "dotted lines" characterize the dependency information):_
+_[Example: In <<figure-connected-fmus>> two different types of connected FMUs are shown (the "dotted lines" characterize the dependency information):_
 
 .Calling sequences for FMUs that are connected in a loop.
-[caption="Figure 5: "]
+[#figure-connected-fmus]
 image::images/ArtificialAlgebraicLoop.svg[width=80%, align="center"]
 
 _In the upper diagram, FMU1 and FMU2 are connected in such a way that by an appropriate sequence of `fmi3SetXXX` and `fmi3GetXXX` calls, the FMU variables can be computed.
@@ -326,7 +326,7 @@ _[Remark 1 - Calling Sequences:_
 _In the table above, for notational convenience in every Mode one function call is defined to compute all output arguments from all inputs arguments.
 In reality, every scalar output argument is computed by one `fmi3GetXXX` function call.
 Additionally, the output argument need not be a function of all input arguments, but of only a subset from it, as defined in the XML file under_ `<ModelStructure>`.
-_This is essential when FMUs are connected in a loop, as shown in_ Figure 6: _For example, since_ latexmath:[y_{2a}] _depends only on_
+_This is essential when FMUs are connected in a loop, as shown in <<figure-connected-fmus>>. For example, since_ latexmath:[y_{2a}] _depends only on_
 latexmath:[u_{1a}] _, but not on_ latexmath:[u_{1b}]_, it is possible to call_ `fmi3SetXXX` _to set_ latexmath:[u_{1a}] _, and then inquire_ latexmath:[y_{2a}] _with_ `fmi3GetXXX` _without setting_ latexmath:[u_{1b}] _beforehand._
 
 _It is non-trivial to provide code for `fmi3SetXXX`, `fmi3GetXXX`, if the environment can call_ `fmi3SetXXX` _on the inputs in quite different orders.

docs/3___model_exchange.adoc

@@ -1,11 +1,12 @@
 == FMI for Model Exchange [[fmi-for-model-exchange]]
 This chapter contains the interface description to access the equations of a dynamic system from a C program.
-A schematic view of a model in "FMI for Model Exchange" format is shown in Figure 2:
+A schematic view of a model in "FMI for Model Exchange" format is shown in <<figure-model-exchange-data-flow>>:
+
+.Data flow between the environment and an FMU for Model Exchange
+[#figure-model-exchange-data-flow]
+image::images/model-exchange-data-flow.svg[width=80%, align="center"]
 
-.Data flow between the environment and an FMU for Model Exchange:
 [blue]*Blue* arrows: Information provided by the FMU. +
 [red]*Red* arrows : Information provided to the FMU. +
 *v*~start~, *u*, *y*, *w*, *x*~d~ are of type Real, Integer, Boolean, String;
 *t*, *x*~c~, *z* are of type Real.
-[caption="Figure 2:"]
-image::images/model-exchange-data-flow.svg[width=80%, align="center"]

docs/4_1_co-simulation_math.adoc

@@ -13,7 +13,6 @@ In a block representation of the coupled system, the subsystems are represented
 In this framework, the physical connections between subsystems are represented by mathematical coupling conditions between the inputs latexmath:[u(t)] and the outputs latexmath:[y(t)] of all subsystems, _Kübler and Schiehlen (2000)_.
 
 .Data flow at communication points.
-[caption="Figure 10: "]
 image::images/co-simulation-data-flow.svg[width=80%, align="center"]
 
 For co-simulation two basic groups of functions have to be realized:

docs/4_2_co-simulation_api.adoc

@@ -246,7 +246,6 @@ The example is given in a mix of pseudo-code and C, in order to keep it small an
 We consider two slaves, where both have one continuous real input and one continuous real output which are connected in the following way:
 
 .Connection graph of the slaves.
-[caption="Figure 12: "]
 image::images/co-simulation-connection-of-slaves.svg[width=30%, align="center"]
 
 We assume no algebraic dependency between input and output of each slave.

docs/4_3_co-simulation_schema.adoc

@@ -27,7 +27,7 @@ See also <<header-files-and-naming-of-functions>>.
 
 |`needsExecutionTool`
 |If true, a tool is needed to execute the model.
-The FMU just contains the communication to this tool (see Figure 8).
+The FMU just contains the communication to this tool (see <<figure-co-simulation-with-tool-coupling>>).
 _[Typically, this information is only utilized for information purposes.
 For example, a co-simulation master can inform the user that a tool has to be available on the computer where the slave is instantiated.
 The name of the tool can be taken from attribute `generationTool` of `fmiModelDescription`.]_

docs/4___co-simulation.adoc

@@ -3,14 +3,14 @@
 This chapter defines the Functional Mock-up Interface (FMI) for the coupling of two or more simulation models in a co-simulation environment (FMI for Co-Simulation).
 Co-simulation is a rather general approach to the simulation of coupled technical systems and coupled physical phenomena in engineering with focus on instationary (time-dependent) problems.
 
-FMI for Co-Simulation is designed both for coupling with subsystem models, which have been exported by their simulators together with its solvers as runnable code (Figure 7), and for coupling of simulation tools (simulator coupling, tool coupling (Figure 8 and Figure 7)).
+FMI for Co-Simulation is designed both for coupling with subsystem models, which have been exported by their simulators together with its solvers as runnable code (<<figure-co-simulation-with-generated-code>>), and for coupling of simulation tools (simulator coupling, tool coupling (<<figure-co-simulation-with-tool-coupling>> <<figure-co-simulation-with-generated-code>>)).
 
 .Co-simulation with generated code on a single computer (for simplicity shown for one slave only).
-[caption="Figure 7: "]
+[#figure-co-simulation-with-generated-code]
 image::images/co-simulation-single-slave.svg[width=50%, align="center"]
 
 .Co-simulation with tool coupling on a single computer (for simplicity shown for one slave only).
-[caption="Figure 8: "]
+[#figure-co-simulation-with-tool-coupling]
 image::images/co-simulation-tool-coupling.svg[width=70%, align="center"]
 
 In the tool coupling case the FMU implementation wraps the FMI function calls to API calls which are provided by the simulation tool (for example, a COM or CORBA API).
@@ -19,10 +19,10 @@ Additionally to the FMU the simulation tool is needed to run a co-simulation.
 In its most general form, a tool coupling based co-simulation is implemented on distributed hardware with subsystems being handled by different computers with different OS (cluster computer, computer farm, computers at different locations).
 The data exchange and communication between the subsystems is typically done using one of the network communication technologies (for example, MPI, TCP/IP).
 The definition of this communication layer is not part of the FMI standard.
-However, distributed co-simulation scenarios can be implemented using FMI as shown in Figure 9.
+However, distributed co-simulation scenarios can be implemented using FMI as shown in <<figure-distributed-co-simulation>>.
 
 .Distributed co-simulation infrastructure (for simplicity shown for one slave only).
-[caption="Figure 9: "]
+[#figure-distributed-co-simulation]
 image::images/co-simulation-distributed-infrastructure.svg[width=90%, align="center"]
 
 The master has to implement the communication layer.