# 
msgid ""
msgstr ""
"Project-Id-Version: Modelica by Example 0.2.1\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2014-04-15 14:12-0400\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#: ../../source/components/components/system_models.rst:4
msgid "System Models"
msgstr ""

#: ../../source/components/components/system_models.rst:6
msgid ""
"The next chapter will provide an in-depth discussion about "
":ref:`subsystems`.  For now, we'll only discuss the handful of topics "
"related to subsystems that we've seen so far."
msgstr ""

#: ../../source/components/components/system_models.rst:13
msgid "Connections"
msgstr ""

#: ../../source/components/components/system_models.rst:15
msgid ""
"One distinction that we've seen in this chapter between component and "
"subsystem models is that subsystem models include ``connect`` statements.  "
"To explore how the ``connect`` statement works, let's revisit the "
"``MultiDomainControl`` example from the discussion on :ref:`thermal-"
"control`.  If we strip away all the annotations (which we will discuss "
"shortly), we get a model that looks like this:"
msgstr ""

#: ../../source/components/components/system_models.rst:56
msgid ""
"During our earlier discussion on :ref:`acausal-modeling`, we talked about "
"equations that are generated for **acausal** variables in a connector.  But "
"the impact of a ``connect`` statement depends on the nature of the variables"
" being connected.  The ``MultiDomainControl`` model is useful because it "
"isn't restricted to acausal connections."
msgstr ""

#: ../../source/components/components/system_models.rst:64
msgid ""
"Before we consider the specific connections in the ``MultiDomainControl`` "
"model, let's first elaborate on what the ``connect`` statement actually "
"does.  There are some complex cases that arise, but for the sake of "
"simplicity and pedagogy, we'll only discuss the basic case here."
msgstr ""

#: ../../source/components/components/system_models.rst:70
msgid ""
"A ``connect`` statement connects exactly two connectors.  It then \"pairs "
"up\" variables across each connector **by name**.  In other words, it takes "
"each variable in one connector and pairs it up with the variable of the same"
" name in the other connector."
msgstr ""

#: ../../source/components/components/system_models.rst:79
msgid ""
"For each pair, the compiler first checks to make sure that the two "
"corresponding variables have the same type (*e.g.,* ``Real``, ``Integer``)."
"  But what equations are generated and what additional restrictions exists "
"depend on what qualifiers have been applied to the variables.  The following"
" list covers all the essential cases:"
msgstr ""

#: ../../source/components/components/system_models.rst:85
msgid ""
"**Through variables** - These are variables with the ``flow`` qualifier.  As"
" we covered in our previous discussion on :ref:`acausal-modeling`, a "
"conservation equation is generated for all variables in the connection set."
msgstr ""

#: ../../source/components/components/system_models.rst:89
msgid ""
"**Parameters** - A variable that includes the ``parameter`` qualifier does "
"not generate any equations.  Instead, it generates an ``assert`` call that "
"ensures that the values are identical between the two variables.  This is "
"useful when a ``connector`` includes ``Integer`` parameters that specify the"
" size of arrays in the connector, for example, because it asserts the arrays"
" are the same size."
msgstr ""

#: ../../source/components/components/system_models.rst:96
msgid ""
"**Inputs** - A variable that has the ``input`` qualifier can only be paired "
"with a variable that has an ``input`` or an ``output`` qualifier.  Assuming "
"this requirement is met, an equation will be generated simply equating these"
" two variables."
msgstr ""

#: ../../source/components/components/system_models.rst:100
msgid ""
"**Outputs** - A variable that has the ``output`` qualifier can only be "
"paired with a variable that has the ``input`` qualifier (*i.e.,* two outputs"
" can never be connected).  As with the case for input variables, an equality"
" relationship is generated for such a connection."
msgstr ""

#: ../../source/components/components/system_models.rst:105
msgid ""
"**Across variables** - These are variables that lack any qualifiers (unlike "
"the previous cases).  As we covered in our previous discussion on :ref"
":`acausal-modeling`, a series of equations will be generated equating all "
"the across variables in the connection set."
msgstr ""

#: ../../source/components/components/system_models.rst:111
msgid ""
"In our discussion of :ref:`block-components`, we describe the ``input`` and "
"``output`` qualifiers as \"causal\".  In fact, the ``input`` and ``output`` "
"qualifiers do not actually specify the order in which calculations are "
"performed.  As discussed above, they just enforce restrictions on how the "
"variables can be connected.  In addition to the restriction already "
"mentioned, there is one additional restriction that, within a connection "
"set, there can only be one ``output`` signal (for obvious reasons)."
msgstr ""

#: ../../source/components/components/system_models.rst:120
msgid ""
"In our ``MultiDomainControl`` model, we can see several of these cases "
"covered.  For example,"
msgstr ""

#: ../../source/components/components/system_models.rst:127
msgid ""
"Here, an ``output`` signal, ``setpoint.y``, is connected to an ``input`` "
"signal, ``feedback.u1``.  So this is a connection involving only causal "
"signals.  On the other hand, we have connections like this:"
msgstr ""

