CHEPROO
Descripción
CHEPROO es una herramienta orientada a objetos especializados en los procesos geoquímicos complejas. Puede ser fácilmente vinculado a un código externo y para resolver los complejos procesos geoquímicos.
Capabilities
- Cálculos de transporte reactivo.
- Cálculos geoquímicos.
- Caminos de reacción cinética.
- Tendencias de evaporación.
- Modelo de Pitzer.
- Intercambio catiónico.
Soporte técnico
- Sergio Andrés: Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.
- Bea Jofré: Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.
Tabla de contenidos
CHEPROO object-oriented inspired principles
Some public services implemented in CHEPROO
Linking CHEPROO to other codes
CHEPROO object-oriented inspired principles
This section describes the main principles of object-oriented programming that are relevant for CHEPROO. It is included for the sake of completeness, but can be omitted by readers that are familiar with the topic. Details on OOP are given in Decyk et al. (1998), Akin (1999), Carr (1999), Meysman et al. (2003a) and Gorelik (2004). OOP consists of grouping entities that share both the type of data that describe them and the type of functions they can perform. The resulting data structure (set of attributes) and functions (method) is termed a ’class’. Specific entities from a class are called ’objects’ resulting from assigning values to the attributes. For example, all chemical reactions have a name, a number of species, stoichiometric coefficients, an equilibrium constant, and if the reaction is kinetic, a rate law. Chemical reactions can perform maintenance operations (i.e. create, read, destroy) and be used for computing the concentration of secondary species (equilibrium reactions) or reaction rates (kinetic reactions). Therefore, ’reaction’ defines the class and specific reactions (e.g. ’calcite dissolution/precipitation’) would be objects of this class. Figure I displays several examples of classes and objects. OOP is based on three features that facilitate the design, maintenance and growth of programs: 1) encapsulation, 2) inheritance and 3) polymorphism. Encapsulation of objects makes it possible to hide the details of internal implementation, while providing an explicit interface for them. This feature facilitates the use of program units because an object can perform its services without bothering the ’user’ with details. Moreover, these internal details of the service may be changed without affecting the use of the object, thus facilitating extension. Inheritance is formally defined as the ability to reuse and share the data and methods of existing classes to construct hierarchical classes. Indeed, inheritance is most useful when a class can be specialized (i.e., when an object can respond to the question ’is of type...’). For example, an object of the class ’phase’ can be of type mineral, aqueous, gas (Figure I). This feature greatly facilitates extensibility. In the above example, simply adding the specialization ’solid mixture’ would allow the code to work with this new type of phase without any other modification. Inheritance allows us to reuse previously created classes while reducing the size of the program. Polymorphism allows us to use the same name on methods implemented in different classes. Figures IC and ID illustrate example of polymorphism for reaction and phase classes. The method ’compute ’ is used in both classes. This operation returns the concentration of secondary species in equilibrium when applied to a reaction object, or alternatively, the thermodynamic activity coefficients when applied to a phase
F90 supports object-oriented programming. After we define a class, we create its container as a module. The module separates the class from the main code and allows us to store it in an external file. The data structure that defines a class is encapsulated in an user-defined data type. Therefore, each module corresponds to one user-defined data type. The main operations upon this derived data type are also defined within the module as typical subroutines (or functions). Polymorphism is implemented using interfaces and the compiler will execute the correct implementation depending on the type of arguments in the subroutine or function (examples about encapsulation and polymosrphism in F90 can be found in Meysman et al., 2003a,b). Inheritance is not directly supported on F90 unlike truly object-oriented languages such as C++ or Java. However, it can be emulated according to Decyk et al. (1998).
Figure I: Example of class (abstracted data structure) and object (instance of this class) for several entities in a geochemical system: species, reaction and phase.
CHEPROO: Class organization
All the chemical processes are represented by a class termed CHEPROO. This class encapsulates two different classes termed Nodal Chemistry and Chemical System. The Nodal Chemistry class contains compositional data (e.g. concentrations, temperature, mass of water, cation exchange capacity) of a portion of the physical system and is meant to define many objects (e.g. nodes of a finite element mesh). The chemical system class contains the entire description of a geochemical system (species, phases, reactions and kinetic laws, Figure IIA). It is meant to describe few objects (e.g. zones of an aquifer with different active minerals). Both classes are associated to each other. Thus, the methods implemented in the Chemical System class are mainly used by the Nodal Chemistry class. Lists of Nodal Chemistry and Chemical System objects can be created within a CHEPROO object. At the present version of CHEPROO supports three lists of Nodal Chemistry objects. One of them is fixed and predefined in an input file (it is typically used to define initial conditions, boundary waters, or the like). The other two Nodal Chemistry objects lists may change in dimension and content during run time. They may represent the compositional information (e.g. concentrations) in different calculations events (e.g. one list for a previous time step, the other for the present one). Also a list of Chemical System objects can be created. The CHEPROO object handles them, assigning to each Nodal Chemistry object its corresponding Chemical System object. All input data is read from files in xml (eXtensible Markup Language) format. This format was preferred because the information is organized in data structures, and therefore, it is consistent with the object-oriented philosophy.
Figure II. Class organization of CHEPROO.
Some public services implemented in CHEPROO
Linking CHEPROO to other codes
We outline here the use of CHEPROO for solving reactive transport problems based on either SIA or DSA. We assume that a user has got a conservative transport simulator and wishes to modify it to include reactive transport. As illustrated in Figure III, only a small number of modifications are needed.
One starts by declaring the use of CHEPROO module
use m_cheproo
In a F90 object-oriented implementation, a module supports one user-defined data type, and the CHEPROO objects are variables declared as
type(t_cheproo) :: mychemistry
Initialization requires creating (memory space allocation) and reading ’mychemistry’ object from xml file (’mychemistry.xml’)
create_ (mychemistry)
read_xml_ (mychemistry,’mychemistry.xml’)
In this process, the chemical system and the chemical composition of some ’waters’ are read. After reading, initial waters are speciated and stored in nodal chemistry objects. On the other hand, to work on ’mychemistry’ involves creating and initializing a list of nodal chemistry objects. Initial information in these nodal chemistry objects can stored in three ways. As regards the first option, it entails to define in the input file the number of nodal chemistry objects and their corresponding indices with the ’waters’ defined in same file. As regards the second option, the number of nodal chemistry objects and their corresponding indices are provided by the user code through the methods ’create_nodalchem_’ and ’init_nodalchem_’ respectively. The third option is known as ’restart’ procedure. Concentrations obtained in other calculation event (e.g. a simulation of reactive transport) can be written in a xml file. In this case, a new list of nodal chemistry objects could be created and initialized from this file.
The solution procedure using SIA is shown in Figure IIIA. The external code solves the transport step for each component, and then CHEPROO updates the reaction contribution. In the second implementation (Figure IIIB), a CHEPROO object solves the reactive transport equations (optionally in SIA or DSA). In either case ’mychemistry’ object can yield information for updating flow and transport (e.g. to update hydraulic conductivity from porosity variations). It is clear that CHEPROO makes it very easy to build a reactive transport code from a standard conservative transport code. This ease and flexibility could not be obtained when reactive transport is implemented using procedural-programming in a similar way. Notice, moreover, enhancements on either conservative transport (i.e. changing the simulation method) or reactive algorithms (i.e. using a new speciation method) can be implemented without modifying the basic structure.
At the present, two reactive transport codes were obtained coupling CHEPROO (in both cases according to option outlined in Figure IIIB). On of them with the code CODE-BRIGHT (Olivella et al., 1994), and the other one with the code TRACONF (Carrera et al., 1993).
Figure III: Outline of possible reactive transport implementations in conservative transport simulators. Notice that a conventional conservative transport code (shaded boxes) can be easily transformed into a DSA-based (right) or a SIA-based (left) with a very limited number of modifications in the original code.
References
Akin, J. E., Object oriented programming via Fortran 90, Engineering Computations, 16, 26–48, 1999.
Bea, S., J. Carrera, F. Batlle, C. Ayora, and M. Saaltink, CHEPROO: A Fortran 90 object-oriented module to solve chemical processes in Earth science models, Computers & Geosciences, 2008a, (in press).
Bea, S., J. Carrera, and C. Ayora, Pitzer algortithm: Efficient implementation of the Pitzer equations in geochemical and reactive transport models, Computers & Geosciences, 2008b, (submitted).
Carr, M., Using Fortran90 and object-oriented programming to accelerate code development, IEEE Antennas and Propagation Magazine, 41, 85–90, 1999.
Carrera, J., Galarza, G. and Medina, A. TRACONF: Elements finite program to solution of flow and transport equations in confined aquifers. User manual, 1993.
Decyk, V. K., C. D. Norton, and B. K. Szymanski, How to support inheritance and run-time polymorphism in Fortran90, Computer Physics Communications, 115, 9–17, 1998.
Gorelik, A. M., Object-oriented programming in modern Fortran, Programming and Computer Software, 30, 173–179, 2004.
Meysman, F. J. R., J. J. Middelburg, P. M. J. Herman, and C. H. R. Heip, Reactive transport in surface sediments. I. Model complexity and software quality, Computers & Geosciences, 29, 291–300, 2003a.
Meysman, F. J. R., J. J. Middelburg, P. M. J. Herman, and C. H. R. Heip, Reactive transport in surface sediments. II. MEDIA: An object-oriented problem-solving environment for early diagenesis, Computers & Geosciences, 29, 301–318, 2003b.
Olivella, S., J. Carrera, A. Gens, and E. E. Alonso, Nonisothermal multiphase flow of brine and gas through saline media, Transport in Porous Media, 15, 271–293, 1994.
Archivos
Descargar Manual Ejemplo Aqueous Phase Class TRACONF-CHEPROO
