Use consistent language for "states"

docs/1___overview.adoc

@@ -321,8 +321,8 @@ Properties that might be additionally needed for trajectory optimization, for ex
 
 === How to Read This Document
 
-The core of this document is the description of the state machines and their states for each of the three interface types, each interface type in its own section.
-Each state description starts with a brief state's purpose, then the mathematical model in a table linking formulas with C-API functions, and finally descriptions of all allowed functions for this particular state.
+The core of this document is the description of the state machines and their modes for each of the three interface types, each interface type in its own section.
+Each state machine mode description starts with a brief mode's purpose, then the mathematical model in a table linking formulas with C-API functions, and finally descriptions of all allowed functions for this particular state machine mode.
 
 To keep the descriptions brief and redundancy low, <<fmi-common-concepts,common concepts>>, which are used by more than one interface type, are described once.
 
@@ -346,4 +346,4 @@ Conventions used in this document:
 [[VariableTypeExclClock,`{VariableTypeExclClock}`]]
 * `{VariableTypeExclClock}` is used just like <<VariableType>>, except does not include functions on variable type `fmi3Clock`.
 
-* State machine states are formatted as *bold* link, e.g. <<InitializationMode>>.
+* State machine modes are formatted as *bold* link, e.g. <<InitializationMode>>.

docs/2_2_common_mechanisms.adoc

@@ -12,7 +12,7 @@ The FMU itself does not implement any services to support this.]_
 * The following FMI callback functions must not call back into the FMU:
  ** <<logMessage,`fmi3LogMessageCallback`>>, and
  ** <<preemption-support,`fmi3LockPreemptionCallback`>>, and
- ** <<preemption-support,`fmi3UnlockPreemptionCallback`>>).
+ ** <<preemption-support,`fmi3UnlockPreemptionCallback`>>.
 
 +
 The following callback functions lead to well-defined states and may call FMI functions according to their respective state definitions:
@@ -222,9 +222,9 @@ The call failed.
 The output argument values are undefined and the simulation must not be continued.
 Function <<logMessage>> should be called by the FMU with further information before returning this status, respecting the current logging settings.
 If a function returns <<fmi3Error>>, it is possible to restore a previously retrieved FMU state by calling <<fmi3SetFMUState>> or to reset the instance by calling <<fmi3Reset>>.
-When detecting illegal arguments or a function call not allowed in the current state according to the respective state machine, the FMU must return <<fmi3Error>>.
+When detecting illegal arguments or a function call not allowed in the current state machine mode according to the respective state machine, the FMU must return <<fmi3Error>>.
 Other instances of this FMU are not affected by the error. +
