WO2005111873A1 - Object-oriented framework for hydroprocessing reactor simulation applications - Google Patents

Abstract

An object oriented framework provides a set of objects that perform Hydroprocessing Reactor Simulation functioning and that permit a framework user to add extensions for specific processing features, thereby producing a Hydroprocessing Reactor Simulation application program that supports development and operation of company processes. The framework includes a Reactor Definition Document category of classes for defining the Hydroprocessing Reactor Process, a Reactor category of classes for parsing the Reactor Definition Document and creating internal classes that mathematically model reactor behaviour and a Simulator category of classes that simulate Reactor behaviour via the solution of the mathematical model defined by the Reactor classes and register simulation results for further engineering analysis. These classes provide the base framework upon which Hydroprocessing Reactor Simulation application programs are developed by the framework user.

Description

OBJECT-ORIENTED FRAMEWORK FOR HYDROPROCESSING REACTOR SIMULATION APPLICATIONS Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to data processing systems and, more particularly, to object oriented programming systems and processes.

2. Description of the Related Art

Computer programs have typically been developed using procedural programming techniques. Procedural programming techniques emphasize structuring ihe data processing procedures to which data values are .subjected. Efforts to reduce long software development times and high software maintenance costs have resulted in structured programming techniques that attempt to reuse blocks of programming code. For example, tasks or processes that must be repeated can bo written as system programming routines or program library functions. Program developers then provide an application program to accomplish a desired result using calls to the system routines and library functions.

System routines and library functions provide only a limited reduction in software development time and maintenance costs. Once a procedural application program is written, it is relatively difficult to incorporate new features or additional data lypes. There arc many processes in an application program thai cannot be easily extracted from program code and reused. Additional data types often cannot be inserted into procedural program code without extensive rewriting of the original program code. Thus, even if new features in a program can be implemented using processes similar to those already in the application, the programming for such processes must bo largely duplicated, with slight modifications, to provide the new features. This increases program development time. Moreover, if such programs must operate with other applications, it can be difficult to ensure thai the changes will interface properly.

Another problem confronting program developers is that of providing program versions capable of operating with the various platforms used by customers. The different platforms encompass different operating systems as well as different companion applications with which the application must interface. With respect to operating systems, for example, a program developer might have to write different versions for satisfactory operation under the "Windows" operating system by Microsoft Corp. or tho UNIX system. In a similar fashion, a program developer might want to provide the ability to interface with application programs such as word processor programs, spreadsheet programs, and the like, meaning that the program developer must provide the ability to accept files (and produce files) in different file formats. Different platforms use different data formats and procedural operations, so program developers must provide different program versions or routines for each platform, Another problem confronting program developers is that of providing program versions capable of operating with the various platforms used by customers. The different platforms encompass different operating systems as well as different companion applications with which the application must interface. With respect to operating systems, for example, a program developer might have to write different versions for satisfactory operation under the "Windows" operating system by Microsoft Corp. or the UNIX system. In a similar fashion, a program developer might want to provide the ability to interface with application programs such as word processor programs, spreadsheet programs, and the like, meaning that the program developer must provide the ability to accept files (and produce files) in different file formats. Different platforms use different data formats and procedural operations, so program developers must provide different program versions or routines for each platform.

Object oriented programming (OOP) techniques encapsulate, or bind together, data and methods that operate on them. This permits program development to more closely model real-world systems for problem solution and breaks up program development efforts into smaller, more manageable pieces. OOP programs are developed around object classes that have attributes, also called data values, and methods, also called functions. Although OOP techniques have done much to improve program development efficiency, such techniques still require a great degree of code generation on the part of application developers and limit program reuse among different classes.

OOP frameworks have been developed in an effort to further reduce program development costs. For example, U.S. Pat. No. 5,398,336 discloses an object oriented architecture for factory floor management; U.S. Pat. No. 5,787,425 discloses an object oriented data mining framework mechanism; U.S. Pat. No. 5,878,432 discloses an object oriented framework mechanism for source code repository; U.S. Pat. No. 5,936,860 discloses an object oriented framework for warehouse control and U.S. Pat No 6,618,852 discloses an object oriented framework for chemical-process-development decision-support applications. A framework is a set of OOP classes that embodies a predetermined set of attributes and methods for providing a common group of behaviours. An application program developer utilizes the framework and builds upon it, adding subclasses and attributes and modifying methods depending on the problem to be solved. Such changes to the framework are typically referred to as framework extensions, and are made possible by the OOP notions of inheritance and polymoφhism. The challenge confronting framework developers, then, is to arrive at a set of classes and methods that will best provide the desired problem solution and will accept the most likely framework extensions. Thus, the designer of a framework must carefully assess what framework users will most likely need in the way of classes and attributes.

One area in which there is a great need for application program development is in the simulation of hydroprocessing reactors. In particular, many businesses are aiming to simulate the operation of their hydroprocessing reactors under normal and/or hypothetical scenario-based conditions. Representative applications, for example, include simulation of process response to process upsets, optimization of process operating conditions, simulation of a candidate revamped process and de-bottlenecking of an existing process. Particularly, industrial Hydroprocessing Reactors are known for their unique features originating from hardware evolution, need to interface with other Refinery Process Units and market or regulation driven product specification changes. Thus, commercial units are continuously changing, so that simulator program development and software maintenance are critical. Today, a great deal of cost and effort are devoted to developing and maintaining application programs that perform hydroprocessing reactor simulation functionality.

From the discussion above, it should be apparent that there is a need for development tools that permit application program developers to more quickly develop and more easily maintain hydroprocessing reactor simulation applications. The present invention fulfils this need. BRIEF SUMMARY OF THE INVENTION

In accordance with the present invention, a reusable object oriented (OO) framework for use with object oriented programming systems comprises a Hydroprocessing Reactor Simulation control shell that permits a framework adopter to use a set of internal objects and a set of external objects that account for specific Reactor Hardware and Reaction Kinetics features, and to then add framework extensions for other specific processing features, thereby producing a Hydroprocessing Reactor Simulation application specific to the company process. Such a Reactor Simulation application can be used to simulate process response to process upsets, optimize process operating conditions, simulate candidate revamped processes and de-bottleneck existing operations. In this way, the Hydroprocessing Reactor framework of the invention provides an OO base on which application program developers can build to add specific data types and processing features they deem important.