#: ../../source/components/components/system_models.rst:136
msgid ""
"This will lead to the types of conservations equations :ref:`discussed "
"earlier <acausal-modeling>`."
msgstr ""

#: ../../source/components/components/system_models.rst:139
msgid ""
"In summary, a ``connect`` statement is a way to generate equations that "
"automatically manages complex tasks (like generation of conservation and "
"continuity equations) while at the same time checking to make sure that the "
"connection makes sense (*e.g..,* that the variables have the same type)."
msgstr ""

#: ../../source/components/components/system_models.rst:148
msgid "Diagrams"
msgstr ""

#: ../../source/components/components/system_models.rst:150
msgid ""
"In this chapter, we showed how Modelica subsystem models can be represented "
"graphically, *e.g.,*"
msgstr ""

#: ../../source/components/components/system_models.rst:158
msgid ""
"All the information required to generate such a diagram is contained in the "
"Modelica model.  While this information has been visible in some of the "
"Modelica code listings in this chapter, we haven't really discussed what "
"information is stored and where."
msgstr ""

#: ../../source/components/components/system_models.rst:163
msgid "To render a subsystem diagram, three pieces of information are needed:"
msgstr ""

#: ../../source/components/components/system_models.rst:165
msgid "The icon to use to represent each component."
msgstr ""

#: ../../source/components/components/system_models.rst:166
msgid "The location of each component."
msgstr ""

#: ../../source/components/components/system_models.rst:167
msgid "The path for each connection"
msgstr ""

#: ../../source/components/components/system_models.rst:170
msgid "Component Icon"
msgstr ""

#: ../../source/components/components/system_models.rst:172
msgid ""
"The icon used for each component is simply whatever drawing primitives are "
"included in the ``Icon`` annotation for that component's definition.  The "
"details of the ``Icon`` annotation were covered in our previous discussion "
"of :ref:`graphical-annos`."
msgstr ""

#: ../../source/components/components/system_models.rst:182
msgid "Component Placement"
msgstr ""

#: ../../source/components/components/system_models.rst:184
msgid ""
"Now that we know what to draw for each component, we need to know where to "
"draw it.  This is where the ``Placement`` annotation comes in.  This "
"annotation appeared in many of the examples in this chapter, *e.g.,*"
msgstr ""

#: ../../source/components/components/system_models.rst:194
msgid ""
"The ``Placement`` annotation simply establishes a rectangular region in "
"which to draw the icon associated with each component.  As with other :ref"
":`graphical-annos`, we can describe the ``Placement`` annotation in terms of"
" a ``record`` definition:"
msgstr ""

#: ../../source/components/components/system_models.rst:207
msgid ""
"The ``visible`` field serves the same purpose as it does in the "
"``GraphicItem`` annotation we discussed earlier, *i.e.,* it is used to "
"control whether the component is rendered or not."
msgstr ""

#: ../../source/components/components/system_models.rst:211
msgid ""
"The ``transformation`` field defines how the icon is rendered in a schematic"
" diagram and the ``iconTransformation`` defines how it is rendered if it is "
"considered part of the **subsystem's** icon. Generally, the "
"``iconTransformation`` is only defined for connectors since these are "
"typically the only components that appear in the icon representation."
msgstr ""

#: ../../source/components/components/system_models.rst:218
msgid "The ``Transformation`` annotation, which is defined as follows:"
msgstr ""

#: ../../source/components/components/system_models.rst:228
msgid ""
"The ``rotation`` field indicates how many degrees the component's icon "
"should be rotated and the ``origin`` field indicates the point around which "
"this rotation should occur.  Finally, the ``extent`` field indicates the "
"size of the region the icon will be rendered into."
msgstr ""

#: ../../source/components/components/system_models.rst:234
msgid "Connection Rendering"
msgstr ""

#: ../../source/components/components/system_models.rst:236
msgid ""
"Finally, we have the third topic, rendering the connections.  Again, the "
"annotations that govern how connections are rendered have appeared in many "
"examples.  Now, finally, we'll explain what that information represents.  "
"Consider the following ``connect`` statement from our :ref:`thermal-control`"
" example:"
msgstr ""

#: ../../source/components/components/system_models.rst:246
msgid ""
"Note that the ``connect`` statement is followed by an annotation.  In "
"particular, note that this is a ``Line`` annotation.  We already discussed "
"the :ref:`line-anno`.  The annotation data is the same in this context as it"
" was then."
msgstr ""

#: ../../source/components/components/system_models.rst:62
#: ../../source/components/components/system_models.rst:75
#: ../../source/components/components/system_models.rst:76
#: ../../source/components/components/system_models.rst:77
msgid "connect"
msgstr ""

#: ../../source/components/components/system_models.rst:75
msgid "input"
msgstr ""

#: ../../source/components/components/system_models.rst:76
msgid "output"
msgstr ""

#: ../../source/components/components/system_models.rst:77
msgid "parameter"
msgstr ""

#: ../../source/components/components/system_models.rst:177
msgid "annotation"
msgstr ""

#: ../../source/components/components/system_models.rst:177
msgid "Placement"
msgstr ""
