# 
msgid ""
msgstr ""
"Project-Id-Version: Modelica by Example 0.2.1\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2014-04-14 10: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/behavior/equations/physical.rst:4
msgid "Getting Physical"
msgstr ""
"Llegando a la física"

#: ../../source/behavior/equations/physical.rst:6
msgid ""
"Although the previous section got us started with representing mathematical "
"behavior, it doesn't convey any connection to *physical* behavior.  In this "
"section, we'll explore how to build models that represent the modeling of "
"physical behavior.  Along the way, we will highlight some of the language "
"features we can leverage that will not only tie these models to physical and"
" engineering domains, but, as we shall see, they can even help us avoid "
"mistakes."
msgstr ""
"Aunque en la sección anterior comenzamos representando comportamiento "
"matemático, no contiene ninguna conexión con el comportamiento *físico*. En esta "
"sección, exploraremos cómo construir modelos que representan el modelado del "
"comportamiento físico. A lo largo del camino, destacaremos algunas características "
"del lenguaje aprovechando que no solamente unirán estos modelos a los dominios "
"físicos y de la ingeniería, sino, como veremos, incluso pueden ayudarnos a evitar "
"errores."

#: ../../source/behavior/equations/physical.rst:14
msgid "Let's start with the following example:"
msgstr ""
"Comencemos con el siguiente ejemplo:"

#: ../../source/behavior/equations/physical.rst:22
msgid ""
"As we saw in the examples in our discussion of :ref:`first-order`, the "
"previous example consists of a ``model`` definition that includes variables "
"and equations."
msgstr ""
"Como vimos en los ejemplos en nuestra discusión de :ref:`first-order`, el "
"ejemplo anterior consiste en la definición de un ``model`` que incluye variables "
"y ecuaciones."

#: ../../source/behavior/equations/physical.rst:26
msgid ""
"However, this time we see the word ``parameter`` for the first time. "
"Generally speaking, the ``parameter`` keyword is used to indicate variables "
"whose value is known *a priori* (*i.e.*, prior to the simulation).  More "
"precisely, ``parameter`` is a keyword that specifies the *variability* of a "
"variable.  This will be discussed more thoroughly in the section on "
":ref:`variability`.  But for now, we can think of a ``parameter`` as a "
"variable whose value we must provide."
msgstr ""
"Sin embargo, en esta ocasión vemos la palabra ``parameter`` por primera vez. "
"En términos generales, la palabra clave ``parameter`` se usa para indicar variables "
"cuyo valor es conocido *a priori* (*es decir*, antes de la simulación). Más "
"concretamente, ``parameter`` es una palabra clave que especifica la *variabilidad* de una "
"variable. Esto se tratará con más detalle en la sección sobre "
":ref:`variability`. Pero por ahora, podemos pensar en un ``parameter`` como una "
"variable cuyo valor debemos proporcionar."

#: ../../source/behavior/equations/physical.rst:35
msgid ""
"Looking at our ``NewtonCooling`` example, we see there are five parameters: "
"``T_inf``, ``T0``, ``h``, ``A``, ``m`` and ``c_p``.  We don't need to bother"
" explaining what these variables are because the model itself includes a "
"descriptive string for each one.  At the moment, there are no values for "
"these parameters, but we will return to that topic shortly.  As with all the"
" variables we have seen so far, these are all of type ``Real``."
msgstr ""
"Mirando a nuestro ejemplo ``NewtonCooling``, vemos que hay cinco parametros: "
"``T_inf``, ``T0``, ``h``, ``A``, ``m`` y ``c_p``. No necesitamos preocuparnos de "
"explicar qué son estas variables porque el modelo mismo incluye un "
"string descriptivo para cada una. Por el momento, no hay valores para "
"estos parámetros, pero volveremos a este tema en breve. Como todas las "
"variables que hemos visto hasta ahora, estas son todas del tipo ``Real``."

#: ../../source/behavior/equations/physical.rst:43
msgid ""
"Let's examine the rest of this model.  The next variable is ``T`` (also a "
"``Real``).  Since this variable doesn't have the ``parameter`` qualifier, "
"its value is determined by the equations in the model."
msgstr ""
"Examinemos el resto de este modelo. La siguiente variable es ``T`` (también "
"``Real``). Como esta variable no tiene el calificativo ``parameter``, "
"su valor es determinado por las ecuaciones del modelo."