The framework includes classes for which anticipated extension sub-classing with new attributes and methods will occur. An application program developer can customize the extension classes to meet the needs of the application users and create all user interfaces with the application program, permitting the developer to more quickly complete program development and more easily perform software maintenance. The end-user interface establishes a means for the end-user to communicate with the application program to receive, process, and view data. The framework allows the program developer to concentrate on application program features, which can easily be implemented by extending the 00 classes and methods of the 00 framework. The framework thereby provides a base from which a variety of hydroprocessing reactor simulation systems can be quickly and efficiently produced.

The framework includes object oriented classes that specify object data attributes and methods. The framework adopter is free to incorporate extensions to the framework to provide a unique suite of functions and operations, resulting in the production of an application that is then utilized by an end user. For example, a single object of the framework provides a data object location for characterizing the chemical species and the properties of the process streams. Using OOP principles, the framework adapter can add attributes not present in the framework to support the species characterization desired by a customer. In this way, the framework adopter maximizes the exploitation of program commonality and the reuse of programming efforts, thereby reducing program development time and software maintenance costs.

Other features and advantages of the present invention should be apparent from the following description of the preferred embodiment, which illustrates, by way of example, the principles of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow diagram representation of the application development process, which utilizes the framework of the invention, to provide a hydroprocessing reactor simulation application program.

FIG. 2 is a block diagram of a computer system constructed in accordance with the invention.

FIG. 3 is a representation of the computer system of FIG. 2. It shows the Reactor Definition Mechanism, the Reactor Mechanism and the Simulator

Mechanism that comprises the framework, and also shows related common and generic business objects utilized by the extended Hydroprocessing Reactor simulation framework of the invention.

FIG. 4 is a class diagram of the Reactor Definition Document showing Identity, Chemical Species, Reaction Networks, Fillings, Reactor Hardware, Process

Upsets, Validator and Controller classes of objects.

FIG. 5 is a class diagram of the Chemical Species class illustrated in FIG 4. The class contains Identity Information utilized by the Hydroprocessing Reactor Simulator framework and user defined Identity Information utilized by the Properties Predictor class to be used by the Application and other Property

Information.

FIG. 6 is a class diagram of the Reaction Network class illustrated in FIG. 4 consisting of the Reaction class and its Properties and Stoichiometry subclasses.

FIG. 7 is a class diagram of the Reactor Hardware collection illustrated in FIG.

4. The Reactor Hardware class also contains a collection of Reactor Hardware Connectivity sub-class. FIG. 8 is a class diagram of the Reactor Hardware class illustrated in FIG. 7 consisting of the Identity, the Catalyst and the Reaction Network sub-classes.

FIG. 9 is a class diagram of the Process Upsets class illustrated in FIG. 4 consisting of the Identity and the Reactor Hardware sub-classes.

FIG. 10 is a class diagram of the Reactor Document Definition Validator class illustrated in FIG. 4 consisting of the Reaction Network Validator and its Reaction, Chemical Species and Stoichiometry Validator sub-classes, and the Reactor Hardware Validator class with its Connectivity, Fillings and Reaction Network Validator sub-classes.

FIG. 11 is a category diagram representation of the Reactor categories

FIG. 12 is a diagram of the Reactor Mechanism showing the Reactor Document Parser class, the Model Builder class, the collections of Reactor Components and Streams classes, and the Controller class.

FIG. 13 is a class diagram of the Parser/Validator class illustrated in FIG. 12 consisting of the Reactor Hardware Parser/Validator class and the

Parser/Validator sub-classes of Connectivity, Fillings and Reaction Networks.

FIG. 14 is a class diagram of the Reactor Component class illustrated in FIG. 12 showing its Identity, Catalyst, Reaction Network, Inlet Stream, Outlet Stream and Component Properties sub-classes.

FIG. 15 is a class diagram of the Reactor Stream illustrated in FIG. 12 showing its Identity class, its collection of Phase classes and its Reactor Component Property class. Each Phase class consists of the Identity class and the Properties class. The Property Predictor class is also shown as a sub-class related to the Property class.

FIG. 16 is a category diagram representation of the Simulator categories FIG. 17 is a class diagram of the Reactor Simulator Mechanism consisting of the Identity class, the Reactor class, the Equation Solver class, the Upset Parser class and its value validation and Hardware Parameter Parser/Validator subclasses, and the Controller class.

FIG. 18 is a flow diagram representation of the processing carried out by the

Reactor Definition Document Creator using the Reactor Document Definition category illustrated in FIG. 4.

FIG. 19 is a flow diagram representation of the processing carried out by the Model Creator using the Reactor category illustrated in FIG. 12.

FIG. 20 is a flow diagram representation of the processing carried out by the

Simulation Runner using the Simulator category illustrated in FIG. 17.

DET AILED DESCRIPTION OF THE INVENTION

Application Development

FIG. 1 is a flow diagram representation of the steps performed with a computer system to produce a Hydroprocessing Reactor Simulation application program using the framework of the present invention. The Hydroprocessing Reactor

Simulation application program of the preferred embodiment is designed to obtain certain information from objects of related core classes. Such information will include process information concerning the reactor configuration for which reactor simulation is needed, as well as other information needed to carry out operations in a computer system. These core classes can be organized into a core framework (CF) that is complementary to the framework of the present invention. The application developer provides a user interface and combines operating interface features of the core object classes with the structure and functionality of the hydroprocessing reactor simulation OOP framework constructed in accordance with the present invention, and also adds particular framework extensions as needed, to generate an application program. The resulting application program can be used by customers, such as research and engineering groups in Petrochemical businesses, to carry out hydroprocessing development functions and other related tasks. In the following description, "framework" will refer to the framework illustrated in the drawing figures and

"application" will refer to an application program that comprises an implementation of the extended framework, produced by an application developer who uses the framework.

In the FIG. 1 flow diagram, the first step is to incorporate the core framework with the Hydroprocessing Reaction Simulation framework of the invention, as represented by the flow diagram box numbered 101. This step includes the incorporation of any object classes necessary for the system on which the application will run. For example, the preferred embodiment achieves operating platform independence and application program inter-operability by extending classes from the core framework (CF) set of base business classes. In this way, the Hydroprocessing Reactor Simulation application can interface with multiple operating systems because only the CF extensions need change to accommodate new operating systems, while the Hydroprocessing Reactor Simulation application can remain the same. In a similar way, companion application programs can more easily interface with the extended application program because the core, common set of CF classes will be known and will form a common interface.

