Home

Fulltext - LiU E

image

Contents

1. 6 7 7 5 from_dp false A AA wal from_dp true i v E3 a z A a 2 A Li e e fe 0 L 1 2 4 6 8 10 12 14 nRes k Figure 5 Example 2 illustrating computation time for solving mass flow rates through resistances in series phiSat Tin ice a KET m_condens b mCond phi xSat sink duration 1 bou Figure 7 Example 4 illustration proach can also be used when a valve is connected in series to the pressure drop components The valve pa rameter dpFixed_nominal should then be used Figure 6a shows Example 3 where nRes k paral lel instances of a series connection of two resistances are simulated The simulation time for this example is shown in Figure 6b The parameter mergeDp indicates whether the two resistances are merged into one Merg ing the two resistances gives much better results espe cially when combined with from_dp true However when the two resistances are not merged it is better to set from_dp false Model Design for Avoiding Algebraic Loops Devel opers should avoid coupling systems of equations that are only weakly dependent Consider for instance the model of a condensing heat exchanger Such a model contains equations for the pressure drop heat flow rate and water vapour condensation One should try to avoid coupling these equations into one algebraic loop Example 4 in Figure 7 shows a simple condensing hea
2. Statistics 2 3 Time Integration For simplicity we explain the consequences of selecting explicit versus implicit time integration algorithms based on the Euler integration algorithm Let the index i de note the current time step and consider a fixed step size Euler integration method The explicit Euler integration method computes Xil Xi HAt i xi At f ti Xi Yii 10 whereas the implicit Euler integration algorithm com putes Xi 1 Xi At iyi Xi At f ti41 Xi 1 Yi 1 Ui 1 11 Hence for the implicit Euler algorithm if f can not be solved symbolically for x an iterative solu tion is required to obtain x This system of equa tions is large if there are many state variables Solv ing it typically involves the calculation of the Jacobian and requires multiple iterations before convergence is achieved This may lead to more work per time step but it also allows large time steps being taken Also implicit integrators are better suited to solve stiff ODEs The Radau IIa integration is an implicit Runge Kutta method This method is a single step method mean ing that the solution at the current time step is only af fected by information from the previous time step In tegrators such as DASSL Petzold 1982 and Lsodar Petzold 1983 Hindmarsh 1983 are multi step meth ods Dassault Syst mes 2014 Multi step methods use more than one previous value of the integrator s solution t
3. parameter Real b sum a Real c equation der c sin time if efficient then b else sum a end Example5 The corresponding code in dsmodel c is helpvar 0 sin Time F_ 0 helpvar 0 IF DP_ 0O THEN W_ 0 ELSE DP_ 1 DP_ 2 DP_ 3 adding annotation Evaluate true to the defini tion of efficient results in helpvar 0 sin Time F_ 0 helpvar 0 DP_ 0 DP_ 1 DP_ 2 This can be further improved by setting efficient true helpvar 0 sin Time F_ 0 helpvar 0 W_ 1 The new code contains less operations even though the implementation is mathematically identical Taking this into account allows implementing more efficient models DOI 10 3384 ecp1511859 Proceedings of the 11 International Modelica Conference September 21 23 2015 Versailles France 65 Simulation Speed Analysis and Improvements of Modelica Models for Building Energy Simulation Obsolete Model Variables In some cases it may be wise to eliminate model variables Consider for instance variables a b and c where b 2a and c 2b If b is not used in any other equation then it is better to write c 4a and remove b It may be important to analyse the effects of such changes in detail Consider for instance the model of a discretised wall The model consists of a series of tem perature states with an adiabatic boundary condition on one side and a sinusoidal temperature on the other side Typically th
4. It is thus important that models expose these parameters and allow easy configuration The achieved speed increase is considerable How ever this still requires about 18 hours for a one year sim ulation As this is longer than typical building energy simulations we think that further research is desirable to reduce the simulation time further 68 Proceedings of the 11 International Modelica Conference September 21 23 2015 Versailles France DOI 10 3384 ecp1511859 Session 2B Building Energy Applications 1 4 Conclusion We conclude that the analysis of algebraic loops the optimization of Modelica code and the application of physical insight can lead to significant simulation time improvements Analysis of the model time constants avoiding system instabilities using analytic Jacobians and proper integrator choice can also be important These modifications were applied to a large building model where removal of all fast dynamics allowed ex plicit integrators to perform well Fixed step integra tors can also be used if simulation results do not need to be very accurate Euler integration performs very well in terms of computation time allowing detailed of fice building simulations at a speed 500 times faster than real time Further work can focus on analysing and changing the problem structure in such a way that parallelization can be used efficiently It should also be investigated up to which extent model
5. Analysis and Improvements of Modelica Models for Building Energy Simulation Integrator Tolerance CPUtime Dynamics Outside of Function State Time Jacobian Eal step size s section s model s evaluations nfg events events evaluations error Dassl 1 E 6 4261 3538 476 787341 41 8 1235 4 35 E 6 Dassl 1 E 4 3088 2759 327 546326 36 8 862 3 17 E 3 Radau Ia 1 E 6 4042 2400 1416 453073 37 8 347 1 64 E 3 Lsodar 1 E 6 3450 2666 547 679486 44 8 1047 4 35 E 6 Lsodar 1 E 4 2073 1435 515 347018 41 8 537 2 25 E 5 Lsodar 1 E 2 1655 1152 406 256458 38 8 399 4 51 E 3 Dopri45 1 E 6 194 159 17 0 41166 39 8 0 4 68 E 4 Dopri45 1 E 8 199 162 18 3 42017 39 8 0 1 96 E 6 Rkfix4 20s 15 4 11 3 1 1 2717 39 8 NA 1 34 E 2 Rkfix4 5s 50 6 42 9 1 5 10233 43 8 NA 2 52 E3 Rkfix4 ls 224 202 3 2 50211 38 8 NA 1 28 E3 Euler 5s 24 0 18 2 1 7 4271 50 8 NA 2 00 E 3 Euler 0 25 s 446 389 12 8 80233 41 8 NA 4 22 E 4 Table 2 Example building model statistics for various integrators and tolerance options Results are the solution statistics when available else NA and the relative error of Es chronization and communication The authors have not been able to gain notable improvements in simulation speed in building applications by using parallelization in Dymola 2015 FDO1 3 3 2 Example of Large Building Model The approach explained in this paper was applied to a building model based on a real case Solarwind Lux emburg containing 32 IDEAS Baetens et
6. Most likely this change will create larger systems but often these can be simplified using the ap proach explained above DOI 10 3384 ecp1511859 Proceedings of the 11 International Modelica Conference September 21 23 2015 Versailles France 63 Simulation Speed Analysis and Improvements of Modelica Models for Building Energy Simulation o N u from_dp False N O a v v from_dp True v 0 15 5 0 10 A id s 0 05 s d v v v v y 0 00 5 10 15 20 25 30 35 nRes k Figure 4 Example illustrating computation time for solving mass flow rates through parallel resistances Algebraic Loops Iterating on Mass Flow Rates and Pressures When setting allowFlowReversal false the remaining computation time is almost en tirely used for computing the mass flow rates and pres sures We now focus on reducing this computing time further The pressure drop equations in this non linear system can be written either as 7 f Ap or as Ap f m for some function f or its inverse f The value of the parameter res from_dp will pick one or the other for mulation If from_dp false then the system has size 21 22 before and 19 20 after manipulation otherwise it has sizes 21 22 and 1 1 in Dymola OpenModelica This can be explained as follows When from_dp t rue the mass flow rate is calculated as a function of the pressure difference Ap Therefore Ap is chosen as an i
7. computational time However firstly generally nz also grows with problem size for example because larger problems have more controllers that may trigger events If the amount of buildings doubles then the amount of state events may double which causes a performance penalty Secondly when a numeric Jaco bian needs to be computed then nfg will increase since the number of states increases linearly with the prob lem size The number of operations for an implicit in tegrator typically does not scale linearly either Solving dense implicit systems typically requires n opera tions Hairer and Wanner 2002 Building model Ja cobians are however very sparse It is not clear how well this is exploited by Dymola An integrator such as Rkfix4 can have an operation count that is linear with the problem size unless the fixed time step is changed For certain large problems that do not require event han dling it can therefore be advantageous to use these sim ple integrators also because they do not require a Jaco bian to be calculated 3 3 1 Parallelization Dymola supports parallelization for the cal culation of f and g Dassault Syst mes 2014 and analytic Jacobian see Advanced ParallelizeAnalyticJacobian However parallelization generates overhead for syn DOI 10 3384 ecp1511859 Proceedings of the 11 International Modelica Conference 67 September 21 23 2015 Versailles France Simulation Speed
8. flow rate m y is defined by a simplified pressure drop equation describing a pipe as ri k y Ap or equivalently y k uj Equa tions 4 and 5 are then z uz x y cp 6 C O y kVm 7 where cp is the specific heat capacity of water and k is a constant 2 2 Solution of Algebraic System At time f equation 5 needs to be solved for the alge braic variables y Note that g consists of p equa tions 0 g Ideally these can be reformulated using computer algebra and block lower triangulariza tion such that y can be explicitly computed However such a reformulation is not always possi ble In our example the solution is still relatively easy since m can be calculated directly from Ap which is a known input Ap may however be a function of an alge braic variable m for instance if a proportional controller is tracking a set point for the mass flow rate In this case an algebraic loop is created with two equations needing to be solved simultaneously 0 kp n mser dp 8 9 where kp is the proportional gain of the P controller Note that non linear algebraic loops are typically more expen sive to solve than linear systems of equations Dymola will try to manipulate algebraic loops to limit the amount of work required for solving them Information about the sizes of these non linear systems before and after ma nipulation can be found in Dymola in the Translation tab under
9. the Jacobian and the inte grator choice Modelica when performing 100 000 Euler integration steps of Exam ple 6 and Example 7 66 Proceedings of the 11 International Modelica Conference September 21 23 2015 Versailles France DOI 10 3384 ecp1511859 Session 2B Building Energy Applications 1 System Time Constants When a system has fast dy namics then the solver has to track these dynamics with small step sizes In general systems with large time con stants have shorter calculation times It may therefore be advantageous to make certain dynamics slower espe cially the fastest dynamics in the system Dymola option Which states that dominate error may be used to iden tify these states Changing the dynamics may however be non physical or introduce instability in feedback control loops In this case a different option may be to remove the fast dynamics completely and simulate the system as a steady state system Note however that this may in crease the size of the algebraic system of equations The latter approach may be very effective when considering air flow networks If air is modelled as compressible pressure states are created in in stances of MixingVolume unless massDynamics SteadyState These states however introduce small time constants if part of a building air flow network It may therefore be better to remove them Again this may create larger systems of equations System Stability If a fee
10. x u 0 1 with initial conditions x 0 xo where F 0 1 x R x R x R gt R for some n m N t is time x is the vector of state variables and u are inputs For simplicity we omit discrete variables in this discussion Often the equations can be manipulated analytically such that this system of equations can be expressed as an explicit ODE of the form F t x u 2 For example if a heat capacitor with capacitance C is coupled to a fixed temperature boundary condition u through a thermal resistor R then 2 becomes u x RC x 3 However if the system of ODE is coupled to algebraic equations as is common in building simulation such a formulation is often not possible In this case the problem is defined by a system of Differential Algebraic Equations DAE of the form 4 5 f t x y u 0 g t x y u with initial conditions x 0 x where y R for some p N are algebraic variables Under certain smoothness assumptions and by use of the Implicit Function Theo rem one can show existence of a unique solution to 4 and 5 Polak 1997 Coddington and Levinson 1955 This DAE can be solved by first solving 5 for y and then using y to compute x For example consider a per fectly mixed volume with thermal capacity C and a pump that provides a constant pressure head Ap u1 Suppose that the pump provides water to the mixing volume with temperature u2 and that the water mass
11. Simulation Speed Analysis and Improvements of Modelica Models for Building Energy Simulation Filip Jorissen Michael Wetter2 Lieve Helsen Mechanical Engineering KU Leuven Leuven Belgium filip jorissen lieve helsen kuleuven be Energy Technologies Area Lawrence Berkeley National Laboratory Berkeley CA USA mwetter 1lbl gov 3EnergyVille Waterschei Belgium Abstract This paper presents an approach for speeding up Model ica models Insight is provided into how Modelica mod els are solved and what determines the tool s computa tional speed Aspects such as algebraic loops code ef ficiency and integrator choice are discussed This is il lustrated using simple building simulation examples and Dymola The generality of the work is in some cases verified using OpenModelica Using this approach a medium sized office building including building enve lope heating ventilation and air conditioning HVAC systems and control strategy can be simulated at a speed five hundred times faster than real time Keywords Modelica speed performance buildings 1 Introduction The Modelica language allows simulations of multidis ciplinary problems Combining multiple disciplines can lead to models that quickly grow in size and complexity Consider for instance building energy modelling where building envelope heating ventilation and air condi tioning HVAC systems and controls are integrated in a single model The buildin
12. acques Roux and Monika Woloszyn editors Proc of the 13 th IBPSA Conference pages 3505 3512 2013 URL http simulationresearch 1bl gov wetter download 2013 IBPSA Wetter pdf Michael Wetter Wangda Zuo Thierry S Nouidui and Xiufeng Pang Modelica buildings library Journal of Building Per formance Simulation 7 4 253 270 2014 Michael Wetter Marcus Fuchs Pavel Grozman Lieve Helsen Filip Jorissen Moritz Lauster Dirk Miiller Christoph Nytsch Geusen Damien Picard Per Sahlin and Matthis Thorade IEA EBC annex 60 modelica library an inter national collaboration to develop a free open source model library for buildings and community energy systems In Building simulation 2015 submitted Hyderabad 2015 Dirk Zimmer Using Artificial States in Modeling Dynamic Systems Turning Malpractice into Good Practice In Pro ceedings of the 5th International Workshop on Equation Based Object Oriented Modeling Languages and Tools pages 77 85 2013 DOI 10 3384 ecp1511859 Proceedings of the 11 International Modelica Conference 69 September 21 23 2015 Versailles France
13. al KOS T tow bou hea Figure 1 Example 1 illustration flow_in m0 m_flow_nominal mm pump res computing time can be reduced These values can be estimated from the Dymola simulation output Setting Advanced GenerateBlockTimers true in Dy mola generates the required output The parameter n fg in 12 equals the last column of the block timers The value of trg equals the sum of column Mean of rows OutputSection and DynamicsSection Row Outside of model contains the overhead of the integrator and possibly other overhead as well nint equals the Number of succesful steps ndata is determined by the settings in the General and Output tabs of the simulation settings Decreasing any of these factors will result in a lower simulation time However it is not always clear how this should be achieved A measure for decreasing one fac tor may also cause an increase in another The following sections provide more insight into how to influence these different factors Firstly the overhead for each function evaluation t is discussed Secondly the number of eval uations nf is discussed Whenever possible example models are provided based on the Annex 60 library Fi nally a methodology is proposed for increasing the sim ulation speed of large building models 3 1 Overhead per Evaluation Evaluation of f and g involves the evalua
14. al 2015 building zones with individual concrete core activation circuits Baetens et al 2015 and Variable Air Vol ume VAV boxes including heating battery bore field model Picard and Helsen 2014 solar collector Wet ter et al 2014 four thermal storage devices Wetter et al 2014 one pellet boiler four heat pumps Baetens et al 2015 two adiabatic active heat recuperating air handling units pumps Wetter 2013 and valves Wet ter et al 2015 and a control strategy based mostly on hysteresis controllers PID controllers heating cooling curves and boolean algebra The model has 2468 con tinuous time states and 28342 time varying variables Special care was taken to make sure that the small est time constants are in the order of 30 s Therefore air ducts are steady state pumps and valves have no open ing delay or filter and pipes were lumped into only a few states per circuit branch thereby allowing to increase the time constant Temperature sensors are assumed to have a time constant in the order of one minute Using dynamic sensors avoids coupling the thermal equations with the control equations into a single algebraic loop This model was simulated for tend tstart 10 000 s using various implicit integrators with numeric Jaco bians and explicit integrator Dopri45 The total amount of function evaluations exceeds 40 000 in each case This is on average one function evaluation every 0 25 s while the smallest
15. bles leads to significantly more function evaluations probably be cause by default Dymola computes a numerical approx imation to the Jacobian based on numeric differentiation Due to the performance penalty for approximating the Jacobian the simulations are repeated using an an alytic Jacobian which can be done in Dymola by setting Advanced GenerateAnalyticJacobian true In OpenModelica an option for this exists in the simula tion setup Results are shown in Figure 3b and in Ta ble 1 The penalty for adding new states is almost com pletely removed when using an analytic Jacobian Some how the average execution time for the dynamics sec tion increased slightly even though the equations did not change The reason for this is unclear The results indi cate that the analytic Jacobians should be used whenever possible especially for models with a large amount of states From this analysis we conclude that the user should be cautious when adding states for decou pling algebraic loops If they are added setting Advanced GenerateAnalyticJacobian true may reduce computing time An alternative approach is to use physical insight to simplify the equations where possi ble in a way similar to setting al lowF lowReversal false Also it may be beneficial to remove the states that are added by default in three way valves and other components containing mixing volumes This can be done by setting energyDynamics massDynamics SteadyState
16. dback control loop is tuned badly oscillatory behaviour can occur A variable time step integrator may track these oscillations leading to a major decrease in simulation speed Note that it may be difficult to see these oscillations when the output interval is set too large Number of Events Events require the integration to stop and restart typically with a lower order method and with smaller time steps In addition for state events typ ical ODE solvers require an iterative solution to find the time when the event happens Computing the Jacobian Some integrators require the Jacobian to be calculated Having more states leads to a larger Jacobian as was illustrated in Example 1 Since by default Dymola and OpenModelica use numeric dif ferentiation to approximate the Jacobian a lot of finite differences need to be calculated each requiring a func tion evaluation Note that in particular models with a larger number of states benefit more from having an an alytic Jacobian since the number of Jacobian entries equals the square of the number of states Integrator Choice Many integrators use an implicit integration scheme This typically requires the compu tation of a Jacobian and requires iterations to be per formed before reaching convergence This can lead to more function evaluations However for stiff systems implicit integrators are more efficient than explicit inte grators 3 3 Analysis of Large Problems In the previo
17. em Simulation Springer US 2006 Earl A Coddington and Norman Levinson Theory of ordinary differential equations McGraw Hill Book Company Inc New York Toronto London 1955 Dassault Systemes Dymola user manual vol 1 2014 Ernst Hairer and Gerhard Wanner Solving Ordinary Differen tial Equations IT Stiff and Differential Algebraic Problems Springer Verlag Berlin Heidelberg 2002 Alan C Hindmarsh Odepack a systematized collection of ode solvers IMACS transactions on scientific computation 1 55 64 1983 Linda R Petzold Description of dassl a differential algebraic system solver Technical report Sandia National Labs Liv ermore CA USA 1982 Linda R Petzold Automatic selection of methods for solving stiff and nonstiff systems of ordinary differential equations SIAM journal on scientific and statistical computing 4 1 136 148 1983 Damien Picard and Lieve Helsen Advanced Hybrid Model for Borefield Heat Exchanger Performance Evaluation an Im plementation in Modelica In 0th International Modelica Conference 2014 pages 857 866 Lund 2014 Elijah Polak Optimization Algorithms and Consistent Ap proximations volume 124 of Applied Mathematical Sci ences Springer Verlag 1997 Michael Tiller Introduction to Physical Modeling with Mod elica Springer US 2001 Michael Wetter Fan and pump model that has a unique solu tion for any pressure boundary condition and control signal In Jean J
18. ful Jacobian Function Continuous Mean time Total time steps evaluations evaluations nfg time states dynamics sec us dynamics sec s N Initial model 55 21 647 310 0 200 N Enthalpy state 54 20 1448 22 103 0 150 N No flow reversal 55 21 647 2 109 0 071 A Enthalpy state 54 20 547 22 137 0 075 A No flow reversal 55 20 557 2 116 0 065 Table 1 Solver output for 3 configurations of Example 1 Figure 1 with nRes k 20 and analytic A or numeric N Jacobian 1 0 7 7 T s y v initial model v 4 4 enthalpy state 2 0 6 allowFlowReversal False I ai 5 0 4 z x 0 2 x e 2 i o o LE kd 3 1 5 10 15 20 25 30 35 nRes k a numeric Jacobian 1 0 7 T y v initial model A A enthalpy state a lt a g 0 6 allowFlowReversal False v a 04 v 9 0 2 y 4 o oola 3 g 5 10 15 20 25 30 35 nRes k b analytic Jacobian Figure 3 Simulation time for three variants of Example 1 known values of state variables This causes the equa tions to be solved explicitly OpenModelica does not make this simplification and consequently the algebraic loop size remains unchanged A different approach can be taken to break algebraic loops without relying on the solver to make simplifica tions Many fluid components contain equations such as port_a h_outflow port_b h_outflow inStream port_b h_outflow inStream port_a h_outflow w
19. g envelope s thermal response typically has relatively slow dynamics and heat transfer can be modelled using mostly linear equations Building HVAC systems however contain a lot of non linearities performance curves and performance tables and typi cally have faster dynamics Building control contains less dynamic components but contains a lot of discrete variables Simulation of these types of systems can become very time consuming limiting the use of these models Current literature does not provide a lot of insight into what determines computational speed and what Model ica users and library developers can do to speed up mod els Chapter 14 of Tiller 2001 provides some hints on ways to improve computational performance such as us ing equations instead of algorithms avoiding events pro viding Jacobians of functions selecting good solvers and tolerances and eliminating intermediate variables The Dymola manual section 5 7 suggests to limit overhead for writing results and to avoid chattering and to use op tions such as inline integration and parallelization Das sault Syst mes 2014 While the provided tips can be valuable they are still high level and often do not provide a lot of insight and consequently can be difficult to apply in practice Also a lot of potential for code optimization remains untouched This paper provides insight in approaches to increase computational performance of models specifically tar
20. geted at Modelica users and Modelica library developers Related research focuses on creating efficient solvers such as Quantized State System QSS solvers using fast Jacobian evaluation techniques and using efficient paral lelization strategies These methods can be useful and complementary but are outside of the scope of this work Firstly some technical background about Modelica is given to allow easier interpretation of the discus sion Secondly relatively small examples are used to demonstrate how Modelica code and models can be im proved in Dymola and OpenModelica These examples are based on the IEA EBC Annex 60 Modelica library Wetter et al 2015 and are available online Finally the code improvements are applied to a large building model demonstrating the potential of Modelica in con junction with the solvers available in Dymola 2015 FDO1 for whole building simulations 2 Technical Background The goal of this section is to provide the technical background required for understanding the analysis per formed in this paper 2 1 Governing Equations A typical Modelica model can be mathematically ex pressed as an implicit system of Ordinary Differential DOI 10 3384 ecp1511859 Proceedings of the 11 International Modelica Conference 59 September 21 23 2015 Versailles France Simulation Speed Analysis and Improvements of Modelica Models for Building Energy Simulation Equations ODE of the form F t
21. hich may be simplified into if allowFlowReversal then inStream port_b h_out flow else Medium h_default inStream port_a h_outflow port_a h_outflow port_b h_outflow because the value of port_a h_outflow should never be required for calculations upstream of port_a Therefore it does not matter what its value is Choosing a fixed value has the advantage that it allows breaking algebraic loops Note that when the flow does reverse the model equations will be wrong which may cause unstable dynamics Figure 3a shows the influence of these two measures on the simulation time Adding enthalpy states only re duced the computing time for nRes k gt 20 However setting allowFlowReversal false led to faster sim ulations Note that the speed increase for the first case depends on the time constants of the new states Larger time constants in general lead to faster simulations but may introduce non physical dynamics The first three rows of Table 1 allow analysing the re sults in further detail Both measures allow reducing the computational work for each evaluation of f and g in the dynamics section from 310 Us to 106 us The overall speed when using allowFlowReversal false is however better due to the lower number of function evaluations that is required 647 instead of 1448 The increased number of function evaluations is caused by the increased number of states in the model It turns out that the higher number of state varia
22. ion then this means that the same calculation is repeated multiple times This is not necessarily a problem if the overhead is small However in the case of a window model the compu tation involves a lot of trigonometrical calculations and it would be better to isolate this calculation in a sepa rate model An example implementation of this problem can be found in the IDEAS library Baetens et al 2015 However putting the solar irradiation in a separate model requires the user to keep the radiation computation con sistent among multiple models An illustration of common subexpression elimination is given by Example 8 model Examples Real a sin time 1 Real b sin time 1 end Examples The Dymola C code evaluates the sine and addition only once w_ 0 W_ 1 sin Time 1 W_ 0 This simplification is not made in OpenModelica since it evaluates the sin function once for a and once for b Still more complicated common subexpressions such as in IDEAS are not detected by both tools Therefore improving the common subexpression elimination would allow further performance improvements 3 2 Number of Evaluations The previous section focussed on how to reduce the com putational overhead for each evaluation of f and g The current section focusses on how to re duce the number of evaluations Important aspects are the time constants of the system the system stability the number of events computing
23. is will be modelled using thermal capaci tances C and thermal resistors R A Modelica implemen tation could be as presented by Example 6 model Example6 parameter Integer nTem 500 parameter Real R 0 001 parameter Real C 1000 Real nTem T Real nTem 1 Q_flow equation Q_flow 1 273 15 sin time T 1 R der T 1 Q flow 1 Q_flow 2 C for i in 2 nTem loop Q_flow i T i 1 T i R der T i Q_flow i Q_flow it 1 C end for Q_ flow nTemt 1 0 end Example6 In this model variables Q_ 1ow are calculated but not necessarily needed These variables can be eliminated as illustrated in Example 7 model Example7 parameter Integer nTem 500 parameter Real R 0 001 parameter Real C 1000 parameter Real tauInv Real nTem T equation der T 1 xtaulnv for iin 2 nTem 1 loop der T i T i 1 2 T i T i 1 tauInv end for der T nTem end Example7 1 RxC 273 15 sin time 2 T 1 T 2 T nTem 1 T nTem tauInv Comparing Example 7 to Example 6 a variable has been eliminated but the number of operations within the for loop remains the same In particular there are two ad ditions and two divisions in Example 6 and two ad ditions and two multiplications in Example 7 How ever Example 7 is 83 faster in Dymola 2 83 s 0 49 s and OpenModelica 9 2 s gt 1 6 s It turns out that this is mostly because a division gener ates more overhead than a multi
24. nerates the following algebraic loops 6 1 Based on the C code generated by OpenModelica the following algebraic loops are generated 21 19 46 22 Sizes nonlinear systems of equations Sizes after manipulation 7 1 In Dymola these algebraic loops can be analysed us ing the dsmodel mof file The first system solves for the mass flow rate in the left part of the fluid loop The second system solves for the mass flow rate in the right part of the fluid loop The third system solves for the en thalpies of the components in the right part of the fluid loop Dymola s BlockTimers generate the following output for the system dynamics 41 20 47 23 Sizes nonlinear systems of equations Sizes after manipulation Name of block Block CPU s DynamicsSection 14 0 200 Dynamics 2 eq 15 0 000 Dynamics code 16 0 000 Nonlin sys l1 17 0 007 Dynamics code 18 0 000 Dynamics 20 eq 19 0 066 Dynamics code 207 0 002 Nonlin sys 22 21y 0122 Dynamics code 22 0 001 Blocks 17 19 and 21 clearly dominate the computa tional cost of this example The Dymola file dsmodel c shows that these block numbers correspond to the three non linear systems We explain how these systems can be simplified or removed The third system is created because there are no enthalpy states in the right circuit except in the pump In general the fluid can flow in both directions Therefore the inlet and o
25. o approximate the new solution For a more detailed discussion on integrators we refer to Cellier and Kofman 2006 and Hairer and Wanner 2002 60 Proceedings of the 11 International Modelica Conference September 21 23 2015 Versailles France DOI 10 3384 ecp1511859 Session 2B Building Energy Applications 1 2 4 Simulation Procedure The simulation of a Modelica model typically proceeds as follows First the state variables are initialized based on the initial equations and start values Then continu ous time integration starts and results are saved at inter mediate time intervals At certain points in time time or state events may occur which need to be handled by the integrator The equations f and g that are solved can be found in the Dymola output file dsmodel mof in the working directory Output of this file can be enabled in the Translation tab Note that no distinction between equations of f and g is made in this file The file may contain different sec tions that determine when the contained code is exe cuted such as the Initial section Output section Dynam ics section Accepted section and Conditionally accepted section A description of these sections can be found in Dassault Systemes 2014 Using dsmodel mof and also the C code in dsmodel c can be important for de bugging model stability and performance 3 Analysis of Computational Over head This section builds
26. on such that algebraic loops can be simpli fied Setting in Dymola the option Evaluate true may also cause analytical solutions to be found especially for linear algebraic loops However this leads to parameter values to be evaluated during translation and hence they can no longer be changed without translating the model again These examples illustrate that even using existing component models can be a challenge Ideally this level of complexity is not exposed to the end user A possi ble approach to do this is to construct often used base circuits that are preconfigured in an efficient way 3 1 2 Overhead Due to Inefficient Code In general every implemented equation will be evalu ated Simulation tools are able to perform certain code simplifications such as common subexpression evalua tion and detection of alias variables but the level of op timization is not exhaustive Therefore the developer should be aware of how the solver treats equations Here we illustrate some important aspects Inlining functions Inlining functions may allow bet ter symbolic processing It can also lower the func tion evaluation time probably because overhead for call ing a C function is avoided We recommend to set Inline true by default for all functions unless their body is large Model Parameters code listing below Consider Example 5 shown in the model Example5 parameter Boolean efficient false parameter Real 3 a 1 3
27. plication probably be cause of guarding against division by zero This perfor mance penalty can be reduced significantly by adding annotation Evaluate true to parameters R and C or by creating a dummy parameter similar to tauInv and by multiplying with this parameter This reduces simulation time to 0 65 s gt 0 49 s in Dymola and 2 39 s gt 1 6 s in OpenModelica The reason for the remaining These CPU times are based on the total Dynamics section time in Dymola and the simulation timer in the Statistics output of Open performance difference is unclear but may be explained by the extra variables Q_ flow which may generate over head From this analysis we conclude that there exists unex ploited code optimization potential in popular Modelica tools Certain variables can be eliminated and dummy parameters can be introduced to avoid parameter divi sions during each time step Until these issues are re solved users can avoid performance penalties by taking into account these limitations by reformulating models Duplicate Code The developer should avoid making models that generate duplicate code A good example is a window model which requires the solar irradiance to be calculated Since this calculation is influenced by pa rameters such as the window orientation and inclination angle the developer may choose to include these equa tions in the window model If multiple windows have the same orientation and inclinat
28. rallel instancs of a series connection of two resistances and b simulation time based on two parameters mergeDp and from_dp mass flow rate heat flow rate and moisture balance are coupled into a single system of 12 10 non linear equa tions before manipulation in Dymola OpenModelica As a simplification one could argue that the impact of the water vapour mass flow rate on the pressure drop is very small and that it could therefore be removed from the mass conservation equation ma 0 This physi cal approximation decouples the algebraic loop so that in both simulation tools the equations can be solved se quentially We conclude from this discussion that the developer should consider to approximate equations if such approximations allow decoupling large systems of equations while maintaining the accuracy required by the application In some cases analytical solutions to nonlinear sys tem of equations may exist Especially linear system of equations can often be solved analytically To en able this the solver needs to be able to establish whether a system is linear When using a Modelica function in a system of equations it is therefore important that annotation Inline true is used When using this annotation the model developer suggests to the symbolic processor to substitute the function call with the body of the Modelica function thereby allowing the symbolic processor to detect the linearity This allows symbolic manipulati
29. s can be made faster by changing the model dynamics which allows larger time steps to be taken without introducing too large errors The pro posed changes demonstrate that further symbolic pro cessing in Dymola and OpenModelica is possible We also propose to use analytic Jacobians by default for all Jacobian elements where an analytic Jacobian can be computed 5 Acknowledgements The authors acknowledge the financial support by the Agency for Innovation by Science and Technology in Flanders IWT for the PhD work of F Jorissen contract number 131012 This research was supported by the Assistant Secre tary for Energy Efficiency and Renewable Energy Of fice of Building Technologies of the U S Department of Energy under Contract No DE AC02 05CH11231 This work emerged from the Annex 60 project an international project conducted under the umbrella of the International Energy Agency IEA within the En ergy in Buildings and Communities EBC Programme Annex 60 will develop and demonstrate new generation computational tools for building and community energy systems based on Modelica Functional Mockup Inter face and BIM standards References Ruben Baetens Roel De Coninck Filip Jorissen Damien Pi card Lieve Helsen and Dirk Saelens Openideas an open framework for integrated district energy simulations In Building simulation 2015 submitted Hyderabad 2015 Fran ois E Cellier and Ernesto Kofman Continuous Syst
30. t exchanger model Along the flow path first air cools in the heat exchanger hex then condensate is extracted from the stream in vol steady state and finally the re maining mass is sent through a pressure drop component Ideally the solver would be able to first compute the mass flow rate based on the pressure drop characteristic Using this mass flow rate the heat flow rate can be computed since it only depends on inlet temperatures and mass flow rates Finally moisture can be extracted such that the air stream becomes saturated In practice this sequential cal culation is not possible because removing water vapour from the air affects its mass flow rate and therefore also the pressure drop As a consequence the equations for the 64 Proceedings of the 11 International Modelica Conference September 21 23 2015 Versailles France DOI 10 3384 ecp1511859 Session 2B Building Energy Applications 1 pulse period 1 CPUtime s p res pump res1 mergeDp from_dp nRes 2 4 Le 0 true true k 6 a x mergeDp true from_dp false mergeDp false from_dp false Fe A A A mergeDp true from_dp true A mergeDp false from_dp true e e 7 e J e e e H A A 4 A A 2 4 6 8 10 12 14 nRes k b Figure 6 Example 3 a illustration for solving mass flow rates through pa
31. teration variable The symbolic processing algorithm detects that all resistances are in parallel and hence must have the same pressure drop Therefore they can all use the same iteration variable leading to a much smaller system This leads to a significant speed improvement as shown in Figure 4 Example 1 uses a pump which sets the mass flow rate to an input value and which is connected to nRes k par allel pressure drop components The solver can exploit the system structure by selecting the common pressure drop as an iteration variable The dual problem Ex ample 2 could be to consider a pump which takes the pressure drop as an input value and which is connected to nRes k pressure drop components connected in series In this case it is advantageous to set from_dp false since Dymola and OpenModelica then select the com mon mass flow rate as the iteration variable as illustrated in Figure 5 These were fairly simple problems In practice com binations of parallel and series connections are used making the choice of the parameter from_dp difficult However it is often possible to aggregate multiple pres sure drop components that are connected in series If all components have the same nominal mass flow rate m_flow_nominal then the nominal pressure drops dp_ nominal can be added into one component reducing the series branch into a single pressure drop equation Otherwise dp_nominal needs to be rescaled This ap
32. time constant of the system is 30 s There fore it makes sense to use an explicit fixed step integra tor Table 2 shows the results including fixed step ex Euler Rkfix4 Dopri45 dassl Lsodar Radau CPUtime s lt gt HE O lt gt H 3 107 10 10 10 Relative error Eel 10 10 Figure 8 Relative errors of E for various solvers and toler ances or fixed time step sizes plicit integrators Rkfix4 and Euler It contains statis tics and the error on one simulation result that is of inter est namely the integrated electrical power consumption of the building E The relative error was calculated us ing Dassl with a tolerance of 1078 which produced a result of 4 591880 kWh From these results and Figure 8 it is clear that implicit integrators are very slow compared to explicit integrators for this problem Fixed step methods are especially fast when high accuracy is not required allowing a simula tion speed 500 times faster than real time which is more than 100 times faster than Dassl For higher accuracies Dopri45 can be used Lsodar is the fastest implicit inte grator that was tested Note that the simulation can easily be made faster by using a larger step size at the cost of accuracy Also using larger step sizes will eventually lead to numerical instabilities The user may therefore want to adjust the dynamics of the system or set certain dynamics to steady state
33. tion of sequential code algorithms linear and non linear algebraic loops etc We discuss how the overhead for this code can be reduced 3 1 1 Algebraic Loops When multiple equations are interdependent an alge braic loop is formed Depending on the type of equa tions the algebraic loop can be linear or non linear Solv ing non linear algebraic loops requires iterative solutions such as encountered in a Newton Raphson algorithm and is therefore more expensive The user should therefore try to simplify or remove these systems where possible We present some examples that demonstrate how this can be approached DOI 10 3384 ecp1511859 Proceedings of the 11 International Modelica Conference 61 September 21 23 2015 Versailles France Simulation Speed Analysis and Improvements of Modelica Models for Building Energy Simulation Algebraic Loops Iterating on Enthalpy Consider Example 1 shown in Figure 1 The presented hydraulic system contains a heater a three way valve and a pump setting the mass flow rate The pump is connected to nRes k parallel pressure drop components res The only two states are the temperatures of the heater and the pump with a time constant of 10 and 1 seconds re spectively A pulsed signal sets the mass flow rate of the pump and the outlet temperature of the heater The valve opening is set to 50 The results are generated for nRes k 20 unless stated otherwise For the given configuration Dymola ge
34. ulation and from 22 23 to 1 3 after the manipulation for Dymola OpenModelica regardless of the value of nRes k Note that adding states also changes the simulation results In this example a second approach is possible We know that the fluid will always flow from the pump into the resistance Therefore the inflow enthalpy of the resis tances is always equal to the enthalpy leaving the pump This knowledge can be passed on to the model by setting allowFlowReversal false in the components where no flow reversal occurs This causes the min and max at tributes of the m_flow variable of the fluid ports to be set to zero Dymola utilizes this and simplifies equations such as H_out semiLinear port_a m_flow inStream port_a h_outflow port_a h_outflow into H_out port_a m_flow inStream port_a h_outflow or H_out port_a m_flow port_a h_outflow It can conduct this simplification because the solver can now take into account that the mass flow rate will never become negative or positive Due to the simplified structure of the problem the solver is able to sort the enthalpy equations in such a way that no algebraic loop is formed the solver can evaluate the equations se quentially following the fluid downstream starting from 62 Proceedings of the 11 International Modelica Conference September 21 23 2015 Versailles France DOI 10 3384 ecp1511859 Session 2B Building Energy Applications 1 Succes
35. upon the basic simulation pro cedure detailed above to provide further insight into reduction in computing time using illustrative examples All numbered examples are available at https github com iea annex60 modelica annex60 commit e9e247d in the Modelica package Fluid Examples Performance Presented results are based on Dymola 2015 FDO1 and OpenModelica 1 9 3 dev 125881 installed on Ubuntu 14 04 64 bit running on a virtual machine Paral lels 9 0 24251 on OS X Yosemite Since the authors are most familiar with Dymola all analyses are performed using Dymola unless stated otherwise A selection of results have been verified using OpenModelica to test their generality Models that could not be compiled by OpenModelica were not verified The CPU time required for performing a simulation can be approximated by t O tinit Nfg tfg Nint tint ndata taata 12 where are the computation times of different steps n are the number of times these steps are evaluated and finit is the time required to solve the initialization problem The indices fg int data refer respectively to the evaluation of functions f and g the overhead for the integrator and the data storage The total computational overhead can be reduced by addressing any of these components Knowing their values provides an important hint for where allowFlowReversal pulse gain period 1001 k r_flow_nomin
36. us sections computing time was analysed using small models In building simulation models can however become considerably larger and analysing the computational speed can be difficult since it depends on a lot of factors including the unknown solver implemen tation Still we predict some trends for the computation time based on the size of the model Consider a model of a district energy system includ ing building models and an electrical grid When dou bling the size of the district ideally the computational time would double as well such that computational time scales linearly with problem size Let us analyse this further based on Equation 12 Ideally tr scales linearly with the problem size In practice this is not necessar ily the case The electrical grid of the district typically results in a large non linear system of equations since all electrical components have very fast transients and are therefore modelled as steady state components Dou bling the size of the model therefore also doubles the size of the algebraic loop Example 1 has shown that compu tational time for algebraic loops does not scale linearly with size and therefore larger models will become com putationally slow Equations outside algebraic loops can be solved sequentially Therefore their computational time does scale linearly Because tg scales at best linearly with size nf should remain constant if we want to obtain overall lin ear scaling of the
37. utlet enthalpies of all res components can be a function of all other res components depending on the flow direction This causes an algebraic loop since all enthalpy values depend on each other heatCapacitor c fixedTemperature thermalConductor thermalConductor1 G 1 req z 100 T 273 15 Figure 2 Example generating linear system of 2 equations cos prescribedTemperature G 1 A common approach for decoupling algebraic loops is adding additional states Zimmer 2013 However this can introduce fast dynamics necessitating short time steps during parts of the simulation The values of the state variables are solved by the integration algorithm and hence they reduce the size of the algebraic loops A simple example is shown in Figure 2 where a system of two linear equations is generated when the heat capacitor is unconnected This system is decoupled when a heat capacitor is added since the temperatures at the ports connecting the two conductances are then equal to the state variable of this heat capacitor and need no longer be obtained by solving an algebraic loop The enthalpy calculation of Example 1 can be simplified in a similar way by adding nRes k mixing volumes at the location of the blue dot in Figure 1 introducing a state in the flow path with a time constant for the enthalpy of 10 s The state values for the enthalpy cause the system to become decoupled The system size is now reduced from 46 47 to 4 7 before the manip

Download Pdf Manuals

image

Related Search

Related Contents

HP ENWW User guide  Über O&O SafeErase    Netgear AirCard 595 (all others) User Guide  - A.J.Pinto  MANUALE D`USO - Autorita` portuale di Gioia Tauro  Instruction Manual  presentation  Manual Sopradores com recolhedor 2T v13  Vutec EVMW6080D  

Copyright © All rights reserved.
Failed to retrieve file