#
msgid ""
msgstr ""
"Project-Id-Version: Modelica by Example v0.3.6\n"
"Report-Msgid-Bugs-To: mail@modelica.co.kr\n"
"POT-Creation-Date: 2023-01-28 22:37+0000\n"
"PO-Revision-Date: 2023-03-12 22:37+0000\n"
"Last-Translator: Baek Youngjin, mail@modelica.co.kr / Ha HyeonSu, <iloveyou934671@gmail.com>\n"
"Language-Team: modelica.co.kr <mail@modelica.co.k>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Generated-By: Babel 2.6.0\n"


#: ../../source/behavior/equations/physical.rst:4
msgid "Getting Physical"
msgstr ""
"물리적인 이해(Getting Physical)"

#: ../../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 ""
"이전 섹션에서 수학적 동작을 표현하는 것에 대해서 언급하며 시작했지만 *물리적* 동작에 대한 연결을 보여주지는 않았습니다. "
"이 섹션에서는, 물리적 동작을 모델링하여 표현하는 모델을 구축하는 방법을 살펴보겠습니다. "
"그 과정에서 이러한 모델을 물리적 및 엔지니어링 도메인에 연결할 뿐만 아니라 "
"실수를 방지하는 데 도움을 줄 수 있는 몇 가지 언어 기능을 강조하여 보여줄 것입니다. "



#: ../../source/behavior/equations/physical.rst:14
msgid "Let's start with the following example:"
msgstr ""
"다음의 예제로부터 시작 하겠습니다."

#: ../../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 ""
":ref:`first-order` 섹션 에서 다룬 예제에서 보았듯이 기존 예제는 변수와 방정식을 포함하는 ``model`` 정의로 구성되었습니다."

#: ../../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 ""
"이번 예제에서는 처음으로 ``parameter`` 라는 단어가 등장합니다. "
"일반적으로 ``parameter`` 키워드는 값이 *사전에 알려진* (*즉*, 시뮬레이션 이전에 정의되는) 특성을 가진 변수를 나타내는 데 사용합니다. "
"더 정확하게는 ``parameter`` 는 변수의 *variability - 변동성* 을 지정하는 키워드입니다. "
"이에 대해서는 :ref:`variability` 섹션에서 자세히 설명하였으며, "
"우선 ``parameter`` 는 사전에 제공된 값을 가진 변수로 생각하겠습니다."

#: ../../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 ""
"앞에서 보여준 ``NewtonCooling`` 예제를 보면 ``T_inf`` , ``T0`` , ``h`` , ``A`` , ``m`` 그리고 ``c_p`` 의 여섯 가지 파라미터가 있음을 알 수 있습니다. "
"지금까지 본 모든 변수와 마찬가지로 이들은 모두 ``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 ""
"언급한 변수 이외에 다루지 않고 남아있는 것을 살펴 보면, 변수 ``T`` (마찬가지로 ``Real``)가 있습니다."
"이 변수에는  ``parameter`` 한정자가 없기 때문에 그 값은 모델의 방정식에 의해 결정됩니다.


#: ../../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 ""
"다음으로  두 개의 ``방정식(equation)`` 섹션을 봅 수 있습니다. "
"첫 번째는 변수 ``T`` 의 초기 값을 지정하는 방법인, ``initial equation`` 섹션입니다. "
"이 섹션을 통해 ``T`` 의 초기 값은 ``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 ""
"두 번째는 ``T`` 의 동작에 관련된 미분 방정식입니다. "
"이 방정식을 수학적으로 다음과 같이 표현할 수 있습니다."


#: ../../source/behavior/equations/physical.rst:56
msgid "m c_p \\dot{T} = h A (T_{\\infty}-T)"
msgstr ""

#: ../../source/behavior/equations/physical.rst:58
msgid "but in Modelica, we write it as:"
msgstr ""
"그리고 수학적 표현을 모델리카 언어로 작성 하면 다음과 같습니다. "

#: ../../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 ""
"이것은  :ref:`First-Order` 예제의 ``FirstOrder`` 모델에서 본 방정식의 표현과 다르지 않습니다."

#: ../../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 ""
"다만, 주목할 가치가 있는 한 가지는 ``NewtonCooling`` 예제에서는 방정식 왼쪽에 **표현식(expression)** 이 포함되어 있다는 것입니다. "
"모델리카에서는 각 방정식이 단일 변수에 대한 명시적 방정식이 될 필요가 **없습니다.** "
"방정식은 등호 양쪽에 임의의 표현식을 포함할 수 있고,  "
"방정식에 포함된 변수를 해결하기 위해, 방정식을 사용하는 방법을 결정하는 것은 컴파일러의 작업입니다."