The next step of application program development is to add desired extensions to the Hydroprocessing Reactor Simulation framework, including the user interface. To implement this part of the program development process, the application developer framework user must decide upon the particular extensions needed for the desired Hydroprocessing Reactor simulation operations and user interface, including any modifications or extensions to the class attributes and behaviours. The framework extensions are performed by a framework user in a manner dependent on the particular computer system on which the framework is received and manipulated. Such processing is represented in FIG. 1 by the flow diagram box numbered 102.

After the framework extensions are decided upon, the next step is to generate the application program. This step is represented by the flow diagram box numbered 103. The generation of an application program is generally referred to . as program compilation. This step also will depend on the particular computer system on which the framework is used. Changes to the compiled program might be desired; both as part of the initial program debug and as part of revisions due to comments received from actual use. The process of determining such desired changes is represented by the flow diagram box numbered 104.

When such changes are determined, they must be implemented into the program structure in the form of modified classes, attributes, and methods, which comprise further extensions to the framework. This is represented by the flow diagram path from the "determine changes" step at box 104 back to the "add extensions" step at box 102. Thus, the design of the framework provides base classes on which application program developers can build to add specific features they deem important. With the core business classes, the framework classes can remain platform independent so that framework extensions are simplified. The application is easily modified without need for writing multiple versions of the program code because the revision of framework classes, attributes, and methods in accordance with the invention is platform independent. Easier development of new code, and seamless operation with applications using the same core classes, is ensured.

Operational Structure

FIG. 2 is a block diagram of a computer system 206 constructed in accordance with the present invention. The computer system is suitable for utilizing the framework of the invention to develop an application program, and for using the extended framework application program. The computer system 206 includes a central processing unit (CPU) 208 that operates in response to operator commands, which it receives from an operator/display interface 207 to which it is connected by a system bus 209. The CPU also communicates over the system bus with a main memory 205. The main memory is illustrated containing a variety of data structures, including application programs 201, objects 202, data 203, and an operating system 204. The main memory 205 is represented as a single entity, but those skilled in the art will appreciate that the main memory can comprise a combination of random access memory (RAM), hard disk drives, optical disk drives, and other storage devices containing logically segmented storage locations.

The operating system 204 preferably supports an object oriented programming environment such as that provided, for example, by the C++, Java and Visual Basic programming languages. The application programs 201 are invoked, or launched, by a user through the operator/display interface 207. The application programs can be written in a variety of languages, including C++, Java and Visual Basic. The objects 202 are data or software structures of an object oriented programming language, such as C++, Java and Visual Basic.

The computer system 206 also includes a direct access storage device (DASD) interface 211 that is connected to the system bus 209 and also is connected to a DASD 212. Those skilled in the art will appreciate that the DASD 212 can receive and read from program products comprising machine-readable storage devices 213, such as magnetic media disks on which are recorded program instructions whose execution implements the framework of the present invention. The storage devices 213 also can comprise, for example, media such as optical disks and other machine readable storage devices. The computer system 206 also includes a network interface 210 that permits communication between the CPU 208 and other computer systems 214 over a network 215. The other computer systems 214 can comprise, for example, computer systems similar in construction to the exemplary computer system 206. In that way, the computer system 206 can receive data into the main memory 205 over the network 215 after communication between the computer systems has been established by well-known methods that will be understood by those skilled in the art without further explanation.

System Modules

In the preferred embodiment of the invention, the object oriented framework includes system modules comprised of a Reactor Definition mechanism, which defines the underlying reactor process, a Reactor mechanism, which parsers the Definition Document object and builds the mathematical representation of the reactor and a Simulation mechanism, which executes the simulation and manages the reporting of the results.

The Reactor Definition module contains object categories that contain methods and attributes for defining the reactor process, which includes identity information, and information that characterizes the process such as chemical species, reaction networks, catalyst types, reactor hardware and desired process upsets to be simulated. Other categories provide additional features that improve the ability of the framework to accommodate user defined data types and features, as desired.

The Reactor module contains object categories that contain methods and attributes for parsing and validating the information contained in the Reactor Definition Document object and for building the mathematical representation of the Reactor through the creation of Reactor Component and Reactor Stream Collections. The Simulator module contains object categories with methods and attributes that simulate Process Operation, calculate hydrodynamic and thermodynamic properties, and store them on external devices and/or databases.

FIG 3 is a representation of the framework that operates in the system of FIG. 2, showing the Reactor Definition Document (RD), the Reactor (RT) and the Simulator (SM) modules or mechanisms that comprise the Hydroprocessing Reactor Simulator system that is the subject of this description. The RD, RC and SM mechanisms are shown attached to a Common Business Objects framework (CBOF) mechanism and a Generic Business Objects framework (GBOF) mechanism, which together comprise a core framework (CF) utilized by the framework of the invention. The CF provides common functionality to permit communication between application mechanisms and different operating platforms, which are shown in FIG. 3 by the modules indicated as "MS .NET" and "Linux" and are attached to CF.

Application developers will add sub-classing to the classes of which CBOF and GBOF are comprised. The classes of CBOF, for example, will include Reactor Hardware identification classes that can serve as base classes for defining Reactor Equipment to multiple application programs. A CBOF "hardware" class might contain general identifying hardware information, while the

Hydroprocessing Reactor Simulation framework of the invention might extend from the CBOF and include "hardware" classes that identify reactor configuration. Another application program, such as a Reactor Cost Planner, might include "hardware" classes that identify Process Equipment Cost. The GBOF classes are more directly related to the operating system and computer system side of the operating environment. That is, the GBOF classes are responsible for object persistence according to the operating system and object environment being supported, so that a Hydroprocessing Reactor Simulator object that wants to maintain an object in persistent data storage must interface with GBOF classes. For example, the classes of GBOF will include "data storage" classes that can serve as base classes for defining data transfer activities to other application programs. The hydroprocessing reactor simulation framework of the invention might extend from the GBOF and include "data- storage" classes that allow the application developer to directly transfer simulation results to a Relational Database Management System. All application programs in related "business object" subject areas, or domains, should be able to make use of the common object classes specified by the CBOF and GBOF classes.

The CF interface, however, does not form a part of the invention described herein. As noted above, those skilled in the art should be able to produce, without further explanation, a framework that provide the common functionality between operating systems and application domains that are provided by CF.

