# 
msgid ""
msgstr ""
"Project-Id-Version: Modelica by Example 0.2.1\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2014-04-14 10:14-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/heat_transfer.rst:4
msgid "Heat Transfer Components"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:6
msgid ""
"We'll start our discussion of component models by building some component "
"models in the heat transfer domain.  These models will allow us to recreate "
"the models we saw :ref:`previously <getting-physical>`, but this time using "
"component models to represent each of the various effects.  Investing the "
"time to make component models will then allow us to easily combine the "
"underlying physical behavior to create models for a wide variety of thermal "
"systems."
msgstr ""

#: ../../source/components/components/heat_transfer.rst:15
msgid "Thermal Connectors"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:17
msgid ""
"In our previous discussion on :ref:`simple-domains` we described how a "
"thermal connector could be described.  For the component models in this "
"section, we will utilize the thermal connector models from the Modelica "
"Standard Library.  These connectors are defined as follows:"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:59
msgid ""
"Careful inspection of these connector definitions shows that ``HeatPort_a`` "
"and ``HeatPort_b`` are identical in terms of their content to the "
"``HeatPort`` model.  The only difference is that ``HeatPort_a`` and "
"``HeatPort_b`` have distinguishing graphical icons."
msgstr ""

#: ../../source/components/components/heat_transfer.rst:64
msgid ""
"The component models presented in the remainder of this section will utilize"
" these connector definitions."
msgstr ""

#: ../../source/components/components/heat_transfer.rst:68
msgid "Component Models"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:70
msgid ""
"When building component models, the goal is to create component models that "
"implement (only) one physical effect (*e.g.,* capacitance, convection).  By "
"implementing component models in this way, we will see that they can then be"
" combined in any infinite number of different configurations without the "
"need to add any more equations.  This kind of reuse of equations makes the "
"model developer more productive and avoids opportunities to introduce "
"errors."
msgstr ""

#: ../../source/components/components/heat_transfer.rst:81
msgid "Thermal Capacitance"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:83
msgid ""
"Our first component model will be a model of lumped thermal capacitance. "
"with uniform temperature distribution. The equation we wish to associate "
"with this component model is:"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:92
msgid ""
"The Modelica model (with the ``Icon`` annotation removed) representing this "
"equation is quite simple:"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:99
msgid ""
"where ``C`` is the thermal capacitance and ``T0`` is the initial "
"temperature."
msgstr ""

#: ../../source/components/components/heat_transfer.rst:102
msgid ""
"Note the presence of the ``node`` connector in this model.  This is how the "
"``ThermalCapacitance`` component model interacts with the \"outside world\"."
"  We will use the temperature at the ``node``, ``node.T`` to represent the "
"temperature of the thermal capacitance. The ``flow`` variable, "
"``node.Q_flow``, represents the flow of heat **into** the thermal "
"capacitance.  We can see this when looking at the equation for the thermal "
"capacitance:"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:114
msgid ""
"Note that when ``node.Q_flow`` is positive, the temperature of the thermal "
"capacitance, ``node.T``, will increase.  This confirms that we have followed"
" the Modelica convention that ``flow`` variables on a connector represent a "
"flow of the conserved quantity, heat in this case, into the component (a "
"more thorough discussion of :ref:`flow-signs` will be presented shortly)."
msgstr ""

#: ../../source/components/components/heat_transfer.rst:121
msgid ""
"Using this model alone, we can already build a simple \"system\" model as "
"follows:"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:127
msgid ""
"This model contains only the thermal capacitance element (as indicated by "
"the declaration of the variable ``cap`` of type ``ThermalCapacitance``) and "
"no other heat transfer elements (*e.g.,* conduction, convection, radiation)."
"  Ignore the ``Placement`` annotation for the moment, we'll provide a "
"complete explanation in a later section on :ref:`comp-annos`."
msgstr ""

#: ../../source/components/components/heat_transfer.rst:134
msgid ""
"Using the graphical annotations in the model (some of which were left out of"
" the previous listing) it can be rendered as:"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:142
msgid ""
"Since no heat enters or leaves the thermal capacitance component, ``cap``, "
"the temperature of the capacitance remains constant as shown in the "
"following plot:"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:150
msgid "ConvectionToAmbient"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:152
msgid ""
"To quickly add some heat transfer, we could define another component model "
"to represent heat transfer to some ambient temperature.  Such a model could "
"be represented in Modelica (again, without the ``Icon`` annotation) as "
"follows:"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:161
msgid ""
"This model includes parameters for the heat transfer coefficient, ``h``, the"
" surface area, ``A`` and the ambient temperature, ``T_amb``. This model is "
"attached to other heat transfer elements through the connector ``port_a``."
msgstr ""