#: ../../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 ""
"``NewtonCooling`` 예제와 ``FirstOrder`` 모델을 구분하는 또 다른 점은 서로 다른 ``parameter`` 값을 독립적으로 조정할 수 있다는 것입니다."
"이러한 ``parameter`` 값은 재료 또는 환경 조건의 물리적, 측정 가능한 속성과 연결됩니다."
"즉, 이 버전은 물리적 속성과 관련되어 있기 때문에 ``FirstOrder`` 모델에서 사용하는 단순한 수학적 관계보다 약간 더 물리적입니다."


#: ../../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 ""
"지금 바로 ``NewtonCooling`` 모델을 있는 그대로 실행할 수 없습니다. "
"6개의 ``parameter`` 에 대한 *값*이 부족하기 때문입니다. "
"시뮬레이션할 수 있는 모델을 만들기 위해서 아래 *예제* 와 같은 값을 제공해야 합니다."
 
#: ../../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 ""
"두 예제 사이에서 유일한 차이점은 각 ``parameter`` 변수에 지정된 값이 있는 것입니다.  "
"``NewtonCooling`` 모델에서는 7개의 변수(전체)와 단 하나의 방정식만 있기 때문에 시뮬레이션할 수 없습니다."
"(``initial equation`` 은 실제로는 카운트 되지 않는 이유에 대한 것은 :ref:`initialization` 섹션을 확인하면 됩니다.)"
"그러나 ``NewtonCoolingWithDefaults`` 모델에는 개념적으로 7개의 방정식(그 중 6개는 ``parameter`` 변수의 값 + 방정식 섹션의 하나)과 7개의 미지수가 있습니다."

#: ../../source/behavior/equations/physical.rst:102
msgid ""
"If we simulate the ``NewtonCoolingWithDefaults`` model, we get the "
"following solution for ``T``."
msgstr ""
"``NewtonCoolingWithDefaults`` 모델을 시뮬레이트하면 다음과 같은 ``T`` 에 대한 해를 얻습니다."

#: ../../source/behavior/equations/physical.rst:111
msgid "Physical Units"
msgstr ""
"물리적 의미의 단위(Physical Unit)"

#: ../../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 ""
"이 섹션에서 이미 언급했듯이, 여기서 보이는 예제는 실제 시스템의 개별 속성에 해당하는 개별 물리적 parameter를 포함하기 때문에 좀 더 물리적입니다. "
"그러나  여전히 뭔가를 놓치고 있습니다. "
"이러한 변수는 온도, 질량 *등* 과 같은 물리적 양을 나타내지만 물리적 자료형을 명시적으로 지정하지는 않았습니다."

#: ../../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 ""
"이미 짐작하셨겠지만 ``T`` 변수는 온도입니다."
"이는 변수와 관련된 설명 텍스트에서 명확하게 나타납니다. "
"또한 ``T0`` 및 ``T_inf`` 도 분명히 온도이여야만 한다는 부분을 결정하기 위해, 이전의 모델을 심도 있게 해석하지 않습니다."


#: ../../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 ""
"그러나 ``h`` 또는 ``A`` 와 같은 다른 변수는 어떻게 해야 할 까요? 이 변수는 무엇을 대표하는 것인가요? "
"사실 더욱 중요한 것은, 방정식이 **물리적으로 일치하는가?** 하는 것입니다. "
"물리적으로 일치한다는 것은 방정식의 양쪽이 동일한 물리적 단위(*예:*, 온도, 질량, 전력)를 갖는다는 것을 의미합니다."
 
#: ../../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 ""
"아래에서 보여지는 것 처럼, 모델리카에서는 실제 변수를 선언하는 구문에서 변수를 선언하는 것 뿐 아니라 다양한 변수의 물리적 단위를 포함하여서 엄격하게 정의 할 수 있습니다. "

