Comparison with Domain Specific Tools

Chapter 5. The ThermoFluid Library

water supply for space applications, fuel cells have not yet reached a de-velopment status which allows them to be used in every-day applications.

TheThermoFluid-library has been used at United Technologies Research Center, Hartford, CT, to develop dynamic models of fuel cells including the complex fuel reforming unit. The reformer transforms hydrocarbons like natural gas or even gasoline to hydrogen and other byproducts. The hydrogen is used in the fuel cell to generate electric power.

TheThermoFluidlibrary was not designed with fuel cells as a prospec-tive application, but as a base library it offered models for most of the phenomena which are relevant for fuel cell modeling. The combination of the Modelica language, ThermoFluid-library and Dymola simulation envi-ronment was evaluated against a range of other possible modeling tools and techniques and was found to best fulfill all requirements of a flexible base to develop models for a range of different fuel cell products currently under development. The models are used both by members of the research department who develop the models of subsystems and libraries and by engineers at UTC Fuel Cells for development work. The fuel cell system models are the most complex systems built so far based on the basis of ThermoFluid. The models are also used for hardware-in-the-loop investi-gations of control system performance.

5.11 Comparison with Domain Specific Tools seamlessly. Because most of these tools emerged independently and were integrated later on, the work flow and data consistency across different tools is much less integrated than software vendors pretend.

The comparison is meant to point out the main features of similar tools and their differences. A thorough comparison of all the differences would require more space than given.

gPROMS and ABACUSS II

The acronym gPROMS stands for general PRocess Modeling System. This program consists of an equation based modeling language and environ-ments for simulation and optimization. It was originally developed at the Department of Chemical Engineering at the Imperial College of Science, Technology and Medicine in London. Later, it was commercialized in the spin-off company PSE Ltd, Process Systems Engineering. ABACUSS II is derived from the original gPROMS code with some extensions by one of the developers of gPROMS. It is still an academic code used for research, mainly in the area of dynamic optimization of large, combined continuous and discrete differential-algebraic equation systems.

ABACUSS II and gPROMS are the only simulation environments in this comparison which are based on a declarative modeling language with equations. Some properties of simulation environments are closely tied to the existence of a high-level, abstract model description format that allows symbolic manipulation of the model before execution.

The following discussion will distinguish between a comparison of lan-guage features and other features concerning the simulation environment.

Table 5.3 summarizes the important language features of gPROMS and Modelica. Most of the differences can be attributed to the different goals of the languages: Modelica was designed as a general purpose multi-domain language and gPROMS was designed primarily for chemical pro-cess engineering systems. Other important properties for library design can not be compared on the language level: Dymola’s Modelica implemen-tation handles high index problems by automatic index reduction. This is not the case in gPROMS, but would be possible, as demonstrated by the ABACUSS II implementation of the same language. The original ver-sion of gPROMS described in[Barton, 1992] had a keyword INHERIT and single inheritance as an object-oriented feature. However, no references to the keyword or the concept occur in recently published material about gPROMS. Both ABACUSS and gPROMS do not generate code from the equations, but instead they build up a data-structure in computer memory which is evaluated when simulating. This results in faster turn-around times in model change and test cycles, but leads to somewhat longer simu-lation times. Since gPROMS is interpreted, execution is slow and memory requirements for the interpreter are high. Both properties are a severe

Chapter 5. The ThermoFluid Library

drawback for hardware-in-the-loop simulations.

The first modeling language to include a notation for partial differ-ential equations in the language was gPROMS. The PDE language ex-tensions to gPROMS, the types of discretization schemes, geometries and boundary condition specifications which are currently implemented are presented in[Oh, 1995]. Integration of language constructs for partial dif-ferential equations is still under development in Modelica, see[Saldamli et al., 2002].

ABACUSS II uses almost the same language as gPROMS, but the key-word SENSITIVITY was added to tag the variables whose sensitivities have to be calculated. ABACUSS II makes it also possible to use exter-nal FORTRAN routines. Automatic differentiation techniques are used to make external routines behave as similar to equations as possible.

Extending from its original purpose, gPROMS has become part of a suite of tools for modeling, simulation, identification and optimization of chemical engineering processes. Currently, a graphical user interface for the system topology is added to the originally text-based modeling

envi-feature Modelica gPROMS

Equations true equations true equations Connections equations generated

by connect-statements, using zero-sum equa-tions for flow variables

connections of streams, all variables use equal-ity assignment at the connect.

Partial differential equation support

no yes, but only for

sim-ple geometries: cylinder and cube.

Hybrid models yes yes

Object Orientation yes no

High-level model parameterization

yes no

Graphical layout is part of language

yes no

Table 5.3 Comparison of language features between gPROMS and Modelica. The ABACUSS II language is almost identical to the gPROMS language.

5.11 Comparison with Domain Specific Tools ronment. This is a difficult task because the graphical representation is not integrated with the modeling language.

ABACUSS II uses other numerical solvers than gPROMS. The solver-collection is called DAEPACK and offers particular features for paramet-ric sensitivity analysis and detection of discontinuities, see [Tolsma and Barton, 1999] and [Tolsma and Barton, 2002]. No graphical modeling en-vironment is currently available. ABACUSS II is one of the few tools that integrate automatic differentiation techniques for FORTRAN with the modeling tool. This is useful in process engineering simulation where it is common to include legacy FORTRAN codes for parts of the problem.