-_[For example, when setting a constant with a call to <<get-and-set-variable-values,`fmi3Set{VariableType}`>>, then the function must return with an error (<<fmi3Error,`fmi3Status = fmi3Error`>>.]_
+_[For example, when setting a constant with a call to <<get-and-set-variable-values,`fmi3Set{VariableType}`>>, then the function must return with an error <<fmi3Error,`fmi3Status = fmi3Error`>>.]_
 
 [[fmi3Fatal,`fmi3Fatal`]]
 `fmi3Fatal`::
@@ -337,7 +337,7 @@ If an API function takes multiple value references, the serialized variables are
 
 ===== Getting and Setting Variable Values [[get-and-set-variable-values]]
 
-Restrictions for setting and getting of variables with certain types, causalities and variabilities are defined in the state machine and state descriptions (see <<common-state-machine>> for common states, <<state-machine-model-exchange>> for Model Exchange, <<state-machine-co-simulation>> for Co-Simulation, and <<state-machine-scheduled-execution>> for Scheduled Execution).
+Restrictions for setting and getting of variables with certain types, causalities and variabilities are defined in the state machine and state machine mode descriptions (see <<common-state-machine>> for common state machine modes, <<state-machine-model-exchange>> for Model Exchange, <<state-machine-co-simulation>> for Co-Simulation, and <<state-machine-scheduled-execution>> for Scheduled Execution).
 In addition to those state-specific restrictions, setting and getting of <<clocked-variable,clocked variables>> is only allowed during <<EventMode>> when their respective Clocks are active, and during <<InitializationMode>> irrespective of Clock activation status.
 
 The variable <<ModelVariables,type>> defined in the <<modelDescription.xml>> determines the function <<get-and-set-variable-values,`fmi3Get/Set{VariableType}`>> (see also <<VariableType,`{VariableType}`>> and <<VariableTypeExclClock,`{VariableTypeExclClock}`>>) that must be used for accessing the respective variable values.
@@ -1125,15 +1125,15 @@ where
 ** <<StepMode>> (Co-Simulation): The variables listed as elements <<Output>> of <<ModelStructure>> with a floating point type and <<variability>> = <<continuous>> or <<discrete>>.
 Each continuous state derivative variable listed as elements <<ContinuousStateDerivative>> in <<ModelStructure>>, if present.
 
-* latexmath:[\mathbf{v}_{\mathit{known}}] is the vector of arguments of function latexmath:[\mathbf{f}] which can be changed by the importer in the current state.
+* latexmath:[\mathbf{v}_{\mathit{known}}] is the vector of arguments of function latexmath:[\mathbf{f}] which can be changed by the importer in the current state machine mode.
 Details about which variables are in latexmath:[\mathbf{v}_{\mathit{known}}] are given in the description of element <<dependencies>> in <<ModelStructure>>.
 
-* latexmath:[{\mathbf{v}_{\mathit{rest}}}] is the set of <<input>> variables and discrete-time states of function latexmath:[\mathbf{f}] which cannot be set by the importer in the current state, but in other states _[for example, discrete-time <<input,`inputs`>> in <<ContinuousTimeMode>>]_.
+* latexmath:[{\mathbf{v}_{\mathit{rest}}}] is the set of <<input>> variables and discrete-time states of function latexmath:[\mathbf{f}] which cannot be set by the importer in the current state machine mode, but in other state machine modes _[for example, discrete-time <<input,`inputs`>> in <<ContinuousTimeMode>>]_.
 
 * <<EventIndicator,`EventIndicators`>> must not be included among latexmath:[\mathbf{v}_{\mathit{unknown}}]. +
 _[This is intentional as their dependencies listed in <<ModelStructure>> are intended for debugging purposes and not for partial derivatives.]_
 
-_[The variable relationships are different in different states._
+_[The variable relationships are different in different state machine modes._
 _For example, during <<ContinuousTimeMode>>, the partial derivate of a continuous-time output_ latexmath:[\mathbf{y}] _with respect to discrete-time <<input,`inputs`>> is undefined, because discrete-time <<input,`inputs`>> cannot be set between events.]_
 
 There are two access functions for partial derivatives:
@@ -1178,7 +1178,7 @@ Both functions have the same arguments:
 * `nUnknowns` contains the length of argument `unknowns`.
 * `knowns` contains value references of the knowns.
 * `nKnowns` contains the length of argument `knowns`.
-* `seed` contains the <<serialization-of-variables,serialized>> components of the seed vector.  
+* `seed` contains the <<serialization-of-variables,serialized>> components of the seed vector.
 * `nSeed` contains the length of `seed`.
 * `sensitivity` contains the <<serialization-of-variables,serialized>> components of the sensitivity vector.
 * `nSensitivity` contains the length of `sensitivity`.

docs/2_3_common_states.adoc

@@ -1,27 +1,27 @@
 === State Machine and Semantics [[common-state-machine]]
 
 To define allowed calling sequences of FMI functions, state machines are used.
-Each state of the state machine corresponds to a certain phase of a simulation.
-All interface types share a number of states in their respective state machines.
-This chapter describes these common states used in at least two of the interface types.
-State-machine states specific to a single interface type will be described in their respective chapters.
+Each state machine mode corresponds to a certain phase of a simulation.
+All interface types share a number of state machine modes in their respective state machines.
+This chapter describes these common state machine modes used in at least two of the interface types.
+State machine modes specific to a single interface type will be described in their respective chapters.
 
 [[each-state-description]]
-Each state description lists the governing equations and actions and the corresponding API functions influencing these equations in a table (not defining the calling order), and also lists the allowed function calls and usage restrictions.
+Each state machine mode description lists the governing equations and actions and the corresponding API functions influencing these equations in a table (not defining the calling order), and also lists the allowed function calls and usage restrictions.
 
 .Common calling sequence for C functions of common states for at least two of the interface types.
 [#figure-common-state-machine]
 image::images/state-machines-common-states.svg[width=80%, align="center"]
 
 The state machine is given here as UML 2.0 state machine.
 If a transition is labeled with one or more function names (for example, <<fmi3EnterInitializationMode>>, <<fmi3EnterEventMode>>), the transition is taken if the function call returns successfully (not `NULL` for <<fmi3Instantiate>> or <<fmi3OK>> and <<fmi3Warning>> for all other functions).
-This way, importer and FMU can determine in which state the FMU is.
+This way, importer and FMU can determine in which state machine mode the FMU is.
 
 ==== Super State: FMU State Settable [[FMUStateSettable,*FMU State Settable*]]
 
-The state <<FMUStateSettable>> is entered when any of the following functions is called: <<fmi3InstantiateModelExchange>>, <<fmi3InstantiateCoSimulation>> and <<fmi3InstantiateScheduledExecution>>.
-The state is left by either calling <<fmi3FreeInstance>> or when any of the functions called during <<FMUStateSettable>> returns <<fmi3Fatal>>.
-If any function called in super state <<FMUStateSettable>> returns <<fmi3Error>>, the FMU enters state <<Terminated>>.
+The state machine mode <<FMUStateSettable>> is entered when any of the following functions is called: <<fmi3InstantiateModelExchange>>, <<fmi3InstantiateCoSimulation>> and <<fmi3InstantiateScheduledExecution>>.
+The state machine mode is left by either calling <<fmi3FreeInstance>> or when any of the functions called during <<FMUStateSettable>> returns <<fmi3Fatal>>.
+If any function called in super state <<FMUStateSettable>> returns <<fmi3Error>>, the FMU enters state machine mode <<Terminated>>.
 
 Allowed Function Calls to enter this Super State::
 
@@ -179,7 +179,7 @@ include::../headers/fmi3FunctionTypes.h[tags=Reset]
 ----
 +
 Is called by the environment to reset the FMU after a simulation run.
-The FMU goes into the same state as if <<fmi3Instantiate>> would have been called.
+The FMU goes into the same state machine mode as if <<fmi3Instantiate>> would have been called.
 All variables have their default values.
 Before starting a new run <<fmi3EnterInitializationMode>> has to be called.
 
@@ -204,7 +204,7 @@ All these allowed functions are described in <<get-set-fmu-state>>.
 
 ==== State: Instantiated [[Instantiated,*Instantiated*]]
 
-In the state <<Instantiated>> the FMU can do one-time initializations and allocate memory.
+In the state machine mode <<Instantiated>> the FMU can do one-time initializations and allocate memory.
 
 [#table-math-instantiated]
 [cols="2,1",options="header"]
@@ -288,7 +288,7 @@ Function `fmi3EnterInitializationMode`::
 include::../headers/fmi3FunctionTypes.h[tags=EnterInitializationMode]
 ----
 +
-Changes state to <<InitializationMode>>.
+Changes state machine mode to <<InitializationMode>>.
 
 * [[toleranceDefined,`toleranceDefined`]]`toleranceDefined` and
 * [[tolerance,`tolerance`]]`tolerance` depend on the interface type:
@@ -429,7 +429,7 @@ include::../headers/fmi3FunctionTypes.h[tags=ExitInitializationMode]
 ----
 
 +
-Changes the state to
+Changes the state machine mode to
 
  * Model Exchange: <<EventMode>>
  * Co-Simulation:

docs/2_4_common_schema.adoc

@@ -813,10 +813,10 @@ A tool may ignore this information. +
 _[However, it is convenient for a user that <<startTime>>, <<stopTime>>, <<tolerance>> and <<stepSize>> have already a meaningful default value for the model at hand.]_ +
 <<startTime>>, <<stopTime>> and <<stepSize>> refer to the unit of the <<independent>> variable.
 <<stepSize>> defines the preferred <<communicationStepSize>> for Co-Simulation.
-For Model Exchange and Scheduled Execution <<stepSize>> has no defined meaning. 
+For Model Exchange and Scheduled Execution <<stepSize>> has no defined meaning.
 _[This does not prohibit the use of <<stepSize>> in the context of Model Exchange._
 _For example, a fixed step size solver can use it as a default step size._
-_A variable step size solver can use the <<stepSize>> as an initial step size or as result grid for the output._ 
+_A variable step size solver can use the <<stepSize>> as an initial step size or as result grid for the output._
 _Since the required <<stepSize>> depends on the solver itself a defined meaning of <<stepSize>> for Model Exchange is impossible.]_
 
 [[ModelVariables,`<ModelVariables>`]]
@@ -1950,7 +1950,7 @@ An importer should connect terminals only if the number of member variables matc
 
 [[none,`none`]]
 |`none`
-|Matching of the variables is not intended by the creator of the FMU. 
+|Matching of the variables is not intended by the creator of the FMU.
 However, an importer may still connect terminals based on additional information.
 
 |====
@@ -1968,7 +1968,7 @@ This allows the same variable to participate in different connection contexts or
 
 [[terminalKind,`terminalKind`]]
 The normalized string `terminalKind` is an optional attribute.
-Other standards may define terminal kinds. 
+Other standards may define terminal kinds.
 It is strongly recommended to use <<reverse-DNS, reverse domain name notation>> to define a `terminalKind`.
 It is intended that the `terminalKind` is used to define domain specific member variable sequences, member names and order, or high level restrictions for connections.
 

docs/2_5_fmu_distribution.adoc

@@ -51,7 +51,7 @@ sources                             // directory containing the C sources (optio
 binaries                            // directory containing the binaries (optional)
    x86_64-windows                   // binaries for Windows on Intel 64-bit
       <modelIdentifier>.dll         // shared library of the FMI implementation
-      <other files>                 // other platform dependend files 
+      <other files>                 // other platform dependend files
                                     // needed at linking or loading time
    x86-linux                        // binaries for Linux on Intel 32-bit
       <modelIdentifier>.so          // shared library of the FMI implementation
@@ -209,7 +209,7 @@ For the FMU to access these resource files - during runtime, after instantiation
 The resources directory must be available for the lifetime of the FMU instance.
 The FMU instance must not write to or delete the directory or parts of it.
 
-_[The files contained in the resources folder may be platform dependent files. 
+_[The files contained in the resources folder may be platform dependent files.
 In contrast to files in the binaries folder, they can be accessed during runtime by the FMU.
 For more information, please consult the https://modelica.github.io/fmi-guides/main/fmi-guide/[FMI Implementer's Guide].]_
 

docs/3_2_model_exchange_api.adoc

@@ -6,14 +6,14 @@ The state machine in <<figure-model-exchange-state-machine>> defines the allowed
 [#figure-model-exchange-state-machine]
 image::images/state-machine-model-exchange.svg[width=80%, align="center"]
 
-Common states are defined in <<common-state-machine>>, such as super states <<FMUStateSettable>> and  <<Initialized>>, states <<Instantiated>>, <<ConfigurationMode>>, <<ReconfigurationMode>>, <<InitializationMode>>, <<EventMode>> and <<Terminated>>.
+Common state machine modes are defined in <<common-state-machine>>, such as super modes <<FMUStateSettable>> and  <<Initialized>>, modes <<Instantiated>>, <<ConfigurationMode>>, <<ReconfigurationMode>>, <<InitializationMode>>, <<EventMode>> and <<Terminated>>.
 
 ==== State: Continuous-Time Mode [[ContinuousTimeMode,*Continuous-Time Mode*]]
 
 The <<ContinuousTimeMode>> is used to compute the values of all continuous-time variables between events by numerically solving ordinary differential and <<algebraic-loops,algebraic equations>>.
 All discrete-time variables are fixed during this phase and the corresponding discrete-time equations are not evaluated.
 
-In this state, the continuous-time equations are active and integrator steps are performed by the importer.
+In this mode, the continuous-time equations are active and integrator steps are performed by the importer.
 
 [#table-math-model-exchange]
 [cols="8,3",options="header"]
@@ -185,7 +185,7 @@ Function `fmi3EnterEventMode`::
 include::../headers/fmi3FunctionTypes.h[tags=EnterEventMode]
 ----
 +
-This function changes the state to <<EventMode>>.
+This function changes the state machine mode to <<EventMode>>.
 +
 The importer must call <<fmi3EnterEventMode>> when any of the following conditions are met: