This section presents language elements for describing synchronous behavior suited for implementation of control systems.
[This chapter defines additional kinds of discretetime variables and equations, as well as an additional kind of whenclause, in order to define sampled data systems in a safe way, so that the translator can provide good diagnostics in case of a modeling error.
The following small example shows the most important elements
A periodic clock is defined with Clock(3). The argument of Clock(..) defines the sampling interval (for details see section 16.3).
Clocked variables (such as yd, xd, ud) are associated uniquely with a clock and can only be directly accessed when the associated clock is active. Since all variables in a clocked equation must belong to the same clock, clocking errors can be detected at compile time. If variables from different clocks shall be used in an equation, explicit cast operators must be used, such as sample(..) to convert from continuoustime to clocked discretetime or hold(..) to convert from clocked discretetime to continuoustime.
A continuoustime variable is sampled at a clock tick with the sample(..) operator. The operator returns the value of the continuoustime variable when the clock is active.
When no argument is defined for Clock(), the clock is deduced by clock inference.
For a whenclause with an associated clock, all equations inside the whenclause are clocked with the given clock. All equations on an associated clock are treated together and in the same way regardless of whether they are inside a whenclause or not. This means that automatic sampling and hold of variables inside the whenclause does not apply (explicit sampling and hold is required) and that general equations can be used in such whenclauses (this is not allowed for whenclauses with Boolean conditions, that require a variable reference on the lefthand side of an equation).
The whenclause in the controller could also be removed and the controller could just be defined by the equations:
The operator previous(xd) returns the value of xd at the previous clock tick. At the first sample instant, the start value of xd is returned.
A discretetime signal (such as ud) is converted to a continuoustime signal with the hold(..) operator.
If a variable belongs to a particular clock, then all other equations where this variable is used, with the exception of as argument to certain special operators, belong also to this clock, as well as all variables that are used in these equations. This property is used for “clock inference” and allows to define an associated clock only at a few places (above only in the sampler, whereas in the discrete controller and the hold the sampling period is inferred)
The approach in this chapter is based on the clock calculus and inference system proposed by (Colaco and Pouzet 2003) and implemented in Lucid Synchrone version 2 and 3 (Pouzet 2006). However, the Modelica approach also uses multirate periodic clocks based on rational arithmetic introduced by (Forget et. al. 2008), as an extension of the Lucid Synchrone semantics. These approaches belong to the class of synchronous languages (Benveniste et. al. 2002).
Periodically sampled control systems could also be defined with standard whenclauses, see section 8.3.5, and the sample operator, see section 3.7.3. For example:
Equations in a whenclause with a Boolean condition have the property that (a) variables on the left hand side of the equal sign are assigned a value when the whencondition becomes true and otherwise hold their value, (b) variables not assigned in the whenclause are directly accessed (= automatic “sample” semantics), and (c) the variables assigned in the whenclause can be directly accessed outside of the whenclause (= automatic “hold” semantics). This approach to define periodically sample data systems has the following drawbacks that are not present with the solution in this chapter using clocks and clocked equations:
It is not possible to detect sampling errors due to the automatic sample and hold semantics. Examples:
If whenclauses in different blocks should belong to the same controller part, but by accident different whenconditions are given, then this is accepted (no error is detected)..
If a sampled data library such as the Modelica_LinearSystems2.Contoller library is used, at every block the sampling of the block has to be defined as integer multiple of a base sampling rate. If several blocks should belong to the same controller part, and different integer multiples are given, then the translator has to accept this (no error is detected).
Due to the automatic sample and hold semantics, all variables assigned in a whenclause of the above kind must have an initial value because they might be used, before they are assigned a value the first time. As a result, all these variables are “discretetime states” although in reality only a small subset of them need an initial value.
Only a restricted form of equations can be used in a standard whenclause, since the left hand side has to be a variable, in order to identify the variables that are assigned in the whenclause. This is a severe restriction, especially if nonlinear control algorithms shall be defined. This restriction is not present for clocked equations.
All equations belonging to a discrete controller must be in a when clause. If the controller is builtup with several building blocks, then the clock condition (sampling) must be explicitly propagated to all blocks. This is tedious and error prone. With clocked equations, the clock condition need to be defined only at one place, and otherwise is automatically propagated by clock inference.
It is not possible to use a continuoustime model in when clauses (e.g. some advanced controllers use an inverse model of a plant in the feedforward path of the controller, see (Thümmel et. al. 2005)). This powerful feature of Modelica to use a nonlinear plant model in a controller would require to export the continuoustime model with an embedded integration method and then import it in an environment where the rest of the controller is defined. With clocked equations, clocked controllers with continuoustime models can be directly defined in Modelica.
At a sample instant, an event iteration occurs (as for any other event). A clocked partition, as well as a whenclause with a sample(..) is evaluated exactly once at such an event instant. However, the continuoustime model to which the sampled data controller is connected, will be evaluated several times when the overall system is simulated. With whenclauses, the continuoustime part is typically evaluated three times at a sample instant (once, when the sample instant is reached, once to evaluate the continuous equations at the sample instant, and once when an event iteration occurs since a discrete variable v is changed and pre(v) appears in the equations). With clocked equations, no event iteration is triggered if a clocked variable v is changed and previous(v) appears in the equations, because the event iteration cannot change the value of v. As a result, typically the simulation model is evaluated twice at a sample instant and therefore the simulation is more efficient with clocked equations.
]
In this section various terms are defined.
In section 3.8.3 the term “discretetime” Modelica expression and in section 3.8.4 the term “continuoustime” Modelica expression is defined. In this chapter, two additional kinds of discretetime expressions/variables are defined that are associated to clocks and are therefore called “clocked discretetime” expressions:
The different kinds of discretetime variables in Modelica  









]
The following concepts are used:
A “baseclock partition” identifies a set of equations and a set of variables which must be executed together in one task. Different baseclock partitions can be associated to separate tasks for asynchronous execution.
A “subclock partition” identifies a subset of equations and a subset of variables of a baseclock partition which are partially synchronized with other subclock partitions of the same baseclock partition, i.e., synchronized when the ticks of the respective clocks are simultaneous.
The builtin operators (with function syntax) defined in the following sections have partially restrictions on their input arguments that are not present for Modelica functions. To define the restrictions, the following term is defined:
Component Expression:
A Component Reference which is an Expression, i.e. does not refer to models or blocks with equations. It is an instance of a (a) base type, (b) derived type, (c) record, (d) an array of such an instance (ac), (e) one or more elements of such an array (d) defined by index expressions which are parameter expressions (see below), or (f) an element of records. [The essential features are that one or several values are associated with the instance, that start values can be defined on these values, and that no equations are associated with the instance. A Component Expression can be constant or can vary with time.]
In the following sections the following notation is partially used when defining the operators:
The input argument is a Component Expression:
The meaning is that the input argument when calling the operator must be a Component Expression.
[The reason for this restriction is that the start value of the input argument is returned before the first tick of the clock of the input argument and this is not possible for a general expression.
Examples:
]
The input argument is a parameter expression:
The meaning is that the input argument when calling the operator must have parameter variability, that is the argument must depend directly or indirectly only on parameters, constants or literals, see section 3.8.
[The reason for this restriction is that the value of the input argument needs to be evaluated during translation, in order that clock analysis can be performed during translation.
Examples:
]
The input argument is an expression:
There is no restriction on the input argument when calling the operator. This notation is used to emphasis when a standard function call is used (“is an expression”), instead of restricting the input (“is a Component Expression”).
The following overloaded constructors are available to generate clocks:
Clock() 