The Reactor Definition, the Reactor and the Simulator mechanisms of the Hydroprocessing Reactor Simulation framework function in a computer system that includes chemical species categories, reaction networks categories, reactor "fillings" categories, reactor hardware categories and process upset categories. After a framework adopter has extended the framework so as to produce a Hydroprocessing Reactor Simulation control application, the end user of the application provides data and commands to the simulation control application through the Reactor Definition model categories and the user interface and receives process simulated information through the Reactor categories.

The categories of the Reactor Definition mechanism will be described next, followed by a description of the classes that comprise the RD categories. The categories of the Reactor and the Simulator mechanisms will be described thereafter, followed by a description of the classes that comprise the RC and the SM categories. The processing of the extended framework will then be described, in accordance with accompanying flow diagrams of the processing.

1. Reactor Definition Document Mechanism

1.1 Reactor Definition Document Category

The inventor of the present framework has identified a set of OOP classes most likely to be desired by developers of Hydroprocessing Reactor Simulation application programs and have defined the relationships between such classes. These framework categories provide a base of information that can be used by program developers and from which extensions can be developed. Those skilled in the art will recognize that such classes can be overridden by users of the framework in that framework users who are developing applications can incorporate extensions and additions that suit the purposes of the end-user.

FIG. 4 is a category diagram for the Reactor Definition mechanism of the framework implemented in the computer system of FIG. 3, which shows one category, namely RD Document. Those skilled in the art will appreciate that a category, like the one illustrated in FIG. 4 contains groups of OOP classes that encapsulate data attributes and behaviours, and are stored in the memory of the computer system. Such classes can be implemented, for example, in a computer system operating environment that supports an object oriented computer programming language like C++, Java or Visual Basic. It should be understood that a category as used in this description refers to describing the classes that make up the framework in terms of categories for purposes of easier explanation. Categories do not always represent a structure that is reflected in any programming implementation of the framework. Those skilled in the art will appreciate the 00 classes specify characteristics of the objects that will be instantiated at run time and will cooperate to perform the program functions.

The Reactor Definition category includes a RD Document category of classes that contain information concerning properties, behaviour, and attributes of the hydroprocessing process of interest to the end user. That is, the hydroprocessing process that the end user is simulating with the assistance of the Reactor Simulation application developed with this framework is identified by the data contained in the RD Document category of classes.

1.2 Reactor Definition Document class diagrams

The following section will describe the framework of the present invention in terms of object class diagrams for the Reactor Definition (RD) Document categories. FIG. 4 is an object class diagram that illustrates the characteristics of the category called RD Document. A RD Document category comprises container objects classes for information specified by the RD Document. The class definition describes the hydroprocessing process that is the subject of the Reactor Simulation application. FIG. 5 shows that the RD Document has, or contains, relationships with several classes including Identity, Chemical Species, Reaction Networks, Fillings, Reactor Configuration, Process Upsets and Controller.

a. Identity class

The Identity class defines the "identity" information of the Reactor Definition class. It includes, for example, attributes such as project name, version number, investigator name, department and company name; simulation results control properties such as location, database connection parameters and creation date; and a collection of user fields.

b. Chemical Species class

The Chemical Species is a collection of species classes that define the chemical components used by the Property Predictor class of the Reactor Mechanism. The Property Predictor class to be described later is responsible for prediction of the stream properties in the simulated system. The chemical species class of objects contains the information that identifies and characterizes a single species. FIG. 5 illustrates a class diagram of the class that contains information on its identity and its properties. Those skilled in the art will recognize that the species identity information can include the Chemical Abstract Number (CAS), name, synonyms, description, and parameters specific to the Property Predictor class. The property class can include molecular formula, molecular weight and reference properties such as density, boiling point, melting point, viscosity, heat capacity, fugacity coefficient and other. Those skilled in the art will recognize that the information provided by the chemical species classes will be used by the Property Predictor class to calculate the properties of pure components and mixtures at process pressure, temperature and composition.

c. Reaction Networks class

The Reaction Networks class is a collection of Reaction Network classes that quantify the rate of chemical reaction of process species. FIG. 6 illustrates a class diagram of a Reaction Network class comprising of a collection of single Reaction classes. Each Reaction class specifies the rate of reactant transformation to products. Those skilled in the art will recognize that the

Reaction Property container can specify properties such as pre-exponential factor and Activation Energy. The Stoichiometry class is a collection of chemical species involved in the Reaction. Those skilled in the art will also recognize the need for specifying multiple Reaction Networks for better simulation of different Hydroprocessing Reactor sections (Desulphurization,

Saturation, Cracking, etc).

The Reaction Network class is a key class that can be overridden by the developer to include Reaction pathways specific to the end-user Process. Based on the Hydroprocessing Reactor Simulation Framework, the developer can define a series of Reaction Networks classes that best describe the chemical reactions of a specific catalyst of a commercial process. The series of Reaction Networks can also be stored externally and become available to end-users for studying their effect on the underlying Process on a scenario-based engineering study.

d. Fillings class The Filling class is a collection of "filling" objects that define the properties of "physical fillings" loaded to the Reactor Hardware, when applicable. Those skilled in the art will recognize that the information can include pellet type, shape, name and properties such as porosity, effective diameter, specific gravity, reactivity and other user specified. This class can be overridden by the developer to include information needed by the end-user application such as parameters of Pressure Drop calculation, catalyst deactivation, and other.

e. Reactor Hardware class

The Reactor Hardware class specifies the Hardware installed in the underlying Hydroprocessing Reactor. FIG. 7 illustrates an object diagram of the collection of Reactor Hardware objects and their collections of Connectivity objects. FIG. 8 illustrates an object diagram of the Reactor Hardware class with the Identity, Filling and Reaction Network sub-classes. Those skilled in the art will recognize that the identity information can include type, name and properties of distributor trays, inter-bed quench assemblies, catalytic beds, piping and other user specified. The Filling class is a "related" class with information on the Fillings of the Reactor Hardware. The Reaction Network class is a key "related" class of a Reaction Network that best describes the chemical transformation of species in the underlying Hardware and Filling. Those skilled in the art will also recognize that a Reactor Hardware can have no Filling and no Reaction object (i.e. distributor tray, piping), other Hardware can have only a Filling object (i.e. inert balls reactor sections) and other Hardware can have both (i.e. typical catalytic bed). The Connectivity object of FIG. 7 specifies Reactor Hardware physical connectivity as a collection of related Reactor Hardware objects.

The Reactor Hardware is a key class that can be overridden by the developer to include Reactor Hardware specific to the end-user Process. Based on the Hydroprocessing Reactor Simulation Framework, the developer can define a series of Reactor Hardware classes that best describe commercial Reactors. The series of Hardware objects can be stored externally and become available to the end-users for studying their effect on Process operation on a scenario-based engineering study.

f. Process Upset class

The Process Upsets class of FIG. 4 is a collection of Process Upset objects. FIG. 9 illustrates an object diagram of the class that defines a Process Upset to be simulated by the Reactor Simulator application. The class is comprised by the Identity class, the Reactor Hardware class and the Process Variable class. Those skilled in the art will recognize that the Identity class specifies name, time and duration, "shape" and its parameters (i.e. pulse, ramp, impulse) and other user defined. This class can be overridden by the developer to accommodate end-user requirements. The Reactor Hardware is a related class that defines the section of the Reactor that is undergoing the disturbance (i.e. Feed, Distributor Tray, and Catalytic Bed). The Process Variable class defines the Process variable to be disturbed. This class can be overridden by the developer. Those skilled in the art will recognize that the end-user can specify disturbances in Pressure Drop,

Temperature, Reactivity and other variables through this mechanism.

g. Validator class

The Validator class of FIG. 4 specifies the mechanism of Reactor Definition Document validation. FIG. 10 illustrates an object diagram of the class. Those skilled in the art will recognize that validation is done for consistency in the

Reaction Networks and in the Reactor Hardware. The Reaction Networks are validated for existence and compliance of chemical reactions, chemical species and Stoichiometry. The Reactor Hardware is validated for existence and compliance of the related Reaction Networks, Fillings and Connectivity, the last being validated in terms of up-stream and down-stream Hardware.

g. Controller class

The controller class of FIG. 4 is an override-able object that handles management of Reactor Definition Documents or portions of it. The attributes and methods of the class provide selection, deletion and updating functionality. Those skilled in the art will recognize that this class can handle selection of predefined Reaction Networks, Fillings, Chemical Species or Reaction Hardware from external databases, a mechanism that simplifies tremendously Document creation by the end-user.

2. Reactor Mechanism

2.1 Reactor Category

The Reactor mechanism illustrated in FIG. 11 includes a Reactor Definition Document Parser class that contains attributes and methods for reading Reactor configuration and validating consistency. Upon the validation of the Document, the Model Builder class creates and appends Reactor Components and Streams to the Reactor class collections shown in FIG. 12. The object also assigns the appropriate relations and properties. The Reactor mechanism illustrated in FIG. 11 also contains a Controller class, which provides attributes and methods for managing and accessing Reactor information (i.e. SaveAll, PrintAll, LoadAll, and InitAll).

2.2 Reactor class Diagrams

The section below describes the Reactor categories illustrated in FIG. 12.

a. Reactor Definition Document Parser

The Parser/Validator class of FIG. 12 is an object that parsers and validates information contained in the Reactor Document Definition class. Those skilled in the art will recognize that parsing and validation by this class differs from the validation performed by the Reactor Definition Document Validator of FIG. 4. Validation by the Model Builder Validator is based on the capabilities of the Model Builder and not on the consistency of the RD Document. For example, once a Reactor Hardware is being parsed, its identity is checked with respect to "known" Reactor Hardware types. Furthermore, assuming that the parsed Reactor Hardware is "known", the connectivity, fillings and reaction networks constrains are validated. Thus, a "distributor tray" should have no related Reaction Network and filling objects; a "catalytic bed" should have both. Similarly, Reactor Hardware connectivity is validated for consistency of type and number of up-stream and down-stream Hardware objects.

b. Model Builder, Reactor Component and Reactor Stream classes

The Reactor Component class of FIG. 14 is a key class of the Hydroprocessing Reactor Simulation Framework. The Reactor Component is a container of information provided by the Reactor Hardware class of the Reactor Definition Document mechanism and fully exploits the object oriented programming concepts of polymoφhism and inheritance. Those skilled in the art will recognize that the Model Builder class of FIG. 11 initiates a basic Reactor Component object for each Reactor Hardware specified in the RD Document and, depending on the Reactor Hardware Type; a collection of Reactor Component sub-classes which inherit the base class. It is this functionality which allows the Commercial Reactor dynamic response to be predicted numerically through the solution of a set of mathematical equations specified through override-able Reactor Component methods. The Reactor Component class exploits object oriented programming concepts of polymoφhism to accommodate Reactor Hardware Types of varying operating functionality (i.e. reactive and non-reactive, filled or empty and accumulative or not).

The Reactor Stream class of FIG. 15 is another key class of the Hydroprocessing Reactor Simulation Framework. The Model Builder class of FIG. 12 creates and relates one or more streams to each Reactor Component class (and its subclasses if applicable). The class includes the Identity class, the collection of Phase classes and the Component Properties class. Those skilled in the art will recognize that some properties of the streams (i.e. Phase pressure, Phase temperature, Phase composition) are treated mathematically as independent variables with their values being calculated by the Equation solver class. It is for this puφose that properties of the Reactor Components treated as independent variables (i.e. liquid saturation of the reactor) are stored in the "related" outlet stream and not on the Reactor Component class.

Those skilled in the art will also recognize that the ability of the framework to simulate multiphase flow in the Process Reactors imposes the inclusion of the Phase class collection of FIG. 15. Each Phase class includes attributes and methods for identifying the phase (i.e. vapour, liquid) and for calculating its physical properties.

The physical properties of each phase in a stream are calculated by the Property Predictor class of FIG. 15. This is a class that the developer of the Hydroprocessing Reactor Simulation application will override by providing methods for calculating properties of pure components and mixtures at Phase operating conditions (i.e. Pressure, Temperature and Composition).

d. Controller

The controller class illustrated in FIG. 12 is an overwrite-able object that manages the Reaction Mechanism. The class provides methods for accessing properties and methods of Reactor Components and Streams. Those skilled in the art will recognize that through the controller class the developer can manage all system independent variables (initialize, calculate response to one or more variations of their values, set their values and other) and add importing and exporting functionality for all Reactor class attributes. For example, the controller class can become a data provider to a reporter class for presenting and visualizing Reactor Simulation Results stored in the Reactor and its related classes attributes.

3. Simulator Mechanism

3.1 Simulator Category