#: ../../source/components/components/heat_transfer.rst:166
msgid ""
"Again, we must pay close attention to the sign convention.  Recall from our "
"previous discussion of :ref:`thermal-capacitance` that Modelica follows a "
"sign convention that a positive value for a ``flow`` variable represents "
"flow into the component.  In particular, let's take a close look at the "
"equation in the ``ConvectionToAmbient`` model:"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:177
msgid ""
"Note that when ``port_a.T`` is greater than ``T_amb``, the sign of "
"``port_a.Q_flow`` is greater than zero.  That means heat is flowing **into**"
" this component.  In other words, when ``port_a.T`` is greater than "
"``T_amb``, this component will **take heat away** from ``port_a`` (and, "
"conversely, when ``T_amb`` is greater than ``port_a.T``, it will **inject "
"heat into** ``port_a``)."
msgstr ""

#: ../../source/components/components/heat_transfer.rst:184
msgid ""
"Having such a component model available enables us to combine it with the "
"``ThermalCapacitance`` model and simulate a system just like we modeled in "
":ref:`some of our earlier heat transfer examples <getting-physical>` using "
"the following Modelica code:"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:194
msgid ""
"In this model, we see two components have been declared, ``cap`` and "
"``conv``.  The parameters for each of these components are also specified "
"when they are declared.  The following is a schematic for the "
"``CoolingToAmbient`` model:"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:204
msgid ""
"But what is really remarkable about this model is the equation section:"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:211
msgid ""
"This statement introduces one of the most important features in Modelica.  "
"Note that statement appears within an ``equation`` section.  While the "
"``connect`` operator looks like a function, it is much more than that.  It "
"represents the equations that should be generated to model the interaction "
"between the two specified connectors, ``cap.node`` and ``conv.port_a``."
msgstr ""

#: ../../source/components/components/heat_transfer.rst:218
msgid ""
"In this context, a connection does two important things.  The first thing it"
" does is to generate an equation that equates the \"across\" variables on "
"either connector.  In this case, that means the following equation:"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:227
msgid ""
"In addition, a connection generates an equation for all the through "
"variables as well.  The equation that is generated is a conservation "
"equation.  You can think of this conservation equation as a generalization "
"of Kirchoff's current law to any conserved quantity. Basically, it "
"represents the fact that the connection itself has no \"storage\" ability "
"and that whatever amount of the conserved quantity, in this case heat, that "
"flows out of one component must go into the other(s).  So in this case, the "
"connect statement will generate the following equation with respect to the "
"``flow`` variables:"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:241
msgid ""
"Note the sign convention here.  All the ``flow`` variables are summed. We "
"will examine more complex cases shortly where multiple components are "
"interacting.  But in this simple case, with only two components, we see "
"clearly that if one value for ``Q_flow`` is positive, the other must be "
"negative.  In other words, if heat is flowing out of one component, it must "
"be flowing into another.  These conservation equations ensure that we have a"
" proper accounting of conserved quantities throughout our network and that "
"no amount of the conserved quantity gets \"lost\"."
msgstr ""

#: ../../source/components/components/heat_transfer.rst:251
msgid ""
"A very simple way to summarize the behavior of a connection, in the context "
"of a thermal problem, is to **think of a connection as a perfectly "
"conducting element with no thermal capacitance**."
msgstr ""

#: ../../source/components/components/heat_transfer.rst:255
msgid ""
"If we simulate the ``CoolingToAmbient`` model above, we get the following "
"temperature trajectory:"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:264
msgid "Digging Deeper"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:266
msgid ""
"There is one slight issue with the ``CoolingToAmbient`` model.  We mentioned"
" earlier that when building component models it is best to isolate each "
"individual physical effect to its own component.  But we've actually lumped "
"two different effects into one component.  As we will see in a moment, this "
"limits the reusability of the component models. But first, let's refactor "
"the code to separate these effects out and then we'll revisit the system "
"level model using these new components."
msgstr ""