Many optimization techniques require differentiation of the model and the focus of ABACUSS II on dynamic optimization makes the automatic generation of derivatives a valuable asset.

APROS

APROS is a commercial, closed source simulation tool for simulation of power plants developed by VTT Finland, see[Juslin, 1995]. Large system providers for power plants also have in-house simulators for these plants which are used both for process development and for operator training.

APROS is a well known vendor-independent full scale power plant simu-lator.

APROS has a broad selection of validated models for standard power plant configurations. Due to its closed black-box structure it does not of-fer the same flexibility as Modelica based tools. Composing an operator training simulator for a standard power plant is a straightforward task with APROS, but the flexibility of the model use that made Dymola and Modelica attractive for the micro turbine system described in Section 5.10 is lacking. The closed source nature of APROS models makes APROS less suited for control system analysis and design purposes. Extracting re-duced order models and systematic model reduction are not possible with black box modeling tools.

The structure of the APROS models is similar to that of the Ther-moFluid models: “The primary state variables of the thermal hydraulic nodes are pressure, enthalpy, and component mass fractions, and for branches flow velocity. Material property functions are used in calculating various quantities, such as density and viscosity, according to pressure, enthalpy and component mass fractions”⁴.

On the other hand, APROS offers models of different levels of fidelity for each component, which can be selected on a component level to get a good compromise between fidelity and simulation speed. APROS has a communication library to connect the simulator to a distributed control

4information from the APROS web site at http://www.vtt.fi/aut/tau/ala/apros.htm

Chapter 5. The ThermoFluid Library

system. This makes it easy to test new or changed control laws against the simulated plant model. For many simulation applications, APROS provides good solutions when all required process models are available in the APROS model library.

FlowMaster 2

FlowMaster 2 is a commercial, closed source simulation environment for systems with internal flows and heat transfer. It has a graphical user interface for model composition and a database of commonly used com-ponents. Analysis modules are chosen from application specific packages, e. g.,

• Automotive thermal analysis

• Automotive lubrication

• Liquid piping systems

• Gas piping systems

• Aerospace fuel systems

• Air conditioning

The possible application domains of FlowMaster are almost identical to those ofThermoFluid and Dymola, the difference is the degree of special-ization of the tools, the scope and philosophy of the model libraries and the modeling approach. The differences compared toThermoFluidare very similar the ones between APROS and Dymola/ThermoFluid.

The main advantage of specialized domain specific tools are:

• Integration of all tools and utilities needed for the usual engineering tasks in that domain. Equally important is the fact that no unneeded features of a general purpose tool are cluttering the user interface and increasing the learning time.

• The existence of comprehensive model libraries for a very specific domain. A model library for automotive lubrication is much less gen-eral thanThermoFluidbut gives results much quicker than building a specialized library on top ofThermoFluid.

• Numerical routines which are specifically adapted to a problem do-main can be more efficient for that problem. APROS can handle many thousands of states easily while Dymola currently can not.

The main problems with closed source models like in FlowMaster or APROS are twofold:

5.11 Comparison with Domain Specific Tools

• It is impossible to find the details of the model equations. Confidence in models and simulation results rest on a questionable foundation, namely the confidence in the tool vendor.

• When no suitable model can be found in the closed, vendor provided libraries, users usually have to ask for expensive consulting services from the tool vendor to provide the missing closed-source models.

If the models do not fulfill the expectations, the user ends up in a vicious circle and will be asked to spend further money on consulting.

In conclusion one might say that a combination of the advantages of both tools would be the best solution for users: ease of use and model libraries which are as comprehensive as FlowMaster’s and the level of insight and flexibility to develop custom models as in Dymola with Mod-elica. Obviously the ability to write custom models raises the level for the ease of use for the modeling part. It should however be possible to make the flow-sheeting and simulation part of a general purpose tool like Dymola as intuitive to use as of any special purpose tool. In that case it is probably necessary to have a customizable user interface.

Other Modelica Libraries

TheThermoFluid library can be viewed as a framework of software com-ponents that are designed to handle certain problem scenarios well. If the modeling problem in question is outside that range of problems, it may be much better to design or use a simpler but more specific library than to add yet another application to an already complex library.ThermoFluidis made for compressible flows and complete balance equations for mass, en-ergy and momentum. It is possible to choose between dynamic and static momentum balances. Problems that deal only with mass flows or energy flows may be better dealt with using a simpler structure and a more spe-cialized library. A good example of a spespe-cialized library focusing on mass balances for quasi steady state, incompressible internal flows which are typical for liquid transport in chemical processes is described in[Fabricius and Badreddin, 2002]. For incompressible flows it is clearly advantageous to have a separate library. Modelica has the option to interface different libraries if the connection is physically reasonable. Even for certain com-pressible flow problems with a different focus, e. g., no energy balance like in the hydraulics library [Beater, 2002], a separate library is preferable to over-extending the application range ofThermoFluid.

There is an unavoidable compromise between a very general library and a specific one which has to be considered in each particular case:

• A general library will always have extra overhead in terms of addi-tional parameters, variables or interfaces which are not needed in a specialized model library.

Chapter 5. The ThermoFluid Library

• The generality of a library leads to a higher degree of abstraction and a more fine-grained model structure that are obstacles to new or occasional users.

• Specific libraries have limitations in scope. They are not useful for other or mixed domain applications.