Clock(interval) 








Besides inferred clocks and solver clocks, one of the following mutually exclusive associations of clocks are possible in one base partition:
One or more Rational interval clocks, provided they are consistent
with each other, see section 16.7.5.
[For example, assume “y = subSample(u)”, and Clock(1,10) is
associated to “u” and Clock(2,10) is associated with “y”, then
this is correct, but it would be an error if “y” is associated to a
Clock (1,3). ]
Exactly one Real interval clock. [Assume“Clock c = Clock(2.5)”, then variables in the same base partition can be associated multiple times with “c” but not multiple times with “Clock(2.5)”]
Exactly one Boolean clock.
A default clock, if neither a Real interval, nor a Rational interval nor a Boolean clock is associated with a base partition. In this case the default clock is associated with the fastest subclock partition. [Typically, a tool will use Clock(1.0) as a default clock and will raise a warning, that it selected a default clock.]
Clock variables can be used in a restricted form of expressions. Generally, every expression containing clock variables must have parametric variability [in order that clock analysis can be performed when translating a model.]. Otherwise, the following expressions are allowed:
Declaring arrays of clocks [Example: Clock c1[3] ={Clock(1), Clock(2), Clock(3)} ]
Array constructors of clocks: {}, [], cat(...).
Array access of clocks [Example: sample(u, c1[2])]
Equality of clocks [Example: c1 = c2].
Ifexpressions of clocks in equations
[Example: Clock c2 = if f>0 then subSample(c1, f) elseif f<0 then superSample(c1, f) else c1].
Clock variables can be declared in models, blocks, connectors, and records,. A Clock variable can be declared with the prefixes input, output, inner, outer, but not with the prefixes flow, stream, discrete, parameter, or constant [Example: connector ClockInput = input Clock;]
The previous value of a clocked variable can be accessed with the previous operator. Such a variable is called a clocked state variable.
previous(u)  The input argument is a Component Expression (see section 16.2.3) or a parameter expression. The return argument has the same type as the input argument. Input and return arguments are on the same clock. At the first tick of the clock of u or after a reset transition (see section 17.3.2), the start value of u is returned, see section 16.9. At subsequent activations of the clock of u, the value of u from the previous clock activation is returned. 
A set of “clock conversion operators” together act as boundaries between different clock partitions.
The following operators convert between a continuoustime and a clockedtime representation and vice versa:
sample(u, c)  Input argument u is a continuoustime expression according to section 3.8.4. The optional input argument c is of type Clock. The operator returns a clocked variable that has c as associated clock and has the value of the left limit of u when c is active (that is the value of u just before the event of c is triggered). If argument c is not provided, it is inferred, see section 16.7.5. [Since the operator returns the left limit of u, it introduces an infinitesimal small delay between the continuoustime and the clocked partition. This corresponds to the reality, where a sampled data system cannot act infinitely fast and even for a very idealized simulation, an infinitesimal small delay is present. The consequences for the sorting are discussed below. Input argument u can be a general expression, because the argument is continuoustime and therefore has always a value. It can also be a constant, a parameter or a piecewise constant expression. Note that sample() is an overloaded function: If sample(..) has two input arguments and the second argument is of type Real, it is the operator from section 3.7.3. If sample(..) has one input argument, or it has two input arguments and the second argument if of type Clock, it is the baseclock conversion operator from this section.] 
hold(u)  Input argument u is a clocked Component Expression (see section 16.2.3) or a parameter expression. The operator returns a piecewise constant signal of the same type of u. When the clock of u ticks, the operator returns u and otherwise returns the value of u from the last clock activation. Before the first clock activation of u, the operator returns the start value of u, see section 16.9. [Since the input argument is not defined before the first tick of the clock of u, the restriction is present, that it must be a Component Expression (or a parameter expression), in order that the initial value of u can be used in such a case.] 
[Example:
Assume there is the following model:
The value of yc at the first clock tick is yc=2 (and not yc=1 ). The reason is that the continuoustime model der(y)+y=2 is first initialized and after initialization y has the value 2. At the first clock tick at time=0, the left limit of y is 2 and therefore yc = 2.
Sorting of a simulation model:
Since sample(u) returns the left limit of u, and the left limit of u is
a known value, all inputs to a baseclock partition are treated as known
during sorting. Since a periodic and interval clock can tick at most
once at a time instant, and since the left limit of a variable does not
change during event iteration (i.e., reevaluating a baseclock
partition associated with a condition clock always gives the same result
because the sample(u) inputs do not change and therefore need not to be
reevaluated) all baseclock partitions, see section 16.7.3, need
not to be sorted with respect to each other. Instead, at an event
instant, active baseclock partitions can be evaluated first (and once)
in any order. Afterwards, the continuoustime partition is evaluated.
Event iteration takes place only over the continuoustime partition. In
such a scenario, accessing the left limit of u in sample(u) just means
to pick the latest available value of u when the partition is entered,
storing it in a local variable of the partition and only using this
local copy during evaluation of the equations in this partition.]
The following operators convert between synchronous clocks:
The operators in this table have the following properties: The input argument u is a clocked expression or an expression of type Clock. [The operators can operate on all types of clocks]. If u is a clocked expression, the operator returns a clocked variable that has the same type as the expression. If u is an expression of type Clock, the operator returns a Clock. The optional input arguments factor (default=0, min=0), and resolution (default=1, min=1) are parameter expressions of type Integer. The input arguments shiftCounter and backCounter are parameter expressions of type Integer (min=0).  
subSample(u, factor)  The clock of y = subSample(u,factor) is factortimes slower than the clock of u. At every factor ticks of the clock of u, the operator returns the value of u.. The first activation of the clock of y coincides with the first activation of the clock of u. If argument factor is not provided or is equal to zero, it is inferred, see section 16.7.5.  
superSample(u, factor)  The clock of y = superSample(u,factor) is factortimes faster
than the clock of u. At every tick of the clock of y, the operator
returns the value of u from the last tick of the clock of u. The first
activation of the clock of y coincides with the first activation of the
clock of u. If argument factor is not provided or is equal to zero, it
is inferred, see section 16.7.5. If a Boolean clock is associated to a
baseclock partition, all its subclock partitions must have resulting
clocks that are subsampled with an Integer factor with respect to this
base clock.
[Example:
Clock u = Clock(x > 0);
Clock y1 = subSample(u,4);
Clock y2 = superSample(y1,2); // fine; y2 = subSample(u,2)
Clock y3 = superSample(u ,2); // error
Clock y4 = superSample(y1,5); // error



[The first activation of the clock of y =
shiftSample(..) is shifted in time
shiftCounter/resolution*interval(u) later than the first activation of
the clock of u.].
Conceptually, the operator constructs a clock “cBase”
Clock cBase = subSample(superSample(u,resolution), shiftCounter)
// Rational interval clock
Clock u = Clock(3, 10); // ticks: 0, 3/10, 6/10, ..
Clock y1 = shiftSample(u,1,3); // ticks: 1/10, 4/10,
...
// Boolean clock
Clock u = Clock(sin(2*pi*time)>0, startInterval=0.0)
// ticks: 0.0, 1.0, 2.0, 3.0, …
Clock y1 = shiftSample(u,2); // ticks: 2.0, 3.0, …
Clock y2 = shiftSample(u,2,3);// error (resolution must be 1)



The input argument u is either a Component Expression (see
section 16.2.3) or an expression of type Clock. [The first activation of
the clock of y = backSample(..) is shifted in time
backCounter/resolution*interval(u) before the first activation
of the clock of u]. Conceptually, the operator constructs a clock
“cBase”
Clock cBase = subSample(superSample(u,resolution), backCounter)
// Rational interval clock 1
Clock u = Clock(3, 10); // ticks: 0, 3/10, 6/10, ..
Clock y1 = shiftSample(u,3); // ticks: 9/10, 12/10, ..
Clock y2 = backSample(y1,2); // ticks: 3/10, 6/10,
...
Clock y3 = backSample(y1,4); // error (ticks before u)
Clock y4 = shiftSample(u,2,3); // ticks: 2/10, 5/10,
...
Clock y5 = backSample(y4,1,3); // ticks: 1/10, 4/10,
...
// Boolean clock
Clock u = Clock(sin(2*pi*time) > 0, startInterval=xx)
// ticks: 0, 1.0, 2.0, 3.0, ….
Clock y1 = shiftSample(u,3); // ticks: 3.0, 4.0, …
Clock y2 = backSample(y1,2); // ticks: 1.0, 2.0, …


noClock(u)  The clock of y = noClock(u) is always inferred. At every tick of the clock of y, the operator returns the value of u from the last tick of the clock of u. If noClock(u) is called before the first tick of the clock of u, the start value of u is returned. 
[Clarification of backSample(..) operator:
Let a and b be positive integers with a < b, and
Then when ys exists, also yb exists and ys = yb.
The variable yb exists for the above parameterization with a<b one clock tick before ys. Therefore,
backSample is basically
a shiftSample with a different parameterization and the clock
of backSample.y ticks before the clock of u. Before the clock
of u ticks, yb = u.start.
Clarification of noClock(..) operator:
Note, that noClock(u) is not equivalent to sample(hold(u)). Consider the following model:
Due to the infinitesimal delay of sample; z will not show the current value of x as clk2 ticks, but will show its previous value (left limit). However, y will show the current value, since it has no infinitesimal delay.]
In addition to the previously discussed conditional whenclause, a clocked whenclause is introduced:
The clocked whenclause cannot be nested and does not have any elsewhen part. It cannot be used inside an algorithm. General equations are allowed in a clocked whenclause.
For a clocked whenclause, all equations inside the whenclause are clocked with the same clock given by the clockexpression.
This section defines how clockpartitions and clocks associated with equations are inferred. [Typically clock partitioning is performed before sorting the equations. The benefit is that clocking and symbolic transformation errors are separated.]
Every clocked variable is uniquely associated with exactly one clock.
After model flattening, every equation in an equation section, every expression and every algorithm section is either continuoustime, or it is uniquely associated with exactly one clock. In the latter case it is called a clocked equation, a clocked expression or clocked algorithm section respectively. The associated clock is either explicitly defined by a whenclause, see section 16.5.2, or it is implicitly defined by the requirement that a clocked equation, a clocked expression and a clocked algorithm section must have the same clock as the variables used in them with exception of the expressions used as first arguments in the conversion operators of section 16.5. Clock inference means to infer the clock of a variable, an equation, an expression or an algorithm section if the clock is not explicitly defined and is deduced from the required properties in the previous two paragraphs.
All variables in an expression without clock conversion operators must have the same clock to infer the clocks for each variable and expression. The clock inference works both forward and backwards regarding the data flow and is also being able to handle algebraic loops. The clock inference method uses the set of variable incidences of the equations, i.e., what variables that appear in each equation.
Note that incidences of the first argument of clock conversion operators of section 16.5 are handled specially.
The clock partitioning is conceptually performed after model flattening, i.e., redeclarations have been elaborated, arrays of model components expanded into scalar model components, and overloading resolved. Furthermore, function calls to inline functions have been inlined. [This is called “conceptually”, because a tool might do this more efficiently in a different way, provided the result is the same as if everything is flattened. For example, array and matrix equations and records don’t not need to be expanded if they have the same clock.]
Furthermore, each nontrivial expression (nonliteral, nonconstant, nonparameter, nonvariable), expr_{i}, appearing as first argument of any clock conversion operator is recursively replaced by a unique variable, v_{i}, and the equation v_{i} = expr_{i} is added to the equation set.
Consider the set E of equations and the set V of unknown variables (not constants and parameters) in a flattened model, i.e. M = <E, V>. The partitioning is described in terms of an undirected graph <N, F> with the nodes N being the set of equations and variables, N = E + V. The set incidence(e) for an equation e in E is a subset of V, in general, the unknowns which lexically appear in e. There is an edge in F of the graph between an equation, e, and a variable, v, if v = incidence(e):
$$F=\{(e,v):e\in E,v\in \text{incidence}(e)\}$$ 
A set of clock partitions is the “connected components” (Wikipedia, “Connected components”) of this graph with appropriate definition of the incidence operator.
The goal is to identify all clocked equations and variables that should be executed together in the same task, as well as to identify the continuoustime partition.
The baseclock partitioning is performed with baseclock inference which uses the following incidence definition:
incidence(e) = the unknown variables, as well as variables x in der(x), pre(x), and previous(x),  
which lexically appear in e  
except as first argument of baseclock conversion operators: sample() and hold(). 
The resulting set of connected components, is the partitioning of the equations and variables, B_{i} = <E_{i}, V_{i}>, according to baseclocks and continuoustime partitions.
The base clock partitions are identified as clocked or as continuoustime partitions according to the following properties:
A variable u in sample(u) and a variable y in y = hold(ud) is in a continuoustime partition.
Correspondingly, variables u and y in y = sample(uc), y = subSample(u), y = superSample(u), y = shiftSample(u), y = backSample(u), y = previous(u), are in a clocked partition. Equations in a clocked when clause are also in a clocked partition. Other partitions where none of the variables in the partition are associated with any of the operators above have an unspecified partition kind and are considered continuoustime partitions.
All continuoustime partitions are collected together and form “the” continuoustime partition.
[Example:
After base clock partitioning, the following partitions are identified:
]
For each clocked partition B_{i}, identified in section 16.7.3, the subclock partitioning is performed with subclock inference which uses the following incidence definition:
incidence(e) = the unknown variables, as well as variables x in der(x), pre(x), and previous(x),  
which lexically appear in e  
except as first argument of subclock conversion operators:  
subSample, superSample, shiftSample, backSample, and noClock. 
The resulting set of connected components, is the partitioning of the equations and variables, S_{ij} = <E_{ij}, V_{ij}>, according to subclocks.
It can be noted that:
${E}_{ij}\bigcap {E}_{kl}=\mathrm{\varnothing}\forall i\ne k,j\ne l$
${V}_{ij}\bigcap {V}_{kl}=\mathrm{\varnothing}\forall i\ne k,j\ne l$
$V=\bigcup {V}_{ij}$
$E=\bigcup {E}_{ij}$
[Example:
After subclock partitioning of the example from section 16.7.3, the following partitions are identified:
]
For each baseclock partition, the base interval needs to be determined and for each subclock partition, the subsampling factors and shift need to be determined. For each subclock partition, the interval might be rational or Real type and known or parametric or being unspecified. The subclock partition intervals are constrained by subSample and superSample factors which might be known (or parametric) or unspecified and by shiftSample shiftCounter and resolution or backSample, backCounter and resolution. This constraint set is used to solve for all intervals and subsampling factors and shift of the subclock partitions. The model is erroneous if no solution exist.
[It must be possible to determine that the constraint set is valid at compile time. However, in certain cases, it could be possible to defer providing actual numbers until runtime. ]
It is required that accumulated sub and super sampling factors in the range of 1 to 2^{63} can be handled.
[64 bit internal representation of numerator and denominator
with sign can be used and gives
minimum resolution 1.08E19 seconds and maximum range 9.22E+18 seconds =
2.92E+11 years.]
[The goal is that every continuoustime Modelica model can be utilized in a sampled data control system. This is achieved by solving the continuoustime equations with a defined integration method between clock ticks. With this feature, it is for example possible to invert the nonlinear dynamic model of a plant, see (Thümmel et.al. 2005), and use it in a feedforward path of an advanced control system that is associated with a clock.
This feature also allows to define multirate systems: Different parts of the continuoustime model are associated to different clocks and are solved with different integration methods between clock ticks, e.g., a very fast subsystem with an implicit solver with a small stepsize and a slow subsystem with an explicit solver with a large stepsize.]
With the language elements defined in this section, continuoustime equations can be used in clocked partitions. Hereby, the continuoustime equations are solved with the defined integration method between clock ticks.
From the view of the continuoustime partition, the clock ticks are not interpreted as events, but as stepsizes of the integrator that the integrator must exactly hit. [This is the same assumption as for manually discretized controllers, such as the ztransform.] So no event handling is triggered at clock ticks (provided an explicit event is not triggered from the model at this time instant). [It is not defined, how events are handled that appear when solving the continuoustime partition. For example, a tool could handle events exactly in the same way as for a usual simulation. Alternatively, relations might be interpreted literally, so that events are no longer triggered (in order that the time for an integration step is always the same, as needed for hard realtime requirements).]
From the view of the clocked partition, the continuoustime partition is discretized and the discretized continuoustime variables have only a value at a clock tick. Therefore, such a partition is handled in the same way as any other clocked partition. Especially, operators such as sample, hold, subSample must be used to communicate signals of the discretized continuoustime partition with other partitions. Hereby, a discretized continuoustime partition is seen as a clocked partition.
Additionally to the variability of expressions defined in section 3.8, an orthogonal concept “clocked variability” is defined in this section. If not explicitly stated otherwise, an expression with a variability such as “continuoustime” or “discretetime” means that the expression is inside a partition that is not associated to a clock. If an expression is present in a partition that is not a continuoustime partition, it is a “clocked expression” and has “clocked variability”.
After subclock inferencing, see section 16.7.5, every partition that is associated to a clock has to be categorized as “clocked discretetime” or “clocked discretized continuoustime” partition.
If a clocked partition contains no operator der, delay, spatialDistribution, no event related operators from section 3.7.3 (with exception of noEvent(..)), and no whenclause with a Boolean condition, it is a “clocked discretetime” partition [that is, it is a standard sampled data system that is described by difference equations.]
If a clocked partition is not a “clocked discretetime” partition, it is a “clocked discretized continuoustime” partition. Such a partition has to be solved with a “solver method” of section 16.8.2. When previous(x) is used on a continuoustime state variable x, then previous(x) uses the start value of x as value for the first clock tick.
In a clocked discretetime partition all event generating mechanisms do no longer apply. Especially neither relations, nor one of the builtin operators of section 3.7.1.1 (event triggering mathematical functions) will trigger an event.
The integration method associated with a clocked discretized continuoustime partition is defined with a string. A predefined type ModelicaServices.Types.SolverMethod defines the methods supported by the respective tool by using the choices annotation. [The ModelicaServices package contains tool specific definitions. A string is used instead of an enumeration, since different tools might have different values and then the integer mapping of an enumeration is misleading since the same value might characterize different integrators.] The following names of solver methods are standardized:
If a tool supports one of the integrators of SolverMethod, it must use the solver method name of above. [A tool may support also other integrators. Typically, a tool supports at least methods “External” and “ExplicitEuler”. If a tool does not support the integration method defined in a model, typically a warning message is printed and the method is changed to “External”.]
If the solver method is "External", then the partition associated with this method is integrated by the simulation environment for an interval of length of interval() using a solution method defined in the simulation environment [(for example by having a table of the clocks that are associated with discretized continuoustime partitions and a method selection per clock). In such a case, the solution method might be a variable step solver with stepsize control that integrates between two clock ticks. The simulation environment might also combine all partitions associated with method ”External”, as well as all continuoustime partitions, and integrate them together with the solver selected by the simulation environment.]
If the solver method is not "External", then the partition is integrated using the given method with the stepsize interval(). [For a periodic clock, the integration is thus performed with fixed step size.]
The solvers are defined with respect to the underlying ordinary differential equation in state space form to which the continuoustime partition can be transformed, at least conceptually (t is time, u_{c}(t) is the continuoustime Real vector of input variables, u_{d}(t) is the discretetime Real/Integer/Boolean/String vector of input variables, x(t) is the continuoustime real vector of states, and y(t) is the continuoustime or discretetime Real/Integer/Boolean/String vector of algebraic and/or output variables):
$\dot{x}$  $=$  $f(x,u,t)$  
$y$  $=$  $g(x,u,t)$ 
A solver method is applied on a subclock partition. Such a partition has explicit inputs u marked by sample(u), subSample(u), superSample(u), shiftSample(u) and/or backSample(u). Furthermore, the outputs y of such a partition are marked by hold(y), subSample(y), superSample(y), shiftSample(y), and/or backSample(y). The arguments of these operators are to be used as input signals u and output signals y in the conceptual ordinary differential equation above, and in the discretization formulae below, respectively.
The solver methods (with exception of ”External”) are defined by integrating from clock tick t_{i1} to clock tick t_{i} and computing the desired variables at t_{i}, with h = t_{i} – t_{i1} = interval(u) and x_{i} = x(t_{i}):
SolverMethod  Solution method (for all methods: ${y}_{i}=g({x}_{i},{u}_{c,i},{u}_{d,i},{t}_{i})$) 

ExplicitEuler  $\begin{array}{cc}\hfill {x}_{i}& :={x}_{i1}+h\cdot {\dot{x}}_{i1}\hfill \\ \hfill {\dot{x}}_{i}& :=f({x}_{i},{u}_{c,i},{u}_{d,i},{t}_{i})\hfill \end{array}$ 
ExplicitMidPoint2  $\begin{array}{cc}\hfill {x}_{i}& :={x}_{i1}+h\cdot f({x}_{i1}+{\displaystyle \frac{1}{2}}\cdot h\cdot {\dot{x}}_{i1},{\displaystyle \frac{{u}_{c,i1}+{u}_{c,i}}{2}},{u}_{d,i1},{t}_{i1}+\frac{1}{2}\cdot h)\hfill \\ \hfill {\dot{x}}_{i}& :=f({x}_{i},{u}_{c,i},{u}_{d,i},{t}_{i})\hfill \end{array}$ 
ExplicitRungeKutta4  $\begin{array}{cc}\hfill {k}_{1}& :=h\cdot {\dot{x}}_{i1}\hfill \\ \hfill {k}_{2}& :=h\cdot f({x}_{i1}+\frac{1}{2}{k}_{1},{\displaystyle \frac{{u}_{c,i1}+{u}_{c,i}}{2}},{u}_{d,i1},{t}_{i1}+\frac{1}{2}\cdot h)\hfill \\ \hfill {k}_{3}& :=h\cdot f({x}_{i1}+\frac{1}{2}{k}_{2},{\displaystyle \frac{{u}_{c,i1}+{u}_{c,i}}{2}},{u}_{d,i1},{t}_{i1}+\frac{1}{2}\cdot h)\hfill \\ \hfill {k}_{4}& :=h\cdot f({x}_{i1}+{k}_{3},{u}_{c,i},{u}_{d,i},{t}_{i})\hfill \\ \hfill {x}_{i}& :={x}_{i1}+\frac{1}{6}\cdot ({k}_{1}+2\cdot {k}_{2}+2\cdot {k}_{3}+{k}_{4})\hfill \\ \hfill {\dot{x}}_{i}& :=f({x}_{i},{u}_{c,i},{u}_{d,i},{t}_{i})\hfill \end{array}$ 
ImplicitEuler  $\begin{array}{cc}\hfill {x}_{i}& ={x}_{i1}+h\cdot {\dot{x}}_{i}\text{// equations system with unknowns:}{x}_{i},{\dot{x}}_{i}\hfill \\ \hfill {\dot{x}}_{i}& =f({x}_{i},{u}_{c,i},{u}_{d,i},{t}_{i})\hfill \end{array}$ 
ImplicitTrapezoid  $\begin{array}{cc}\hfill {x}_{i}& ={x}_{i1}+\frac{1}{2}h\cdot ({\dot{x}}_{i}+{\dot{x}}_{i1})\text{// equations system with unknowns:}{x}_{i},{\dot{x}}_{i}\hfill \\ \hfill {\dot{x}}_{i}& =f({x}_{i},{u}_{c,i},{u}_{d,i},{t}_{i})\hfill \end{array}$ 
The initial conditions will be used at the first tick of the clock, and the first integration step will go from the first to the second tick of the clock.
[Example: Assume the differential equation
shall be transformed to a clocked discretized continuoustime partition with the ExplicitEuler method. The following model is a manual implementation:
]
[For the implicit integration methods the efficiency can be enhanced by utilizing the discretization formula during the symbolic transformation of the equations. For example, linear differential equations are then mapped to linear and not nonlinear algebraic equation systems, and also the structure of the equations can be utilized. For details see (Elmqvist et. al. 1995). It might be necessary to associate additional data for an implicit integration method, e.g. the relative tolerance to solve the nonlinear algebraic equation systems, or the maximum number of iterations in case of hard realtime requirements. This data is tool specific and is typically either defined with a vendor annotation or is given in the simulation environment.]
A solverMethod can be associated to a clock with the overloaded Clock constructor Clock(c, solverMethod), see section 16.3. If a clock is associated with a clocked partition and a solverMethod is associated with this clock, then the partition is integrated with it.
[Example:
]
If a solverMethod is not explicitly associated with a partition, it is inferred with a similar mechanism as for subclock inferencing, see section 16.7.5. The inferencing mechanism is defined using the operator “solverExplicitlyDefined(c)” which returns true, if a solverMethod is explicitly associated with clock c and returns false otherwise.
For every partitioning operator of section 16.5, two clocks c1 and c2 are defined for the input and the output argument of the operator, respectively. Furthermore, for every equality and assignment of clocks, c1 = c2 or c1 := c2, two clocks are defined as well. In all these cases, the following statements are implicitly introduced:
The introduced set of, potentially underdetermined or overdetermined constraints has to be solved. If no solution exists or if a solution is contradictory on some clocks that are associated with clocked discretetime partitions, then this is ignored, since no solverMethod is needed for such partitions.
[Example:
]
The standard scheme for initialization of Modelica models does not apply for clocked discretetime partitions. Instead, initialization is performed in the following way:
Clocked discretetime variables cannot be used in initial equation or initial algorithm sections.
Attribute “fixed” cannot be applied on clocked discretetime variables. The attribute “fixed” is true for variables to which the previous operator is applied, otherwise false.
The following additional utility operators are provided:
firstTick(u)  This operator returns true at the first tick of the clock of the expression, in which this operator is called. The operator returns false at all subsequent ticks of the clock. The optional argument u is only used for clock inference, see section 16.7. 
interval(u)  This operator returns the interval between the previous and present tick of the clock of the expression, in which this operator is called. The optional argument u is only used for clock inference, see section 16.7. At the first tick of the clock the following is returned: a) if the specified clock interval is parametric, this value is returned; b) otherwise the start value of the variable specifying the interval is returned; c) for an event clock the additional startInterval argument to the event clock constructor is returned. The return value of the interval operator is a scalar Real number. 
It is an error if these operators are called in the continuoustime partition.
[Example:
A discrete PI controller is parameterized with the parameters of a continuous PI controller, in order that the discrete block is robust against changes in the sample period. This is achieved by discretizing a continuous PI controller (here with an implicit Euler method):
A continuoustime model is inverted, discretized and used as
feedforward controller for a PI controller
(der(..), previous, interval are used in the same partition):
]
The execution of sub partitions requires exact time management for proper synchronization. The implication is that testing a Real valued time variable to determine sampling instants is not possible. One possible method is to use counters to handle subsampling scheduling.
and to test the counter to determine when the subclock is ticking:
The Clock_i_j_activated flag is used as the guard for the sub partition equations.
[ Consider the following example:
A possible implementation model is shown below using Modelica 3.2 semantics. The baseclock is determined to 0.001 seconds and the subsampling factors to 1000 and 60000.
]