#: ../../source/components/components/heat_transfer.rst:275
msgid "Convection"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:277
msgid ""
"The first new component is a ``Convection`` model.  In this case, we won't "
"make any assumptions about the temperature at either end. Instead, we'll "
"only assume that each is connected to something with an appropriate thermal "
"connector.  The result is a model like this one:"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:286
msgid "This model contains two equations.  The first equation:"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:292
msgid ""
"represents the fact that this component does not store heat.  The equation "
"enforces the constraint that whatever heat flows in from one connector must "
"flow out from the other (which is exactly the same behavior we saw from the "
"``connect`` statement earlier in this section).  The next equation:"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:302
msgid ""
"captures the heat transfer relationship for convection by expressing the "
"relationship between the flow of heat through this component and the "
"temperatures on either end."
msgstr ""

#: ../../source/components/components/heat_transfer.rst:0
msgid "Number of equations"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:310
msgid ""
"All our previous models had one connector and one equation.  The "
"``Convection`` model has two connectors.  As a result, it has two equations."
"  A simple rule of thumb is that you need as many equations as connectors.  "
"But keep in mind that this rule of thumb assumes that you are using "
"connectors with only one through variable on them and no \"internal "
"variables\" in your model (*e.g.,* ``protected`` variables).  The upcoming "
"section on :ref:`model-comps` will provide a more comprehensive discussion "
"on determining how many equations a component requires. Specifically, it "
"will provide guidance on how to build so-called :ref:`balanced-components`."
msgstr ""

#: ../../source/components/components/heat_transfer.rst:325
msgid "AmbientCondition"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:327
msgid ""
"Now that we have the convection model, we need something to represent the "
"ambient conditions.  We need something like a thermal capacitance model, but"
" one that maintains a constant temperature.  Imagine if we took the "
"``ThermalCapacitance`` model and gave a very large value for its "
"capacitance, ``C``.  Then we'd have something that changed temperature very "
"slowly.  But what we want is something that doesn't change temperature at "
"all, as if it had a ``C`` value that was infinitely large."
msgstr ""

#: ../../source/components/components/heat_transfer.rst:338
msgid ""
"This kind of model comes up frequently and it is commonly called an "
"\"infinite reservoir\" model.  Typically, such a model is characterized by "
"the fact that no matter how much of the conserved quantity (heat in this "
"case) flows into or out of the component, the across variable remains "
"constant.  In an electrical context, such a model would represent electrical"
" ground.  In a mechanical context, it would represent a mechanical ground "
"(something that didn't change position, regardless of how much force was "
"applied)."
msgstr ""

#: ../../source/components/components/heat_transfer.rst:347
msgid ""
"We will represent our ambient conditions using the ``AmbientConditions`` "
"model:"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:354
msgid ""
"Since we are talking about the heat transfer domain, this model is an "
"infinite reservoir for heat and no matter how much heat flows into or out of"
" this component, its temperature remains the same."
msgstr ""

#: ../../source/components/components/heat_transfer.rst:359
msgid "Flexibility"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:361
msgid ""
"Using these new ``Convection`` and an ``AmbientCondition`` models, we can "
"reconstruct our simple system level heat transfer model using the following:"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:368
msgid "When rendered, the model looks like this:"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:375
msgid ""
"This may not seem like much of an improvement.  Although we went to the "
"trouble to break up the ``ConvectionToAmbient`` model into individual "
"``Convection`` and ``AmbientTemperature`` models, we still end up with the "
"same fundamental behavior, *i.e.,*"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:383
msgid ""
"The big benefit of breaking down ``ConvectionToAmbient`` into ``Convection``"
" and ``AmbientTemperature`` models is the ability to recombine them in "
"different ways.  The following schematic is just one example of how the "
"handful of fundamental components we've constructed so far can be rearranged"
" to form an entirely new (and more complex) model:"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:405
msgid ""
"In fact, with these components we can now make **arbitrarily complex** "
"networks of components and still never have to worry about formulating the "
"associated equations that describe their dynamics.  Everything that is "
"required to do this has already been captured in our component models.  This"
" allows us to focus on the process of creating and designing our system and "
"leave the tedious, time-consuming and error prone work of manipulating "
"equations behind."
msgstr ""

#: ../../source/components/components/heat_transfer.rst:192
msgid "connect"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:306
msgid "number of equations required"
msgstr ""

#: ../../source/components/components/heat_transfer.rst:336
msgid "infinite reservoir"
msgstr ""