The Simulator mechanism illustrated in FIG. 16 includes a Reactor Definition Document Parser class that contains attributes and methods for reading Process Upsets and validating them. Once the Upsets have been validated, the Equation Solver executes the Simulation. During the simulation, the Equation Solver methods are being managed by the Controller class. This class provides override-able attributes and methods for observing and controlling the progress of the simulation and the values of the Reactor attributes.

2.2 Simulator class diagrams

The section below describes the Reactor categories illustrated in FIG. 17.

a. Identity

The Identity class defines the "identity" information of the Reactor Simulation class. It includes, for example, attributes such as simulation name, Reactor Definition Document name, investigator name, department and company name; simulation duration, numerical parameters, simulation results control properties such as location, database connection string and creation date; and a collection of user fields. The information on this class can differ from the one defined by the Reactor Definition Document given that the simulation of the Reactor might be performed at different time by different user at different department or company.

b. Upset Parser/Validator

The Parser/Validator class of FIG. 17 is an object that parsers and validates Upset information contained in the Reactor Document Definition class. Those skilled in the art will recognize that the Reactor Hardware Parameter class validates the ability of the framework to simulate the response of the disturbance of the underlying Reactor Model attribute. Upon validation, ordinary consistency checks of the Upsets parameters (i.e. start/end time, formula - i.e. step, pulse, and ramp, value range and other user specified) are performed. The Reactor Hardware Parameter class can be overwritten by the developer to customize end-user application features.

c. Reactor The Reactor class is a related class described earlier in the FIG. 11. Methods of the Reactor class are being exposed to the Controller class and to the Equation Solver class of FIG.17.

d. Equation Solver

The Equation Solver class in FIG. 17 is a container for the Ordinary Differential

Equation mathematical solver provided by the developer. The Equation Solver itself is not part of the Hydroprocessing Reactor Simulation framework. The container exposes the Reactor Model and its attributes and methods needed for simulating Reactor Operation. Those skilled in the art will recognize that the container provides access to the Reactor Model independent variables and to their differential response to variations of the independent variable.

e. Controller

The controller class illustrated in FIG. 17 is the key management class of the Simulation Mechanism. Those skilled in the art will recognize that the class controls the initialization of the simulation, the application of the Upsets, the convergences of the Equation Solver and the management of the simulation results. For example, it provides methods for storing simulation results to an external system (i.e. database), methods for applying stopping criteria, methods for interrupting a simulation and other user defined.

4. Processing of Extended Framework

Following the definition of the framework classes and the brief presentation of their attributes and methods, we proceed to describe how the framework developer will implement Hydroprocessing Reactor Simulation applications. In a typical implementation, the framework user/application developer will utilize the class and methods definitions, as described above, with appropriate extensions and overrides, to produce a desired application program. Those skilled in the art will recognize that, as is the case with object-oriented programming principles, details of the implementation of the extended framework will depend on the particular extensions implemented by the framework user. Nevertheless, a representative implementation of the framework can be described in terms of the classes and methods defined by the present invention. We will describe the processing tasks performed by classes of the extended system in a procedural, step-wise fashion. The following description, therefore, should be understood to apply to the operating steps performed by the extended framework. Those skilled in the art, however, will understand that the flow of processing is not necessarily sequential through the flow diagram boxes, as objects will perform in accordance with their attributes and methods.

The framework classes define the physical and logical elements required to define, simulate and analyze the operation of Hydroprocessing Reactors under normal and scenario-based operating conditions. The Reactor Definition Document mechanism defines the underlying Process through attributes of Chemical Species, Reaction Networks, Fillings, Reactor Hardware and Upset classes. The Reactor mechanism supports the creation of a mathematical representation of the Process Reactor consisting of Components and Streams through parsing and validation of the Reactor Definition Document. The Simulation mechanism supports the simulation of the Process Reactor operation under the conditions specified by the Reactor Definition Document through the solution of the set of mathematical equations that describe the process and are implemented in the Reactor class. The Simulation mechanism also supports management and reporting of simulation results.

I. Reactor Definition Document Creator

The application to be described next is intended to allow creation of valid

Reactor Definition Documents. This application can become part of end-user Hydroprocessing Reactor Simulation applications. For the pmposes of this illustration, we will call this sub-program, the Reactor Definition Document Creator. Furthermore, the Creator will be described in terms of other smaller applications that define Chemical Species, Reaction Networks, Reactor Fillings, Reactor Hardware and Process Upsets. It is important to note that the Creator itself is a class that might not directly carry out all actions described here but simply be responsible for initiating them on the sub-programs.

The end-user needs to assemble first a list of the chemical species to be used in the simulation of the Hydroprocessing Reactor, a list of Reaction Networks that best describe chemical reactions between the selected species, a list of Fillings (i.e. catalyst types, inert pellets) loaded to the vessel, a list of Hardware comprising the Reactor and a list of Process Upsets to be simulated. Once the information is collected, the end-user can have the option of specifying all related information in a new Reactor Definition Document, modifying an older definition document or creating a new document through selection of "blocks" of information stored in a Relational Database System.

The user interface crafter by the application program developer can initiate new sessions by offering typical options such as "New" or "Open". In the first case, a new instance of the RD object is created in computer memory by calling the "new" method of the RD class. In the second case, a "new" instance of the RD object is created again and through the "Load" method of the Controller subclass of the RD class, document information is parsed, "related" classes are initiated and their attributes are set appropriately. It is important to note that when using the "Open" option, the Document selected is being locked to avoid

"collisions" with other users or other program instances of the same user. In this example, the term "file" should not be restricted to classical file-system reposition of the RD document. The developer for example, can select a Relational Database to Load/Store the Information contained in the document in a relational manner.

First, we describe the process of chemical species definition labelled 301 in FIG.18. The user interface developer can provide a list of available chemical species present in the Database System of the Property Predictor Package specified in FIG. 15 which is linked to the final application. From this list, through a drag-and-drop operation, the end user can select one or more species to add to the RD document. This operation initiates the "Add" method of the Chemical Species collection class of FIG. 4 and the initialization of the species characterization attributes needed by the Property Predictor.

Similarly, the application developer can provide user interface functionality that enables creation and/or modification of Reaction Networks (302 in FIG.18).

Each reaction network consists of a set of chemical reactions between species. The user interface can provide efficient methods for selecting the chemical species that act as reactants and products of the reaction through a drag-and- drop operation from the chemical species list defined in step 301.