#: ../../source/behavior/equations/physical.rst:47
msgid ""
"Next we see the two ``equation`` sections.  The first is an ``initial "
"equation`` section which specifies how the variable ``T`` should be "
"initialized.  It should be pretty clear that the initial value for ``T`` is "
"going to be whatever value was given (by us) for the parameter ``T0``."
msgstr ""
"Despues vemos las dos secciones ``equation``. La primera es una sección ``initial "
"equation`` que especifica cómo debe ser inicializada "
"la variable ``T``. Debe quedar muy claro que el valor inicial para ``T`` va "
"a ser cualquier valor asignado (por nosotros) al parámetro ``T0``."

#: ../../source/behavior/equations/physical.rst:53
msgid ""
"The other equation is the differential equation that governs the behavior of"
" ``T``.  Mathematically, we could express this equation as:"
msgstr ""
"La otra ecuación es la ecuación diferencial que gobierna el comportamiento de "
"``T``. Matemáticamente, podemos expresar esta ecuación como:"

#: ../../source/behavior/equations/physical.rst:58
msgid "but in Modelica, we write it as:"
msgstr ""
"pero en Modelica, la escribimos como:"

#: ../../source/behavior/equations/physical.rst:64
msgid ""
"Note that this is really no different from the equation we saw in our "
"``FirstOrder`` model from the :ref:`first-order` example."
msgstr ""
"Observa que ésta realmente no es diferente de la ecuación que vimos en nuestro "
"modelo ``FirstOrder`` del ejemplo :ref:`first-order`."

#: ../../source/behavior/equations/physical.rst:67
msgid ""
"One thing worth noting is that the equation in our ``NewtonCooling`` example"
" contains an **expression** on the left hand side.  In Modelica, it is "
"**not** necessary for each equation to be an explicit equation for a single "
"variable.  An equation can contain arbitrary expressions on either side of "
"the equals sign.  It is the compiler's job to determine how to use these "
"equations to solve for the variables contained in the equations."
msgstr ""
"Una cosa que merece ser mencionada es que la ecuación en nuestro ejemplo ``NewtonCooling`` "
"contiene una **expresión** en el lado izquierdo. En Modelica, **no** es "
"necesario que cada ecuación sea una ecuación explícita para una única "
"variable. Una ecuación puede contener expresiones arbitrarias en cualquier lado del "
"signo de igualdad. Es trabajo del compilador determinar cómo usar estas "
"ecuaciones para resolver las variables contenidas en ellas."

#: ../../source/behavior/equations/physical.rst:75
msgid ""
"Another thing that distinguishes our ``NewtonCooling`` example from the "
"``FirstOrder`` model is that we can independently adjust the different "
"parameter values.  Furthermore, these parameter values are tied to physical,"
" measurable properties of the materials or environmental conditions.  In "
"other words, this version is slightly more physical than the simple "
"mathematical relationship used in the ``FirstOrder`` model because it is "
"related to physical properties."
msgstr ""
"Otra cosa que distingue nuestro ejemplo ``NewtonCooling`` del "
"modelo ``FirstOrder`` es que podemos ajustar independientemente los diferentes "
"valores de los parámetros. Además, estos parámetros están unidos a propiedades físicas "
"medibles de los materiales o de las condiciones ambientales. En "
"otras palabras, esta versión es ligeramente más física que la simple "
"relación matemática usada en el modelo ``FirstOrder`` porque está "
"relacionada con propiedades físicas."

#: ../../source/behavior/equations/physical.rst:83
msgid ""
"Now, we can't really run the ``NewtonCooling`` model as is because it lacks "
"*values* for the six parameters.  In order to create a model that is ready "
"to be simulated, we need to provide those values, *e.g.*,"
msgstr ""
"Ahora, no podemos ejecutar el modelo ``NewtonCooling`` tal como es porque le faltan "
"*valores* para los seis parámetros. Para crear un modelo que esté listo "
"para ser simulado, necesitamos proporcionar esos valores, *p.ej.*,"

