review6_changes #42

Merged
merged 1 commit into from Apr 11, 2014
Commits
Failed to load files and symbols.
+105 −87

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 . However this time, instead of using . 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
ProTip! Use n and p to navigate between commits in a pull request.