The creation of the list of Reactor Fillings labelled 303 in FIG.17 is independent of the chemical species and Reaction Network definitions and can be done separately. The user interface can provide functionality for "adding" new types of fillings or selecting/copying existing types from a relational database and possibly modifying its properties.

Reactor Hardware definition labelled 304 in FIG. 17 can also be done by the user interface via functionality that either defines new objects or modifies objects selected/copied from a relational database of pre-defined objects. The user interface also can provide functionality that defines the "related" classes of each Reactor Hardware. For example, drag-and-drop operations can define the Reaction Network, Filling and Connectivity objects of the underlying Hardware.

Finally, the user interface can also provide functionality to define Process Upsets as shown in 305 of FIG.17. This can be done by appropriate drop-down boxes with available formulas (i.e. step, pulse and ramp) and lists of "available" Reactor Hardware attributes.

Given that the creation of the Reactor Definition Document described in FIG. 18 contains related classes, the sequence of Document creation objects is important. For example, when the user adds an Upset, the corresponding Reactor Hardware must already be part of the Reactor Hardware List. If it is not, then the user can temporarily "freeze" the Upset definition, initiate an addition of the desired Reactor Hardware, and continue with the Upset definition. Thus, the RD creation process of FIG. 18 can be executed in "loops" until the RD Document is complete and valid.

Once the user has completed inputting the Identity, Chemical Species, Reaction Networks, Fillings, Reactor Hardware and Upsets information via the user interface the Document Validator class can be used to check consistency. Upon RD Document validation, the user can initiate storage into persistent areas (file or RDBMS) through the Controller class method of "Save".

Thus, the use of the framework of the present invention allows application program developers to exchange messages and information between software and data objects and efficiently create valid Reactor Definition Documents for use in Hydroprocessing Reactor Simulation applications.

II. Reactor Simulator

The application to be described next creates a Hydroprocessing Reactor Simulator based on the information provided by the Reactor Definition

Document. This application is an example of end-user Hydroprocessing Reactor Simulation applications. For the puφoses of this illustration, we will separately describe the sub-programs of the Reactor Simulator; the Model Creator and the Simulation Runner. It is important to note that the Reactor Simulator itself is a class that might not directly carry out all actions described here but simply initiate them on the sub-programs.

III. Model Creator

The user interface crafter by the application program developer can initiate a model building operation by allowing the end-user to select an option such as "Build". This selection can check if a Reactor Definition Document object is available. If not, then the Creator can ask the end-user to select a document from the persistent area or call the Reactor Definition Document Creator described earlier to create one (401 of FIG. 20). Then, a new instance of the Reactor object can be created by calling the "new" method of the class as shown in 402 of FIG.19. Notice that, in an integrated application that includes the Reactor Definition Creator and the Reactor Creator, the developer can "dim" the "Build" option of the user interface until a RD Document becomes available or has been defined and validated.

Next, the Reactor Creator can parse the RD Document class using the Reactor Definition Parser of the Reactor class (FIG. 12 and FIG. 13) as shown in 403 of FIG. 19. For each Reactor Hardware in the RD Document, the parser can verify "knowledge" of the Hardware Type and existence of the Filling and Reaction Network objects if required by the Hardware Type. Upon validation, the Model

Builder class can be called and a new Reactor Component object can be initialized (404 of FIG. 19). The new object complies with OOP principles of polymoφhism for various Hardware Types and in some cases it might be a container of other elementary Reactor Components. Those skilled in the art will recognize that this process corresponds to the discretization of a domain and the transformation of a set of Partial Differential Equations that describe the system to a set of Ordinary Differential Equations. Upon initialization, object attributes can be set appropriately based on the Component Type (i.e. Filling, Reaction Network, Properties) and one or more outlet streams (depending on Hardware Type) can be initialized, related and added to the Reactor collection of Streams.

After parsing of all Reactor Hardware is completed, a Second pass (405 of FIG. 19) over the RD Document can parse the Connectivity Information provided. The Model Creator can then "relate" Reactor Component Inlet Streams attributes to the appropriate previously defined Outlet Streams.

In the above process, if the validation of the Reactor Definition Information is invalid (403 and 404), the Model Creator can "destroy" the Reactor object and return control to the end-user (for RD redefinition or correction). Those experienced in the art will recognize that FIG. 19 does not show "book keeping" operations performed by the Model Builder class (labelling, sorting, etc.).

II.2. Simulation Runner The user interface crafter by the application program developer can execute a Simulation by allowing the end-user to select an option such as "Run". This selection can first check the existence of RD Document and Reactor objects. If either one does not exist, control can be returned to the appropriate sub-program described earlier. This process is described as steps 501 and 502 in FIG. 20 and ensures that RD Document and Reactor objects are in sync with the simulation object. Those experienced in the art will recognize that object synchronization by this method is done for illustrative puφoses only. Furthermore, synchronization between RD Document, Reactor and Simulator objects becomes particularly important on the so-called "continuation runs" where the Process

Initial state is Read from persistent areas.

Based on the above, once RD Document and Reactor objects are validated and synchronized, the Upset Parser/Validator of the Simulator Model can be called (503 of FIG. 20). The parser can validate the collection of events and the other simulation parameters (i.e. start/end, continuation/new, tolerances) and either send control to the RD Document Creator if validation fails or initialize and give control to anew Simulator object (504 of FIG.20).

Those experienced in the art will recognize that the Controller object will first initialize the independent variables (i.e. Pressure, Temperature, Compositions, Content) based on RD user option via reading values from the results of an older

"compatible" simulation or by "applying" an initialization method. More specifically, initialization can be achieved by calling the over-writable "InitVars" method of the Reactor object with the appropriate parameters. Upon initialization, the Controller object can call the Equation Solver repeatedly and, based on end-user parameters, execute the simulation of the Process Operation from Start to End applying the Upsets in between.

Those experienced in the art will recognize that the "state" of the Reactor during the simulated period can be saved in persistent areas (i.e. files, RDBMS) by calling the appropriate Controller method as frequently as the end-user specifies. Furthermore, if the Equation Solver fails to converge at some point, control can return to the end-user for further action (i.e. Adjustment of parameters) with or without storage of the intermediate results (505 step of FIG. 20).

Finally, a result/report analyzer can be included as part of Hydroprocessing Reactor Simulation applications via integration of OOP specialized frameworks. The Controller class of the Simulator has the capability to export the complete

Relational Structure of the Reactor object and thus, allow identification of all time dependent values of Reactor attributes.

