lowercase &gt; and &lt;

thorade · thorade · commit a20707101dd3 · 2016-11-07T17:31:43.000+01:00
diff --git a/BuildSysPro/BaseClasses/HeatTransfer/Sources/FixedHeatFlow.mo b/BuildSysPro/BaseClasses/HeatTransfer/Sources/FixedHeatFlow.mo
@@ -46,7 +46,7 @@ equation
     Documentation(info="<html>
 <p><u><b>Hypothesis and equations</b></u></p>
 <p>This model allows a specified amount of heat flow rate to be &quot;injected&quot; into a thermal system at a given port. The constant amount of heat flow rate Q_flow is given as a parameter. The heat flows into the component to which the component FixedHeatFlow is connected, if parameter Q_flow is positive.</p>
-<p>If parameter alpha is &GT; 0, the heat flow is mulitplied by (1 + alpha*(port.T - T_ref)) in order to simulate temperature dependent losses (which are given an reference temperature T_ref).</p>
+<p>If parameter alpha is &gt; 0, the heat flow is mulitplied by (1 + alpha*(port.T - T_ref)) in order to simulate temperature dependent losses (which are given an reference temperature T_ref).</p>
 <p><u><b>Bibliography</b></u></p>
 <p>none</p>
 <p><u><b>Instructions for use</b></u></p>
diff --git a/BuildSysPro/BaseClasses/HeatTransfer/Sources/PrescribedHeatFlow.mo b/BuildSysPro/BaseClasses/HeatTransfer/Sources/PrescribedHeatFlow.mo
@@ -49,7 +49,7 @@ equation
     Documentation(info="<html>
 <p><u><b>Hypothesis and equations</b></u></p>
 <p>This model allows a specified amount of heat flow rate to be &quot;injected&quot; into a thermal system at a given port. The amount of heat is given by the input signal Q_flow into the model. The heat flows into the component to which the component PrescribedHeatFlow is connected, if the input signal is positive.</p>
-<p>If parameter alpha is &GT; 0, the heat flow is mulitplied by (1 + alpha*(port.T - T_ref)) in order to simulate temperature dependent losses (which are given an reference temperature T_ref).</p>
+<p>If parameter alpha is &gt; 0, the heat flow is mulitplied by (1 + alpha*(port.T - T_ref)) in order to simulate temperature dependent losses (which are given an reference temperature T_ref).</p>
 <p><u><b>Bibliography</b></u></p>
 <p>none</p>
 <p><u><b>Instructions for use</b></u></p>
diff --git a/BuildSysPro/BoundaryConditions/Scenarios/CombiTimeTable.mo b/BuildSysPro/BoundaryConditions/Scenarios/CombiTimeTable.mo
@@ -117,7 +117,7 @@ initial equation
 <span style=\"font-family: Courier New,courier;\">             = 1: smooth interpolation with Akima Splines such</span>
 <span style=\"font-family: Courier New,courier;\">                  that der(y) is continuous.</span></pre>
 <li>If the table has only <b>one row</b>, no interpolation is performed and the table values of this row are just returned.</li>
-<li>Via parameters <b>startTime</b> and <b>offset</b> the curve defined by the table can be shifted both in time and in the ordinate value. The time instants stored in the table are therefore <b>relative</b> to <b>startTime</b>. If time &LT; startTime, no interpolation is performed and the offset is used as ordinate value for all outputs. </li>
+<li>Via parameters <b>startTime</b> and <b>offset</b> the curve defined by the table can be shifted both in time and in the ordinate value. The time instants stored in the table are therefore <b>relative</b> to <b>startTime</b>. If time &lt; startTime, no interpolation is performed and the offset is used as ordinate value for all outputs. </li>
 <li>The table is implemented in a numerically sound way by generating <b>time events</b> at interval boundaries, in order to not integrate over a discontinuous or not differentiable points. </li>
 <li>For special applications it is sometimes needed to know the minimum and maximum time instant defined in the table as a parameter. For this reason parameters <b>t_min</b> and <b>t_max</b> are provided and can be access from the outside of the table object. </li>
 </ul>
diff --git a/BuildSysPro/BoundaryConditions/Scenarios/StepFunctionMat.mo b/BuildSysPro/BoundaryConditions/Scenarios/StepFunctionMat.mo
@@ -189,7 +189,7 @@ with n rows and two columns and a second table <code>table2 [i, j]</code> n rows
 <ul>
 <li>the interpolation is effcient because the search for a new interpolation starts from the last interval used for the previous interpolation</li>
 <li>if the table has only one row, its values are returned regardless of the input signal value</li>
-<li>if the value of the input signal <code>u</code> is outside the range defined by the first column of the table, for example, u&GT; table [size (table, 1), 1] or u &LT;table [1, 1], the corresponding value is determined by linear extrapolation from the first or last two points of the table</li>
+<li>if the value of the input signal <code>u</code> is outside the range defined by the first column of the table, for example, u&gt; table [size (table, 1), 1] or u &lt;table [1, 1], the corresponding value is determined by linear extrapolation from the first or last two points of the table</li>
 <li>the first column must be strictly monotonic</li>
 </ul>
 <p>A table can be defined as follows:</p>
diff --git a/BuildSysPro/BoundaryConditions/Scenarios/StepFunctionMatPeriodic.mo b/BuildSysPro/BoundaryConditions/Scenarios/StepFunctionMatPeriodic.mo
@@ -190,7 +190,7 @@ with n rows and two columns and a second table <code>table2 [i, j]</code> n rows
 <ul>
 <li>the interpolation is effcient because the search for a new interpolation starts from the last interval used for the previous interpolation</li>
 <li>if the table has only one row, its values are returned regardless of the input signal value</li>
-<li>if the value of the input signal <code>u</code> is outside the range defined by the first column of the table, for example, u&GT; table [size (table, 1), 1] or u &LT;table [1, 1], the corresponding value is determined by linear extrapolation from the first or last two points of the table</li>
+<li>if the value of the input signal <code>u</code> is outside the range defined by the first column of the table, for example, u&gt; table [size (table, 1), 1] or u &lt;table [1, 1], the corresponding value is determined by linear extrapolation from the first or last two points of the table</li>
 <li>the first column must be strictly monotonic</li>
 </ul>
 <p>A table can be defined as follows:</p>
diff --git a/BuildSysPro/BoundaryConditions/Scenarios/StepFunctionSimpleXY.mo b/BuildSysPro/BoundaryConditions/Scenarios/StepFunctionSimpleXY.mo
@@ -38,8 +38,8 @@ protected
 <p><u><b>Instructions for use</b></u></p>
 <p>X vector (dependent variable) and Y vector (data to be interpolated) are 2 vectors having the same size: n elements each.</p>
 <p>For all i from 1 to n-1, for any x in [Xi, X (i + 1) [, calculation of y = Yi</p>
-<p>For all x &GT;= Xn : y = Yn</p>
-<p>For all x, calculation of xp = >if period &GT; 0 then mod(x,period) else x and calculation of y=y(xp)</p>
+<p>For all x &gt;= Xn : y = Yn</p>
+<p>For all x, calculation of xp = >if period &gt; 0 then mod(x,period) else x and calculation of y=y(xp)</p>
 <p><u><b>Validations</b></u></p>
 <p>Validated model - Hassan Bouia 07/2012 </p>
 <p><b>--------------------------------------------------------------<br>
diff --git a/BuildSysPro/BoundaryConditions/Solar/Irradiation/FLUXsurf.mo b/BuildSysPro/BoundaryConditions/Solar/Irradiation/FLUXsurf.mo
@@ -159,7 +159,7 @@ Author : Aurélie KAEMMERLEN, EDF (2011)<br>
 <p><ul>
 <li>Ajout de sorties : hauteur et azimut du soleil, Rayonnement incident diffus provenant du sol</li>
 <li>Vecteur Gh de dimension 9 (anciennement 6) pour ajouter les entrées CoupleFlux, MoyFlux et dt</li>
-<li>Ajout d'une sécurité pour éviter un flux direct infini : sinh&GT;0.01 au lieu de &GT;0 pour le calcul de FDIRN/FDIRH</li>
+<li>Ajout d'une sécurité pour éviter un flux direct infini : sinh&gt;0.01 au lieu de &gt;0 pour le calcul de FDIRN/FDIRH</li>
 </ul></p>
 <p><br>Hassan Bouia 03/2013 : Simplication du calcul solaire - attention nouvelle dimension du vecteur <b>Gh</b> renommé en <b>G</b></p>
 <p>Amy Lindsay 03/2013 : Ajout du paramètre diffus_isotrope pour choisir entre un modèle de diffus isotrope ou le modèle de diffus HDKR</p>
diff --git a/BuildSysPro/BoundaryConditions/Solar/Irradiation/SolarBC.mo b/BuildSysPro/BoundaryConditions/Solar/Irradiation/SolarBC.mo
@@ -382,6 +382,6 @@ BuildSysPro version 2.0.0<br>
 Author : Gilles PLESSIS, EDF (2013)<br>
 --------------------------------------------------------------</b></p>
 </html>",                                                                    revisions="<html>
-<p>Gilles Plessis 12/2013 : Mise à jour des noms des paramètres SurfaceVitree-&GT;SurfacesVitrees et SurfaceExterieures-&GT;SurfacesExterieures</p>
+<p>Gilles Plessis 12/2013 : Mise à jour des noms des paramètres SurfaceVitree-&gt;SurfacesVitrees et SurfaceExterieures-&gt;SurfacesExterieures</p>
 </html>"));
 end SolarBC;
diff --git a/BuildSysPro/BoundaryConditions/Solar/SolarMasks/Masks.mo b/BuildSysPro/BoundaryConditions/Solar/SolarMasks/Masks.mo
@@ -181,7 +181,7 @@ Author : Aurélie KAEMMERLEN, EDF (2013)<br>
 --------------------------------------------------------------</b></p>
 </html>
 ",                                                                           revisions="<html>
-<p>Aurélie Kaemmerlen 04/2013 : Ajout d'une condition sur la hauteur du soleil pour le calcul de la surface ensoleillée. Fait suite à la correction des flux solaires (calcul de l'azimut corrigé - avant il n'était pas déterminé si sinh&LT;=0)</p>
+<p>Aurélie Kaemmerlen 04/2013 : Ajout d'une condition sur la hauteur du soleil pour le calcul de la surface ensoleillée. Fait suite à la correction des flux solaires (calcul de l'azimut corrigé - avant il n'était pas déterminé si sinh&lt;=0)</p>
 <p>Laura Sudries, Vincent Magnaudeix 05/2015 : Ajout de la prise en compte des masques lointains verticaux</p>
 <p>Benoît Charrier 05/2015 : Ajout du choix possible de prise en compte ou non des masques lointains verticaux</p>
 <p>Benoît Charrier 05/2015 : Correction sur le facteur d'affaiblissement du rayonnement solaire direct dû à un masque lointain vertical, qui était appliqué par erreur au rayonnement diffus.</p>
diff --git a/BuildSysPro/BoundaryConditions/Weather/CombiTable1Ds_ForStepMeteo.mo b/BuildSysPro/BoundaryConditions/Weather/CombiTable1Ds_ForStepMeteo.mo
@@ -128,7 +128,7 @@ equation
 <ul>
 <li>The interpolation is <b>efficient</b>, because a search for a new interpolation starts at the interval used in the last call.</li>
 <li>If the table has only <b>one row</b>, the table value is returned, independent of the value of the input signal.</li>
-<li>If the input signal <b>u</b> is <b>outside</b> of the defined <b>interval</b>, i.e., u &GT; table[size(table,1),1] or u &LT; table[1,1], the corresponding value is also determined by linear interpolation through the last or first two points of the table.</li>
+<li>If the input signal <b>u</b> is <b>outside</b> of the defined <b>interval</b>, i.e., u &gt; table[size(table,1),1] or u &lt; table[1,1], the corresponding value is also determined by linear interpolation through the last or first two points of the table.</li>
 <li>The grid values (first column) have to be strictly increasing.</li>
 </ul>
 
diff --git a/BuildSysPro/BoundaryConditions/Weather/Functions/ConvertLongitude.mo b/BuildSysPro/BoundaryConditions/Weather/Functions/ConvertLongitude.mo
@@ -36,7 +36,7 @@ BuildSysPro version 2.0.0<br>
 Author : Aurélie KAEMMERLEN, EDF (2010)<br>
 --------------------------------------------------------------</b></p>
 </html>",                                                                    revisions="<html>
-<p>Aurélie Kaemmerlen 06/2012 : correction de la fonction car le résultat était erroné lors d'une saisie en &deg;Ouest d'une longitude &GT;180&deg; et en &deg;Est d'une longitude &LT;-180&deg;</p>
+<p>Aurélie Kaemmerlen 06/2012 : correction de la fonction car le résultat était erroné lors d'une saisie en &deg;Ouest d'une longitude &gt;180&deg; et en &deg;Est d'une longitude &lt;-180&deg;</p>
 <p>Hassan Bouia 03/2013 : simplification des formules</p>
 </html>"));
 end ConvertLongitude;
diff --git a/BuildSysPro/Building/BuildingEnvelope/HeatTransfer/DoubleGlazingWindow.mo b/BuildSysPro/Building/BuildingEnvelope/HeatTransfer/DoubleGlazingWindow.mo
@@ -331,7 +331,7 @@ equation
 <ul>
 <li>No solar flux transmitted by the part obscured by the shutters</li>
 <li>Absorbed flux unchanged (PVC absorbency similar to that of glass)</li>
-<li>If the shutter is not completely closed (Coeff_Fermeture &LT;95%), unchanged thermal resistance</li>
+<li>If the shutter is not completely closed (Coeff_Fermeture &lt;95%), unchanged thermal resistance</li>
 <li>If the shutter is fully closed, increased thermal resistance of an additional thermal resistance, evaluated at 0.2 m&sup2;K / W (PVC thickness of 12 mm approx.)</li>
 </ul>
 <p>When the window is open, there is \"broke\" of the conductance through the glass, and instead of that a debit of air renewal by natural ventilation is computed (refer to <a href=\"modelica://BuildSysPro.Building.AirFlow.HeatTransfer.WindowNaturalVentilation\"><code>WindowNaturalVentilation</code></a>). </p>
diff --git a/BuildSysPro/Building/BuildingEnvelope/HeatTransfer/SimpleGlazing.mo b/BuildSysPro/Building/BuildingEnvelope/HeatTransfer/SimpleGlazing.mo
@@ -224,7 +224,7 @@ equation
 <ul>
 <li>No solar flux transmitted by the part obscured by the shutters</li>
 <li>Absorbed flux unchanged (PVC absorbency similar to that of glass)</li>
-<li>If the shutter is not completely closed (Coeff_Fermeture &LT;95%), unchanged thermal resistance</li>
+<li>If the shutter is not completely closed (Coeff_Fermeture &lt;95%), unchanged thermal resistance</li>
 <li>If the shutter is fully closed, increased thermal resistance of an additional thermal resistance, evaluated at 0.2 m&sup2;K / W (PVC thickness of 12 mm approx.)</li>
 </ul>
 <p><u><b>Bibliography</b></u></p>
diff --git a/BuildSysPro/Building/BuildingEnvelope/HeatTransfer/Window.mo b/BuildSysPro/Building/BuildingEnvelope/HeatTransfer/Window.mo
@@ -577,7 +577,7 @@ equation
 <ul>
 <li>No solar flux transmitted by the part obscured by the shutters</li>
 <li>Absorbed flux unchanged (PVC absorbency similar to that of glass)</li>
-<li>If the shutter is not completely closed (<code>fermeture_volet</code> &LT; 95%), unchanged thermal resistance</li>
+<li>If the shutter is not completely closed (<code>fermeture_volet</code> &lt; 95%), unchanged thermal resistance</li>
 <li>If the shutter is fully closed, increased thermal resistance of an additional thermal resistance, evaluated at 0.2 m&sup2;K / W (PVC thickness of 12 mm approx)</li>
 </ul>
 <p>When the window is open, the conductive heat transfer through the glass is not considered anymore, and instead of that an air renewal by natural ventilation is computed (refer to <a href=\"modelica://BuildSysPro.Building.AirFlow.HeatTransfer.WindowNaturalVentilation\"><code>WindowNaturalVentilation</code></a>). In addition, the absence of glazing results in a suppression of direct and diffuse transmission factors.</p>
diff --git a/BuildSysPro/Systems/Controls/PBand.mo b/BuildSysPro/Systems/Controls/PBand.mo
@@ -103,7 +103,7 @@ algorithm
 <li>Ymin et Ymax, saturation values (eg. 0 and 1 to obtain a gain).</li>
 <li>Value of the Range, i.e. half bandwidth size</li>
 </ol>
-<p><b>Note :</b> For Range &GT; 0, the proportional band will be decreasing. For an increasing function, all you need is Range &LT; 0, leaving other values unchanged.</p>
+<p><b>Note :</b> For Range &gt; 0, the proportional band will be decreasing. For an increasing function, all you need is Range &lt; 0, leaving other values unchanged.</p>
 <p><u><b>Known limits / Use precautions</b></u></p>
 <p>none</p>
 <p><u><b>Validations</b></u></p>
diff --git a/BuildSysPro/Systems/Controls/PBandHysteresisSingleMode.mo b/BuildSysPro/Systems/Controls/PBandHysteresisSingleMode.mo
@@ -142,8 +142,8 @@ algorithm
 <p>The model returns a value between 0 and 1 from a value X and a setpoint X_ref.></p>
 <p>The regulation is proportional, with a hysteresis loop:</p>
 <ol>
-<li>If X-X_ref &LT; - Range, epsilon = epsmax</li>
-<li>If X-X_ref &GT; Range, epsilon = 0</li>
+<li>If X-X_ref &lt; - Range, epsilon = epsmax</li>
+<li>If X-X_ref &gt; Range, epsilon = 0</li>
 <li>If X belongs to [X_ref-Range; X_ref+Range], proportional regulation or epsilon = 0 according to the entry point in the proportional band.</li>
 </ol>
 <p><u><b>Bibliography</b></u></p>
diff --git a/BuildSysPro/Systems/Controls/PIDFixedDualMode.mo b/BuildSysPro/Systems/Controls/PIDFixedDualMode.mo
@@ -161,7 +161,7 @@ equation
 <p><u><b>Instructions for use</b></u></p>
 <p>none</p>
 <p><u><b>Known limits / Use precautions</b></u></p>
-<p>Of course, this model should not be used if Tc &LT; Tf.</a></p>
+<p>Of course, this model should not be used if Tc &lt; Tf.</a></p>
 <p>Safeguards should be added to prevent bug.</p>
 <p><u><b>Validations</b></u></p>
 <p>Validated model (BESTEST) - Aurélie Kaemmerlen 12/2010</p>
diff --git a/BuildSysPro/Systems/Controls/Switch.mo b/BuildSysPro/Systems/Controls/Switch.mo
@@ -67,7 +67,7 @@ equation
 <p><u><b>Hypothesis and equations</b></u></p>
 <p>Operation: </p>
 <ul><li>If the switch is <u>closed</u>, there is equality between thermal ports temperatures (default if OnOff = 1)</li>
-<li>If the switch is <u>opened</u>, no flow circulates between the two ports (default if OnOff &LT;&GT; 1)</li></ul>
+<li>If the switch is <u>opened</u>, no flow circulates between the two ports (default if OnOff &lt;&gt; 1)</li></ul>
 <p>It is possible to change the value at which the switch is closed by changing the value of <code>valeur_On</code> parameter.</p>
 <p><u><b>Bibliography</b></u></p>
 <p>none</p>
diff --git a/BuildSysPro/Utilities/Analysis/Simulation2CSV.mo b/BuildSysPro/Utilities/Analysis/Simulation2CSV.mo
@@ -78,7 +78,7 @@ annotation(interactive=true,
 <li>In the tab <i>setup</i>, select the name and location of the CSV file and the name of the model to simulate</li>
 <li>In the tab <i>Model parameters </i>select the parameters to be modified from their default value. <b>Warnings, parameters of type String are not changeable by this function,</b></li>
 <li>In the tab <i>Model variables </i>select the variables to be registered in the CSV file, the column <i>description </i>is used to set the title to be associated with the CSV file columns. If it is not given, then the variable name is used.</li>
-<li>The tab <i>preferences</i> <i>-&GT;</i> <i>simulationOptions</i> allows the modification of simulation parameters (<i>startTime..</i>).</li>
+<li>The tab <i>preferences</i> <i>-&gt;</i> <i>simulationOptions</i> allows the modification of simulation parameters (<i>startTime..</i>).</li>
 </ol>
 <p><br>After the successful parameterization of the function, click on <i>Execute </i>in the bottom right of the dialog window. The simulation is performed and variables are saved in the specified CSV file.</p>
 <p><br>This function normally performs a simulation without recording events (<i>saveEvents </i>variable set to <i>false</i> by default), corresponding to the <i>store variables</i> <i>at events </i>box<i> </i>shakeout<i> </i>in the <i>Output </i>tab of the <i>Setup </i>menu (see figure below).</p>
diff --git a/BuildSysPro/Utilities/Math/FindMultiExtremum.mo b/BuildSysPro/Utilities/Math/FindMultiExtremum.mo
@@ -32,15 +32,15 @@ algorithm
   end for;
 
   annotation (Documentation(info="<html>
-<p><i><b>FindMultiExtremum returns a vector containing the n (where n &LT;N) extreme values of the input vector X and their indexes.</b></i></p>
+<p><i><b>FindMultiExtremum returns a vector containing the n (where n &lt;N) extreme values of the input vector X and their indexes.</b></i></p>
 <p><u><b>Hypothesis and equations</b></u></p>
 <p>This function takes as input : </p>
 <ul>
 <li>a vector <i>X</i> made of N real values,</li>
 <li><i>n</i>, the number of extreme values to extract from the vector <i>X</i></li>
 <li>The boolean <i>ascending</i>, to set if extreme values wanted are the smallest ones (=true) or the greatest ones (=false)</li>
 </ul>
-<p>FindMultiExtremum returns a vector <i>Xm</i> contenant les n (où n &LT; N) containing the n (where n &LT; N) extreme values of the input vector <i>X</i> and the vector <i>Indm</i> containing their indexes in the vector <i>X</i>.</p>
+<p>FindMultiExtremum returns a vector <i>Xm</i> contenant les n (où n &lt; N) containing the n (where n &lt; N) extreme values of the input vector <i>X</i> and the vector <i>Indm</i> containing their indexes in the vector <i>X</i>.</p>
 <p><u><b>Bibliography</b></u></p>
 <p>none</p>
 <p><u><b>Instructions for use</b></u></p>
diff --git a/BuildSysPro/Utilities/Math/IntegerExpression.mo b/BuildSysPro/Utilities/Math/IntegerExpression.mo
@@ -40,7 +40,7 @@ block IntegerExpression
 <p><u><b>Bibliography</b></u></p>
 <p>Modification of the Modelica.Blocks.Sources.IntegerExpression model, adding the u input so that the expression of y can depend on another variable.</p>
 <p><u><b>Instructions for use</b></u></p>
-<p>For example, in the y-menu the definition \"if time &LT; 1 then 0 else 1\" can be given in order to define that the output signal is one, if time &ge; 1 and otherwise it is zero.</p>
+<p>For example, in the y-menu the definition \"if time &lt; 1 then 0 else 1\" can be given in order to define that the output signal is one, if time &ge; 1 and otherwise it is zero.</p>
 <p>Note that \"time\" is a built-in variable that is always accessible and represents the \"model time\" and that variable <b>y</b> is both a variable and a connector.</p>
 <p><u><b>Known limits / Use precautions</b></u></p>
 <p>none</p>
diff --git a/BuildSysPro/Utilities/Math/RealExpression.mo b/BuildSysPro/Utilities/Math/RealExpression.mo
@@ -40,7 +40,7 @@ block RealExpression "Set output signal to a time varying Real expression"
 <p><u><b>Bibliography</b></u></p>
 <p>Modification of the Modelica.Blocks.Sources.RealExpression model, adding the u input so that the expression of y can depend on another variable.</p>
 <p><u><b>Instructions for use</b></u></p>
-<p>For example, in the y-menu the definition \"if time &LT; 1 then 0 else 1\" can be given in order to define that the output signal is one, if time &ge; 1 and otherwise it is zero.</p>
+<p>For example, in the y-menu the definition \"if time &lt; 1 then 0 else 1\" can be given in order to define that the output signal is one, if time &ge; 1 and otherwise it is zero.</p>
 <p>Note that \"time\" is a built-in variable that is always accessible and represents the \"model time\" and that Variable <b>y</b> is both a variable and a connector.</p>
 <p><u><b>Known limits / Use precautions</b></u></p>
 <p>none</p>
diff --git a/BuildSysPro/Utilities/Math/f_Pow.mo b/BuildSysPro/Utilities/Math/f_Pow.mo