#: ../../source/behavior/equations/physical.rst:92
msgid ""
"The only real difference here is that each of the ``parameter`` variables "
"now has a value specified.  One way to think about the ``NewtonCooling`` "
"model is that we could not simulate it because it had 7 variables (total) "
"and only one equation (see the section on :ref:`initialization` for an "
"explanation of why the ``initial equation`` doesn't really count).  However,"
" the ``NewtonCoolingWithDefaults`` model has, conceptually speaking, 7 "
"equations (6 of them coming from specifying the values of the ``parameter`` "
"variables + one in the equation section) and 7 unknowns."
msgstr ""
"La única diferencia real aquí es que cada una de las variables ``parameter`` "
"ahora tiene un valor especificado. Una manera de pensar sobre el modelo ``NewtonCooling`` "
"es que no podíamos simularlo porque tenía 7 variables (en total) "
"y una única ecuación ( ver la sección :ref:`initialization` para una "
"explicación sobre porque la ``initial equation`` no cuenta). Sin embargo, "
"el modelo ``NewtonCoolingWithDefaults`` tiene, conceptualmente, 7 "
"ecuaciones (6 de ellas provienen de especificar los valores de las variables "
"``parameter`` + una en la sección equation) y 7 incógnitas.

#: ../../source/behavior/equations/physical.rst:102
msgid ""
"If we simulate the ``NewtonCoolingWithDefaults`` model, we get the following"
" solution for ``T``."
msgstr ""
"Si simulamos el modelo ``NewtonCoolingWithDefaults``, obtenemos la siguiente "
"solución para ``T``."

#: ../../source/behavior/equations/physical.rst:111
msgid "Physical Units"
msgstr ""
"Unidades físicas"

#: ../../source/behavior/equations/physical.rst:113
msgid ""
"As mentioned already in this section, these examples are a bit more physical"
" because they include individual physical parameters that correspond to "
"individual properties of our real world system. However, we are still "
"missing something.  Although these variables represent physical quantities "
"like temperature, mass, *etc.*, we haven't explicitly given them any "
"physical types."
msgstr ""
"Como se ha mencionado ya en esta sección, estos ejemplos son un poco más físicos "
"porque incluyen parámetros físicos individuales que se corresponden con "
"propiedades individuales de nuestro sistema del mundo real. Sin embargo, todavía nos "
"falta algo. Aunque estas variables representan cantidades físicas "
"como temperatura, masa, *etc.*, no les hemos asignado explicitamente ningún "
"tipo físico."

#: ../../source/behavior/equations/physical.rst:120
msgid ""
"As you may have already guessed, the variable ``T`` is a temperature. This "
"is made clear in the descriptive text associated with the variable.  "
"Furthermore, it doesn't take a very deep analysis of our previous model to "
"determine that ``T0`` and ``T_inf`` must also be temperatures."
msgstr ""
"Como ya habreis imaginado, la variable ``T`` es una temperatura. Esto "
"queda claro en el texto descriptivo asociado con la variable. "
"Además, no se requiere un análisis profundo de nuestro modelo anterior para "
"determinar que ``T0`` y ``T_inf`` deben ser también temperaturas."

#: ../../source/behavior/equations/physical.rst:126
msgid ""
"But what about the other variables like ``h`` or ``A``?  What do they "
"represent?  Even more important, are the equations **physically "
"consistent**?  By physically consistent, we mean that both sides of the "
"equations have the same physical units (*e.g.*, temperature, mass, power)."
msgstr ""
"Pero ¿que pasa con las otras variables como ``h`` y ``A``? ¿Qué "
"representan? Aun más importante, ¿las ecuaciones son **consistentes "
"físicamente**? Por consistentes físicamente, queremos decir que ambos lados de las "
"ecuaciones tengan las mismas unidades físicas (*p.ej.*, temperatura, masa, potencia)."

#: ../../source/behavior/equations/physical.rst:132
msgid ""
"We could convey the physical units of the different variables more "
"rigorously by actually including them in the variable declarations, like so:"
msgstr ""
"Podemos representar las unidades físicas de las diferentes variables de forma más "
"rigurosa incluyéndolas en las declaraciones de las variables, como:"

