Definitions modeling

Keilson-Storer kernel 17-19 Fourier transform 18 Gaussian distribution 18 impact theory 102. /-diffusion model 199 non-adiabatic relaxation 19-23 parameter T 22, 48 Q-branch band shape 116-22 Keilson-Storer model definition of kernel 201 general kinetic equation 118 one-dimensional 15 weak collision limit 108 kinetic equations 128 appendix 273-4 Markovian simplification 96 Kubo, spectral narrowing 152... 

The answers to the above questions will be the main drivers in choosing the most appropriate approach for the model definition and implementation. A fuel cell operation, in fact, involves a relatively large and complex number of phenomena occurring at the same time, at different scale levels, and in different components of the fuel cell. 

Model Definition. The HSAB model classifies Lewis acids (electrophiles) and bases (nucleophiles) as either "hard" or "soft." Hard acids and bases are relatively small, and exhibit low polarizability and a comparatively low tendency to form covalent bonds. Soft acids and bases have the opposite characteristics (24). Stated simply, the model postulates that hard acids react most readily with hard bases, and soft acids react most readily with soft bases (26). 

Figure 8.4. Main window of Gepasi. The main window of Gepasi consists of menus (File, Options, and Help), icons, and four tabs (Model definition, Tasks, Scan, and Time course). Activation of any of the tab opens an indexed page. At the start of Gepasi, the Model definition page is opened. Enter name of the metabolic pathway to the Title box. Click Reactions button to define enzymatic reactions (e.g., E + A+B = EAB for R1, EAB = EPQ for R2, and EPQ = E + P + Q for R3 shows 3 reactions and 7 metabolites), and then click Kinetics button to select kinetic type. Activate Tasks tab to assign Time course (end time, points, simufile.dyn), Steady state (simufile.ss) and Report request. Activate Scan tab to select scan parameters. Activate Time course tab to select data to be recorded and then initiate the time course run.

Figure 8.5. Definition of kinetic type for Gepasi. To define new kinetic type, open User-defined kinetic types dialog box by clicking Kinetic types button (Model definition page). Click Add button to open New kinetic type dialog box. Enter kinetic equation as shown in the Kinetic function box (forward ordered Bi Bi) of the inset and click Accept function button.

The previous tables summarise criteria and parameters for the failure probabilities calculation, beginning with a list of failure probability model definitions in Table 1, followed by specific data on mechanical equipment in Table 2, and ending with some unavailability reported values in Table 3. 

The definition of a generic object-oriented implementation framework for the interpretation of environment model definitions by the process-integrated tools and the dynamic adaptation of their interactive behavior. 

Domain-specific knowledge is formalized by a process model definition (cf. Sect. 2.4) which constrains the process model instances to be maintained at project runtime. As a consequence, the manager may compose task nets from predefined types and relationships. The process model definition is represented in the Unified Modeling Language UML [560]), a wide-spread standard notation for object-oriented modeling. A process model is defined on the type level by a class diagram which has been adapted to the underlying process meta model for dynamic task nets [388, 389]. 

Before the AHEAD system is used to manage some actual design project, it is provided with a domain-specific process model definition (cf. Sect. 2.4) which should capture the conceptual design and basic engineering of arbitrary chemical design processes to meet our own demands in the IMPROVE project. 

From the UML model, code is generated to customize the functionality provided by the AHEAD system. For example, the project manager may instantiate only the domain-specific classes and associations defined in the class diagrams. The core system as presented in this section enforces consistency with the process model definition. In this way, we can make sure that design proceeds according to the domain-specific model. A more flexible approach will be discussed in the next section (extending process evolution beyond consistency-preserving instance-level evolution). 

PROGRES as well as its modeling environment, which offers a graphical editor, an analyzer, an interpreter and a code generator [414], Both the process meta model and process model definitions are specified in PROGRES. The former was created once by the tool builders of AHEAD the latter ones are generated automatically by the modeling environment (cf. Subsect. 3.4.3). 

While working on the Polyamide-6 reference process, it turned out that even process model definitions cannot be determined completely in advance. Therefore, we generalized evolution support to include all of the following features (cf. [171-173, 387, 390[) ... 

Bottorn-up evolution. By executing process instances, experience is acquired which gives rise to new process definitions. An inference algorithm supports the semi-automatic creation of a process model definition from a set of process model instances. 

Top-down evolution. A revised process model definition may be applied even to running process model instances by propagating the changes from the definition to the instance level. 

The process meta model introduces the language (or meta schema) for process model definitions. The meta model is based on djmamic task nets. It provides meta elements for structural (tasks, control and data flows etc.) and for behavioral aspects (e.g. state machines for tasks) of these task nets. 

Process (model) instances are instantiated from process model definitions. A process model definition represents reusable process knowledge at an abstract level whereas process model instances abstract from only one real world process. A process model instance is composed of task instances which are created from the task classes provided by the process model definition. 

On the partially typed level, the process modeler is capable of defining domain-specific types of tasks and relationships, but he also permits the use of unconstrained types on the instance level. In particular, this allows to leave out exceptions like feedbacks in the definition. When feedback does occur during enactment (e.g., a design error is detected during implementation), it can be handled by instantiating an unconstrained type of feedback flow without necessarily changing the process model definition. 

Inconsistencies between process model instances and real-world processes are frequently caused by inadequate process models. The vast majority of process management systems demands consistency of the process model instance with the process model definition. As a consequence, the process model instance cannot be updated to represent the deviations taken by the process participants. 

---