Advantages of the Invention

Thus, the reusable framework of the invention provides a set of objects that perform Simulation of Hydroprocessing Reactors and permit a framework user to add extensions to the framework for specific processing features, thereby producing a Hydroprocessing Reactor Simulation application for Hydroprocessing development activities. An application program developer can thereby more quickly conclude program development and maintain programs with updates and improvements. The developer must provide the end-user interface, which establishes a means for the end-user to communicate the application program to receive, process, and report data. The program developer is thereby free to concentrate on application program features, building upon the framework.

The embodiments and examples set forth herein were presented in order to best explain the present invention and its practical applications and to thereby enable those skilled in the art to make and use the invention. However, those skilled in the art will recognize that the foregoing description and examples have been presented for the puφose of illustration and example only. The description as set forth is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching without departing from the spirit and scope of the forthcoming claims.

REFERENCES U.S. Patent Documents References: 1. 5398336 Mar., 1995 Tantry et al. 2. 5446842 Aug., 1995 Schaeffer et al. 3. 5544297 Aug., 1996 Milne et al. 4. 5604892 Feb., 1997 Nuttall et al. 5. 5634129 May., 1997 Dickinson. 6. 5717877 Feb., 1998 Orton et al. 7. 5732229 Mar., 1998 Dickinson. 8. 5740425 Apr., 1998 Povilus 9. 5764897 Jun., 1998 Khalidi 10. 5768505 Juα, 1998 - Gilchrist et al. 11. 5778378 Jul, 1998 Rubin. 12. 5781732 Jul., 1998 Adams. 13. 5787283 Jul., 1998 Chin et al. 14. 5787425 Jul., 1998 Bigus 15. 5794001 Aug., 1998 Malone et al. 16. 5878432 Mar., 1999 Misheski et al. 17. 5913205 Jun., 1999 Jain et al. 18. 5930154 Jul., 1999 Thalhammer et al 19. 5936860 Aug., 1999 Arnold et al. 20. 6083276 Jul., 2000 Davidson et al. 21. 6220743 Apr., 2001 Campestre et al. 22. 6266805 Jul., 2001 Nwana et al. 23. 6314555 Nov., 2001 Ndumu et al.

II. Other References 1. Fixed-Bed Reactor Design and Diagnostics. Howard F. Race. Butterworths, 1990. 2. Engineering of Hydrotieating Processes. P. Trambouze. NATO ASI Series, Series E: Applied Sciences - Vol. 225, 1992. 3. Object Oriented Methods. Ian Graham. Addison- Wesley Publishing Company, 1991.

Claims

ClaimsWe claim:

1. A computer system comprising: a central processing unit; a user interface; and a main memory having an operating system that supports an object-oriented programming environment containing an object oriented framework that includes a plurality of predefined object oriented classes that may be extended by a user, wherein the framework provides a Multiphase Dynamic Hydroprocessing Reactor Simulation system for development and operation of a

Hydroprocessing Reactor, said Hydroprocessing Reactor being specified by a data object.

2. The computer system of claim 1, wherein the memory includes a hydroprocessing reactor definition mechanism comprising at least one category of cooperating objects including at least one object specifying at least one of a method and an attribute for at least one of creating, assembling, validating and controlling information contained in the data object specifying the hydroprocessing reactor.

3. The computer system of claim 1, wherein the memory includes a hydroprocessing reactor simulation mechanism comprising at least one category of cooperating objects including at least one object specifying at least one of a method and an attribute for at least one of simulating and analyzing a reactor design for at least one of screening and optimizing a reactor process factor.

4. An object oriented framework that includes a plurality of predefined object classes that may be extended by a user for use in a computer system having an operating system that supports an object oriented programming environment and which includes a memory in which cooperating objects comprising object classes can be stored, the framework providing an extensible Multiphase Dynamic Hydroprocessing Reactor Simulation system for development and operation of a Hydroprocessing Reactor, said Hydroprocessing Reactor being specified by a data object.

5. The framework of claim 4 further including a hydroprocessing reactor definition mechanism comprising at least one category of cooperating objects including at least one object specifying at least one of a method and an attribute for at least one of creating, assembling, validating and controlling information contained in the data object specifying the hydroprocessing reactor.

6. The framework of claim 4 further including a hydroprocessing reactor simulation mechanism comprising at least one category of cooperating objects including at least one object specifying at least one of a method and an attribute for at least one of simulating and analyzing a reactor design for at least one of screening and optimizing a reactor process factor.

7. A program product data storage device, tangibly embodying a program of machine readable instructions executable by a computer system having an operating system that supports an object oriented programming environment, the program product comprising: a recordable medium; and an object oriented framework recorded on the recordable medium, the framework including a plurality of pre-defined object oriented classes that may be extended by a user, wherein the framework provides a Multiphase Dynamic Hydroprocessing Reactor Simulation system for development and operation of a Hydroprocessing Reactor, said Hydroprocessing Reactor being specified by a data object.

8. The framework of claim 7 further including a hydroprocessing reactor definition mechanism comprising at least one category of cooperating objects including at least one object specifying at least one of a method and an attribute for at least one of creating, assembling, validating and controlling information contained in the data object specifying the hydroprocessing reactor.

9. The framework of claim 7 further including a hydroprocessing reactor simulation mechanism comprising at least one category of cooperating objects including at least one object specifying at least one of a method and an attribute for at least one of simulating and analyzing a reactor design for at least one of screening and optimizing a reactor process factor.

10. A method of distributing a program product, the method comprising the steps of: establishing a connection between a first computer system and a second computer system; and transmitting the program product from the first computer system to the second computer system, wherein the program product comprises an object oriented framework that includes a plurality of pre-defined object oriented classes that may be extended by a user, the framework providing a Multiphase

Dynamic Hydroprocessing Reactor Simulation system for development and operation of a Hydroprocessing Reactor, said Hydroprocessing Reactor being specified by a data object.

11. The framework of claim 10 further including a hydroprocessing reactor definition mechanism comprising at least one category of cooperating objects including at least one object specifying at least one of a method and an attribute for at least one of creating, assembling, validating and controlling information contained in the data object specifying the hydroprocessing reactor.

12. The framework of claim 10 further including a hydroprocessing reactor simulation mechanism comprising at least one category of cooperating objects including at least one object specifying at least one of a method and an attribute for at least one of simulating and analyzing a reactor design for at least one of screening and optimizing a reactor process factor.