#: ../../source/behavior/equations/physical.rst:142
msgid ""
"Note that each of the variable declarations now includes the text "
"``(unit=\"...\")`` to associate a physical unit with the variable.  What "
"this additional text does is specify a value for the ``unit`` attribute "
"associated with the variable.  Attributes are special properties that each "
"variable has.  The set of attributes a variable can have depends on the type"
" of the variable (this is discussed in more detail in the upcoming section "
"on :ref:`variables`)."
msgstr ""
"Observa que ahora las declaraciones de las variables incluyen el texto "
"``(unit=\"...\")`` para asociar una unidad física con la variable. Lo que "
"hace este texto adicional es especificar un valor para el atributo ``unit`` "
"asociado con la variable. Los atributos son propiedades especiales que tiene cada "
"variable. El conjunto de atributos que una variable puede tener depende del tipo "
"de variable (esto se trara en más detalle en la siguiente sección sobre "
":ref:`variables`)."

#: ../../source/behavior/equations/physical.rst:150
msgid ""
"At first glance, it may not seem obvious why specifying the unit attribute "
"(*e.g.*, ``(unit=\"K\")``) is any better than simply adding "
"``\"Temperature\"`` to the descriptive string following the variable. In "
"fact, one might even argue it is worse because \"Temperature\" is more "
"descriptive than just a single letter like \"K\"."
msgstr ""
"En un primer vistazo, puede no parecer obvio porque especificar el atributo unit "
"(*e.g.*, ``(unit=\"K\")``) es mejor que simplemente añadir "
"``\"Temperature\"`` al texto descriptivo que sigue a la variable. De "
"hecho, uno puede argumentar que es incluso peor porque \"Temperature\" es más "
"descriptivo que una simple letra como \"K\"."  

#: ../../source/behavior/equations/physical.rst:156
msgid ""
"However, setting the ``unit`` attribute is actually a more formal approach "
"for two reasons.  The first reason is that the Modelica specification "
"defines relationships for all the standard SI unit attributes (*e.g.*, "
"``K``, ``kg``, ``m``).  This includes complex unit types that can be "
"composed of other base units (*e.g.*, ``N``)."
msgstr ""
"Sin embargo, definir el atributo ``unit`` es realmente una aproximación más formal "
"por dos razones. La primera razon es que la especificación de Modelica "
"define relaciones para todos los atributos de las unidades estandar del SI (*p.ej.*, "
"``K``, ``kg``, ``m``). Esto incluye tipos de unidades complejos que pueden "
"componerse con otras unidades base (*p.ej.*, ``N``)."

#: ../../source/behavior/equations/physical.rst:162
msgid ""
"The other reason is that the Modelica specification also defines rules for "
"how to compute the units of complex mathematical expressions.  In this way, "
"the Modelica specification defines everything that is necessary to **unit "
"check** Modelica models for errors or physical inconsistencies.  This is a "
"big win for model developers because adding units not only makes the models "
"clearer, it provides better diagnostics in the case of errors."
msgstr ""
"La otra razón es que la especificación de Modelica también define las normas sobre "
"cómo computar las unidades de expresiones matemáticas complejas. De esta manera, "
"la especificación de Modelica define todo lo necesario para hacer una **verificación "
"de unidades* de los modelos de Modelica para identificar errores o inconsistencias físicas. Esto es una "
"gran ventaja para los desarrolladores de modelos porque añadir unidades no solo hace los modelos "
"más claros, sino que proporciona diagnósticos mejores en caso de errores." 

#: ../../source/behavior/equations/physical.rst:173
msgid "Physical Types"
msgstr ""
"Tipos físicos"

#: ../../source/behavior/equations/physical.rst:175
msgid ""
"But truth be told, there is one drawback of the code for our "
"``NewtonCoolingWithUnits`` example and that is that we have to repeat the "
"``unit`` attribute specification for every variable.  Furthermore, as "
"mentioned previously, ``K`` isn't nearly as descriptive as \"Temperature\"."
msgstr ""
"Pero para decir toda la verdad, hay una desventaja del código para nuestro "
"ejemplo ``NewtonCoolingWithUnits`` y ésta es que tenemos que repetir la "
"especificación del atributo ``unit`` para todas las variables. Además, tal "
"como se ha mencionado previamente, ``K`` no es tan descriptivo como \"Temperature\"."