#: ../../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 ""
"이제 각 변수 선언에는 ``(unit="...")`` 라는 텍스트가 포함되어 물리적 단위를 변수와 연결합니다. "
"이 추가 텍스트가 하는 일은 변수와 관련된 ``unit`` 속성에 대한 값을 지정하는 것입니다. "
"속성(attributes)은 각 변수가 갖는 특별한 특성입니다. "
"변수가 가질 수 있는 속성 집합은 변수의 자료형에 따라 다릅니다."
"(이에 대해서는 다음 섹션에서 자세히 설명합니다. :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 ""
"언뜻 보기에 단위 속성 (*예를들어*, ``(unit="K")`` )을 지정하는 것이 단순히 변수 다음의 설명 문자열로 ``"Temperature"`` 를 추가하는 것보다 나은 이유가 명확하지 않을 수 있습니다. "
"사실 ``Temperature`` 가 ``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 ""
"그러나  ``unit`` 속성을 설정하는 것은 실제로 두 가지 이유로 더 형식적인 접근 방식입니다. "
"첫 번째 이유는 모델리카 사양이 모든 표준 SI 단위 속성(*예:*, ``K``, ``kg``, ``m``)에 대한 관계를 정의하기 때문입니다. "
"여기에는 다른 기본 단위(*예:*, ``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 ""
"또 다른 이유는 모델리카 사양이 복잡한 수학적 표현의 단위를 계산하는 방법에 대한 규칙도 정의하기 때문입니다. "
"이러한 방식으로 모델리카 사양은 모델리카 모델의 오류 또는 물리적 불일치를 **단위 확인** 하는 데 필요한 모든 것을 정의합니다. "
"단위를 추가하면 모델이 더 명확해질 뿐만 아니라 오류 발생 시 더 나은 진단을 제공하기 때문에 이는 모델 개발자에게 큰 도움이 됩니다."


#: ../../source/behavior/equations/physical.rst:173
msgid "Physical Types"
msgstr ""
"물리적 자료형(Physical Types)"

#: ../../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 ""
"그러나 사실을 말하자면, ``NewtonCoolingWithUnits`` 예제 코드에는 한 가지 단점이 있으며, 모든 변수에 대해 ``unit`` 속성 지정을 반복해야 한다는 것입니다. "
"게다가 앞서 언급했듯이 ``K`` 는 "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 ""
"다행스럽게도 모델리카를 사용하면 *derived types - 파생 자료형* 을 정의할 수 있기 때문에 두 가지 문제에 대한 간단한 해가 됩니다. "
"지금까지  선언한 모든 변수는 ``Real`` 자료형이었습니다. "
"``Real`` 의 문제는 그것이 무엇이든 될 수 있다는 것입니다. (*예를들어*, 전압, 전류, 온도). "
"하고 싶은 것은 이러한 범위를 조금 좁히는 것입니다."
"여기에서 파생 자료형이 사용되고 있습니다. "
"파생 자료형을 정의하고 선언에서 사용하는 방법을 다음 예제로 살펴보겠습니다. "


#: ../../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 ""
"물리적 단위가 Kelvin(``K``)이고 가능한 최소값이 ``0`` 인 ``Real`` 형태인  ``Temperature`` 를 내부에서 정의할 때,"
"``type Temperature=Real(unit="K", min=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 ""
"이 예제에서 ``Temperature`` 와 같은 물리적 자료형을 사전에 정의하면 이를 사용하여,  동일 한 특성을 가지는 다수의 변수"
"(*예를들어*, ``T``, ``T_inf`` 및 ``T0`` )에 대해서 각각 ``unit`` 또는 ``min`` 속성을 지정하지 않아도 됩니다. "
"또한 SI 단위인 ``K`` 대신  ``Temperature`` 라는 친숙한 이름을 사용하게 됩니다. "
"파생 자료형을 만들 때 사용할 수 있는 다른 속성이 무엇인지 궁금 하다면, 관련한 더 자세한 논의는 :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 ""
"이 시점에서 모든 모델에서 ``Temperature``, ``ConvectionCoefficient``, ``SpecificHeat`` 및 ``Mass`` 를 정의하는 것이 매우 번거롭다는 것을 알 수 있습니다. "
"정말 필요하다면 그렇게 해야 할 것입니다만, 걱정하지 않아도 됩니다. "
":ref:`importing_physical_types` 섹션에서 볼수 있듯이 이에 대한 쉬운 해결책을 이후에 논의하겠습니다."


#~ msgid "parameter"
#~ msgstr ""

#~ msgid "attributes"
#~ msgstr ""

#~ msgid "unit attribute"
#~ msgstr ""

#~ msgid "derived types"
#~ msgstr ""

#~ msgid "min attribute"
#~ msgstr ""

#~ msgid "type"
#~ msgstr ""

