New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

review6_changes #42

Merged
merged 1 commit into from Apr 11, 2014
Jump to file or symbol
Failed to load files and symbols.
+105 −87
Diff settings

Always

Just for now

@@ -7,14 +7,14 @@ Conceptual Definitions
In both of the examples we presented in this chapter, we used
interface definitions as part of the architecture definition process.
The term "interface" doesn't come from Modelica itself, it is a term
common among object-oriented languages. In Modelica, we can think of
common among computer languages. In Modelica, we can think of
interfaces as models that define all the details of the model **that
are externally visible**. You can think of an interface as a "shell"
without any internal details. For this reason, interface models are
almost always marked as ``partial``.
Another important concept is that of an "implementation". This is
another term borrowed from the world of object-oriented languages.
another term borrowed from the world of computer languages.
Whereas an interface is used to simply describe the externally visible
aspects of a model, an implementation includes internal details as
well. It includes the information required to actually implement that
@@ -58,6 +58,6 @@ Conclusion
The bottom line is that it is very useful to not only think in terms
of interface and implementation models, but also to create models to
formally define interfaces and distinguish them from implementations
formally define interfaces and distinguish them from implementations,
since these will be very useful when creating architecture driven
models.
@@ -18,7 +18,7 @@ The advantage of using the ``replaceable`` keyword is that it allows
new models to be created without having to reconnect anything. This
not only imposes a structural framework on future models (to ensure
naming conventions are followed, interfaces are common, *etc.*), it
also helps avoid potential errors by eliminating one potentially error
also helps avoid potential errors by eliminating an error
prone task from the model development process, *i.e.,* creating
connections.
@@ -56,6 +56,8 @@ keyword is:
replaceable DefaultType variableName constrainedby ConstrainingType;
.. todo:: this sentence needs re-writing.
where ``variableName`` is again the name of the variable being
declared, ``DefaultType`` represents the type of ``variableName`` of
the type of ``variableName`` is never changed and ``ConstrainingType``
@@ -99,7 +101,7 @@ In this ``System`` model, only the sensor is ``replaceable``. So the
types of each of the other subsystems (*i.e.,* ``plant``,
``controller`` and ``actuator``) cannot be changed.
If we wanted to extend this model but use a different model for the
If we wanted to extend this model, but use a different model for the
``sensor`` subsystem, we would use the ``redeclare`` keyword as
follows:
@@ -116,7 +118,7 @@ What this tells the Modelica compiler is that in the context of the
instance of the ``CheapSensor`` model, not the (otherwise default)
``Sensor`` model. **However**, the ``CheapSensor`` model (or any
other type chosen during redeclaration) **must be plug-compatible with
that variables constraining type**.
that variable's constraining type**.
The syntax of a ``redeclare`` statement is really exactly the same as
a normal declaration except that it is preceded by the ``redeclare``
@@ -157,7 +159,7 @@ things that are plug-compatible), but we can never widen the type
(which would make things that were previously not plug-compatible
now plug-compatible).
Earlier when discussing :ref:`arrays-of-components`, we made the point
Earlier, when discussing :ref:`arrays-of-components`, we made the point
that it was not possible to redeclare individual elements in arrays.
Instead, a redeclaration must be applied to the entire array. In
other words, if we declare something initially as:
@@ -264,6 +266,8 @@ declaration and not in subsequent redeclarations, apply it after the
variable name. If you want it to persist through subsequent
redeclarations, apply it to the constraining type.
.. todo:: has definition vs. declaration been discussed somwehere?
Redefinitions
^^^^^^^^^^^^^
@@ -325,7 +329,7 @@ modifications that set the resistance were applied to the constraining
type in our ``Circuit`` model. But, it is a bit tedious that we have
to change each individual resistor and specify ``dRdT`` over and over
again even though they are all the same value. However, Modelica
gives us a way to do them all at once. The way we do this. The first
gives us a way to do them all at once. The first
step is to define a local type within the model like this:
.. code-block:: modelica
@@ -420,7 +424,7 @@ address this issue.
``choices``
~~~~~~~~~~~
The ``choices`` annotation allows to original model developer to
The ``choices`` annotation allows the original model developer to
associate a list of modifications with a given declaration. The very
simplest use case for this could be to specify values for a given
parameter:
@@ -3,7 +3,7 @@
Sensor Comparison
-----------------
Let us start our study of architectures with an examples that is
Let us start our study of architectures with an example that is
similar to one presented in my previous book [ItPMwM]_. In it, we
will consider the performance of a control system using several
different sensor models.
@@ -20,6 +20,8 @@ Our system schematic is structured as follows:
:align: center
:alt: Flat system model
.. todo:: the purple box is showing as magenta
All the components within the purple box represent the plant model.
In this case, it is a simple rotational system involving two rotating
inertias connected via a spring and a damper. One of the inertias is
@@ -28,7 +30,7 @@ box identifies the sensor in the system. The sensor is used to
measure the speed of one of the rotating shafts. Similarly, the
purple box identifies the actuator. The actuator applies a torque to
the other shaft (the one whose speed is not measured). Finally, all
the components in the blue box represent the control system which
the components in the blue box represent the control system, which
tries to keep the measured speed as close as possible to the setpoint
supplied by the signal generator at the top of the diagram.
@@ -77,8 +79,8 @@ following performance for the control system:
.. plot:: ../plots/AFS_SH.py
:include-source: no
In this case, we can see that things are going from bad to worse in
this case. While we were initially unable to track the desired speed
In this case, we can see that things are going from bad to worse.
While we were initially unable to track the desired speed
closely, now (as a result of the measurement artifact) our system has
become unstable.
@@ -92,7 +94,7 @@ improvements might ultimately be required for the control system
itself.
If we plan on substituting sensors, actuators and control strategies
our first step should be to organize our system in those subsystems.
our first step should be to organize our system into those subsystems.
Doing so, we end up with the following system model:
.. image:: /ModelicaByExample/Architectures/SensorComparison/Examples/HierarchicalSystem.svg
@@ -145,6 +147,8 @@ model:
.. literalinclude:: /ModelicaByExample/Architectures/SensorComparison/Examples/HierarchicalSystem.mo
:language: modelica
.. todo:: sentence is missing some text at the end
Now, we want to create a variation of this model where the ``sensor``
component
@@ -172,7 +176,7 @@ something like this:
end Variation2;
This is essentially what we want to do. But this isn't legal in
Modelica. There are a couple of problems with this approach. The
Modelica and there are a couple of other problems with this approach. The
first is that the original model developer might not want to allow
such changes. The second problem is that we end up with two
``sensor`` components (of different types, no less). Even if it truly
@@ -181,7 +185,7 @@ another problem is that we might type the name wrong for the variable
name and end up with two sensors. Finally, we still don't have a way
to know if it even makes sense to change ``sensor`` into a
``SampleHoldSensor``. In this case it does, but how do we ensure that
in general.
in general?
Fortunately, there **is** a way to do almost exactly what we are
attempting here. But in order to address these other complications,
@@ -225,7 +229,7 @@ there and will still be compatible. **However, please note** that if
Plug compatibility is important because, in general, we want to ensure
that any redeclaration that we make is "safe". The way we do that is
to require that whatever type we decide to change our ``sensor``
component to, is plug compatible with the original type. In this
component to is plug compatible with the original type. In this
case, that means that it has to have a ``w`` connector (and that
connector, in turn, must be plug compatible with the ``w`` that was
there before) and it has to have a ``shaft`` connector (which, again,
@@ -295,7 +299,7 @@ model without repeating ourselves as follows:
There are several things worth noting about this model. The first is
that the syntax of a redeclaration is just like a normal declaration
except it are preceded by the ``redeclare`` keyword. Also note that
except it is preceded by the ``redeclare`` keyword. Also note that
the redeclaration is part of the ``extends`` clause. Specifically, it
is a modification, like any other modification, in the extends
clause. If we wanted to both redeclare the ``sensor`` component and
@@ -402,8 +406,8 @@ the constraining type by adding a ``constrainedby`` clause at the end,
.. index:: default type
This declaration says that the ``sensor`` component can be redeclared
by anything that is plug-compatible with the ``IdealSensor`` model
**but** if it isn't redeclared then **by default** it should be
by anything that is plug-compatible with the ``IdealSensor`` model,
**but** if it isn't redeclared, then **by default** it should be
declared as a ``SampleHoldSensor`` sensor. For this reason, the original
type used in the declaration, ``SampleHoldSensor``, is called the
**default type**.
@@ -4,7 +4,7 @@ Architecture Driven Approach
----------------------------
So far in this section, we started with a flat approach and gradually
adapted it to use the architectural features of Modelica. Let's start
adapted it to use the architectural features of Modelica. Let's start to
build out our system from the top down using an architectural
approach where we define the structure of our system first and then
add specific subsystem implementations after that.
@@ -30,8 +30,8 @@ or sub-components), it will end up being a ``partial`` model. But
that's fine for our purposes.
Let's start by considering the interface for our ``sensor``
subsystem. We have already discussed the public interface in detail
already. Here is a Modelica definition and icon for that interface:
subsystem. We have already discussed the public interface in detail.
Here is a Modelica definition and icon for that interface:
.. literalinclude:: /ModelicaByExample/Architectures/SensorComparison/Interfaces/Sensor.mo
:language: modelica
@@ -43,7 +43,7 @@ already. Here is a Modelica definition and icon for that interface:
A few things to note about this ``model`` definition. The first is,
as we mentioned a moment ago, that this model is ``partial``. It
should be clear why since it has connectors but not equations to help
should be clear why, since it has connectors, but not equations to help
solve for the variables on those connectors. Another thing worth
noting is the fact that it contains annotations. The annotations
associated with the connector declarations specify how those
@@ -56,7 +56,7 @@ model that extends from this model will be able to draw **additional**
graphics on top of what is defined by the ``Sensor`` model.
The interface definition for the actuator model is almost identical
except that it includes two rotational connector, one to apply the
except that it includes two rotational connectors, one to apply the
commanded torque to and the other that handles the reaction torque.
If, for example, our actuator model were an electric motor, the former
would be the connector for the rotor and the latter would be the
@@ -218,7 +218,7 @@ By doing so, we ensure that subsequent redeclarations are possible.
If we had wanted our ``SystemArchitecture`` model to specify these
implementations as the default but still used the interfaces as the
implementations as the default but still use the interfaces as the
constraining types, we could have declared the subsystems in
``SystemArchitecture`` as follows:
@@ -363,7 +363,7 @@ signals on the ``bus`` connector are referenced:
:lines: 1-20,68
:emphasize-lines: 18
Again, not the emphasized line. It references something called
Again, note the emphasized line. It references something called
``heat_command`` on the ``bus`` connector. Again, that signal doesn't
exist in the definition of ``ExpandableBus``, but it is implicitly
created simply because it is referenced in the highlighted ``connect``
@@ -456,7 +456,7 @@ Conclusion
^^^^^^^^^^
This is the second example of how we can use the configuration
management features in Modelica to taken an architecturally based
management features in Modelica to take an architecturally based
approach to building system models. This architectural approach is
very useful when there a many variations of a the same architecture
that require analysis. Using the ``redeclare`` feature, it is
@@ -22,7 +22,7 @@ this section, called a ``block``, that is restricted to having only
In this section, we'll first look at how to construct causal blocks
representing some basic mathematical operations. We'll then see how
those blocks can be used in two different ways. The first way will be
to model a sample physical system. We'll include some discussion
to model a simple physical system. We'll include some discussion
contrasting the causal and acausal approaches. The second way to use
such blocks is to model control systems. As we'll see, using blocks
to construct control systems is a much more natural fit for the block
@@ -75,7 +75,7 @@ use is the ``SO``, or "single output", definition:
transformation(extent={{100,-10},{120,10}}, rotation=0)));
end SO;
Obviously, this definition is used to blocks that have a single
Obviously, this definition is used for blocks that have a single
output. By convention, this output signal is named ``y``. Another
definition we'll use is the ``SISO`` or "single input, single output"
block:
@@ -249,13 +249,16 @@ Cooling Example
The first system that we will model using our ``block`` definitions is
the heat transfer example we presented :ref:`earlier in this chapter
<heat-transfer-components>`. However this time, instead of using
<heat-transfer-components>`. However, this time, instead of using
acausal components to build our model, we'll build it up in terms of
the mathematical operations associated with our ``block`` definitions.
Since these blocks represent mathematical operations, let us first
revisit the equation associated with this example:
.. todo:: this and some following expressions involving T are not being rendered correctly using
https://book-preview.herokuapp.com
.. math:: m c_p \dot{T} = h (T_{\infty}-T)
The following block diagram will solve for the temperature profile,
@@ -305,17 +308,16 @@ Such an equation can be typed in very quickly. In contrast, the
component based versions would require the user to drag, drop and
connect component models which would invariably take longer.
However, if you intend to create multiple variations of the problem
However, if you intend to create variations of the problem
combining different modes of heat transfer, different boundary
conditions, etc. then the acausal version is better. This because
conditions, etc., then the acausal version is better. This is because
while some investment is required to create the component models, they
can be reconfigured almost trivially once the component models are
available.
can be reconfigured almost trivially.
One might say the same is true for the block diagram version of the
model (*i.e.,* that it can be trivially reconfigured), **but that is
not the case**. The block diagram version of the model is a
**mathematical** representation of the problem not a schematic based
**mathematical** representation of the problem, not a schematic based
formulation. If you create variations of this heat transfer problem
that specify alternative boundary conditions, add more thermal
inertias or include additional modes of heat transfer, the changes to
@@ -337,8 +339,8 @@ Thermal Control
For the next example, we'll mix both causal components, the blocks
we've developed in this section, with acausal components, the
:ref:`heat-transfer-components` developed earlier in this chapter.
This will prove to be a powerful combination since it allows us to
represent the physical components schematically but allows us to
This will prove to be a powerful combination, since it allows us to
represent the physical components schematically, but allows us to
express the control strategy mathematically.
Here is a schematic diagram showing how both approaches can be combined:
@@ -349,7 +351,7 @@ Here is a schematic diagram showing how both approaches can be combined:
:alt: Gain Block
:figclass: align-center
When modeling a physical system together with a control system the
When modeling a physical system together with a control system, the
physical components and effects will use an acausal formulation. The
components representing the control strategy will typically use a
causal formulation. What bridges the gap between these two approaches
@@ -370,6 +372,8 @@ Our example model can be expressed in Modelica as:
.. literalinclude:: /ModelicaByExample/Components/BlockDiagrams/Examples/MultiDomainControl.mo
:language: modelica
.. todo:: rendering problems follow
Looking at the model, we can see that the initial temperature is
:math:`90\,^{\circ}\mathrm{C}` and the ambient temperature is
:math:`25\,^{\circ}\mathrm{C}`. In addition, the setpoint temperature
Oops, something went wrong.
ProTip! Use n and p to navigate between commits in a pull request.