#: ../../source/behavior/equations/physical.rst:183
msgid ""
"Fortunately, we have a simple solution to both problems because Modelica "
"allows us to define *derived types*.  So far, all the variables we have "
"declared have been of type ``Real``.  The problem with ``Real`` is that it "
"could be anything (*e.g.*, a voltage, a current, a temperature).  What we'd "
"like to do is narrow things down a bit.  This is where derived types come "
"in.  To see how to define derived types and then use them in declarations, "
"consider the following example:"
msgstr ""
"Afortunadamente, tenemos una solución simple para ambos problemas porque Modelica "
"nos permite definir *tipos derivados*. Hasta ahora, todas las variables que hemos "
"declarado han sido del tipo ``Real``. El problema con ``Real`` es que "
"puede ser cualquier cosa (*p.ej.*, un voltaje, una corriente, una temperatura). Lo que nos "
"gustaría hacer es facilitar las cosas un poco. Aquí es donde aparecen los tipos derivados. "
"Consideremos el siguiente ejemplo para ver cómo definir tipos derivados y después usarlos "
"en las declaraciones:"

#: ../../source/behavior/equations/physical.rst:199
msgid ""
"You can read the definition ``type Temperature=Real(unit=\"K\", min=0);`` as"
" \"Let us define a new type, ``Temperature``, that is a specialization of "
"the built-in type ``Real`` with physical units of Kelvin (``K``) and a "
"minimum possible value of ``0``\"."
msgstr ""
"Podeis leer la definición ``type Temperature=Real(unit=\"K\", min=0);`` como"
" \"Vamos a definir un nuevo tipo, ``Temperature``, que es una especialización de "
"el tipo predefinido ``Real`` con unidades físicas de grados Kelvin (``K``) y un "
"valor mínimo posible de ``0``\"."  

#: ../../source/behavior/equations/physical.rst:204
msgid ""
"From this example, we can see that once we define a physical type like "
"``Temperature``, we can use it to declare multiple variables (*e.g.*, ``T``,"
" ``T_inf`` and ``T0``) without having to specify the ``unit`` or ``min`` "
"attribute for each variable.  Also, we get to use the familiar name "
"``Temperature`` instead of the SI unit, ``K``.  You might be wondering what "
"other attributes are available when creating derived types.  For further "
"discussion, see the section on :ref:`builtin-types`."
msgstr ""
"En este ejemplo, podemos ver que una vez que definimos un tipo físico como "
"``Temperature``, podemos usarlo para declarar multiples variables (*p.ej.*, ``T``, "
"``T_inf`` y ``T0``) sin tener que especificar los atributos ``unit`` o ``min`` "
"para cada variable. Además, podemos utilizar el nombre familiar "
"``Temperature`` en lugar de la unidad del SI, ``K``. Quizá os esteis preguntando qué "
"otros atributos están disponibles cuando se crean tipos derivados. Para más "
"detalles, ver la sección sobre :ref:`builtin-types`."

#: ../../source/behavior/equations/physical.rst:213
msgid ""
"At this point, you might find the idea of defining ``Temperature``, "
"``ConvectionCoefficient``, ``SpecificHeat`` and ``Mass`` in every model "
"extremely tedious.  It would be, if it were truly necessary. But don't "
"worry, there is an easy solution to this as you will see in a later section "
"where we discuss :ref:`importing_physical_types`."
msgstr ""
"En este punto, puede que encontreis la idea de definir ``Temperature``, "
"``ConvectionCoefficient``, ``SpecificHeat`` y ``Mass`` en cada modelo "
"extremadamente tedioso. Lo sería, si realmente fuera necesario. Pero no hay que "
"preocuparse, hay una solución fácil para esto como vereis en una sección posterior "
"donde trataremos sobre :ref:`importing_physical_types`." 

#: ../../source/behavior/equations/physical.rst:20
msgid "parameter"
msgstr ""
"parametro"

#: ../../source/behavior/equations/physical.rst:140
msgid "attributes"
msgstr ""
"atributos"

#: ../../source/behavior/equations/physical.rst:140
msgid "unit attribute"
msgstr ""
"atributo unit"

#: ../../source/behavior/equations/physical.rst:181
msgid "derived types"
msgstr ""
"tipos derivados"

#: ../../source/behavior/equations/physical.rst:196
msgid "min attribute"
msgstr ""
"atributo min"

#: ../../source/behavior/equations/physical.rst:197
msgid "type"
msgstr ""
"tipo"
