Title Page

1.0 Introduction

2.0 Literature Review

3.0 Model Framework
3.1 Objectives
3.2 Approach
3.3 Requirements
3.4 Design
3.5 Data Exchange Protocol

4.0 Scenarios

5.0 Qualitative Analysis

6.0 Recommendations

7.0 References

Appendix A

3.4 CCEF Design

3.4.1 Task and Sequence Manager

• Manages scenario being analyzed and sequence of modules being executed
• Provides information on a global basis which includes scenario-specific information
• Manages feedback between modules.

• Computational code and algorithm
• User interface
• Pre- and post- processors (if needed)
• Module-specific databases (if needed).

• Boundary condition information for next module downstream
• Common format and data protocols so all other modules know how to read
• Minimal amount of information.

3.4.2 Client Side

1. Concepts of a Framework - Architectural differences between a framework, model and module are discussed
2. System User Interface - system interface is proposed for CCEF, which represents forum for visually describing conceptual site model, is presented. conceptual site model is a mechanism to convey problem to user in graphical form. System User Interface directly interacts with user, so is very important to ensure is user-friendly and relatively intuitive
3. Data Exchange Protocols - data transfer protocols describe foundation upon which data is universally transferred throughout system. These protocols represent heart of CCEF
4. Sensitivity/Uncertainty Considerations - Utilizing data transfer protocols, section discusses how sensitivity/uncertainty models and parameter estimation models can be incorporated into system
5. Model Space and Time Considerations - Protocol for disparate models in both space and time are discussed
6. System Integration Tools - To help facilitate ability of linking disparate models, databases, and frameworks into Comprehensive Chemical Exposure Framework, a series of system software helpers (i.e., “editors”) are required to step model or database developer integration (and application) process
7. Server Side of CCEF - Software tools, which allow user to link to remote models and databases, are presented
8. Lock and Key - Software tools, which allow a user to fix conceptual site model by locking icon types and connections between icons, and lock models are available under each icon
9. Summary of CCEF Design - A summary of design, requirement-by-requirement, is presented.

The concept of developing a Framework, as opposed to a model, is critical in design philosophy of a technology software system, which meets needs outlined by requirements. Models are designed to perform a specific set of calculations. Although models exist describe a given real-world phenomenon (e.g., fate and transport in aquifer, exposure to contaminated sediments, etc.), a model can also be composed of many parts (e.g., LifeLine, CARES, TRIM, HWIR, etc.), which does not lend itself as a mechanism to link disparate components together to more accurately describe a solution to problem. Framework takes on responsibility for connectivity, while model takes on responsibility of consuming and producing information as part of assessment.

For example, Figure 3.4.2.1 presents an example of a standard U.S. Environmental Protection Agency risk paradigm for performing a multiple media risk assessment, linking source, fate & transport, exposure, and risk/hazard (http://www.epa.gov/epaoswer/hazwaste/id/hwirwste/risk.htm). The ellipsoids provide examples of models (e.g., “modules” in figure). The essence of the Framework is represented by arrows connecting the models (i.e., modules). The protocol for transferring information from one model or database to the next is the responsibility of the Framework. The choice of the model, which represents the best solution to problem, is the responsibility of the analyst or the user. The Framework should take no responsibility for what happens inside of the model but takes full responsibility to ensure data consumed and produced are appropriately provided to the next model in line, and models fire in the correct sequence. The Framework controls the flow of information but not how the information is used.

By utilizing this approach in defining the difference between models and frameworks, solutions to problems can be designed to best meet the needs of the client. For example, Figure 3.4.2.2 illustrates how best the features of micro-environmental exposure modeling can be combined with the U.S. Environmental Protection Agency's standard fate and transport, exposure modeling. In this example, the analyst is interested in using a micro-environmental model to track ramifications of chemical exposures, including a discrete (i.e., short period of time) exposure from a nearby waste site. Because fate and transport models and their results are considerably more accurate, using standard risk assessment approaches, than those inherently included in micro-environmental model, they can be linked to the micro-environmental models. A similar design could be established when a more accurate lung model is needed to produce/consume information for/from the micro-environmental model. Not only that, the user could set up a comparison between two different micro-environmental models to determine differences between them using the same input data, and which ones would best meet the needs of problem.

Figure 3.4.2.2 also illustrates that databases can be viewed in a similar manner as models. Using this design, any database can be linked to any model, and the user is free to input user-specific information. As with linking models, any database can be linked to any other database. For example, if a site-specific database lacks necessary information to fulfill all of needs of a model, regional and national databases could be linked to site-specific database to fill gaps that might exist, prioritizing data, where appropriate.

As an illustrative example of design, four exposure scenarios have been identified for conceptual analysis; definitions of each are presented in scenarios section. Typical information flow diagrams, used to describe these four exposure scenarios, are presented in Figure 3.4.1. Figure 3.4.1 illustrates connectivity from source term through risk with boxes representing models and ellipsoids representing information flow between models. Framework concept can easily be expanded to four exposure scenarios, outlined in scenarios section, with each information flow diagram described therein.

Using Scenario 3 as illustrative example, a process flow diagram as illustrated in Scenario Model 3 Flow Diagram, can be developed to describe the process of implementing occupational exposure of VOC compound Group D (benzene, toluene, and n-hexane) to adult male. In the process flow diagram, algorithms and models can be used to describe each of the boxes, and these process boxes can be matched to information flow diagram, to provide substance behind source, fate and transport, and effects/impacts modeling.

3.4.3 Design Associated with System Functionality

Comprehensive

• Application Programming Interface represents protocol to communicate with Dynamic Link Libraries, which control flow of information between components within system. This requirement covers and is related to a unified data exchange protocol, which covers specific spatial and temporal data-file specifications at boundary conditions between modules and general design associated with input./output, system read only, system write, and system conversions.

  Application Programming Interface, using a series of Dynamic Link Libraries, will be utilized to transfer information between modules and between modules and databases. DICtionary files will describe characteristics of data to be transferred and boundary conditions link modules together. Data transfer will be through Dynamic Link Libraries, where quality of data can be inspected. Four universal data Application Programming Interfaces have been identified to support data exchange protocol:

  A. Input/Output - input/output Application Programming Interface shall consider
  • range checking of parameters with storage of information
  • data retrieval
  • data storage
  • units checking
  • open/close data sources
  • monotonic checks (e.g., time in a time series)
  • meta data functions [cardinality, units, definitions, type (e.g., real, integer, etc.), number of elements, etc.]
  • automatic call for conversions (e.g., units conversion)

  B. System (Read Only) - System Read Only Application Programming Interface shall consider
  • error handling functions (e.g., assertions, errors, and warnings)
  • Command line functions (not standard in FORTRAN)
  • producer/consumer relationships
  • conceptual site meta data (e.g., type, qualifiers, counts, available models, description files, Domain, Class, Group, SubGroup)
  • Read note

  C. System (Write) - System Write Application Programming Interface shall consider
  • setting arguments
  • setting producer/consumer relationships
  • creating a new module
  • locking/unlocking conceptual site models
  • model selection
  • calling and running interfaces and models
  • Run calls between models
  • move icon placement routines
  • Call-back when error occurs
  • adding notes

  D. Conversion - Conversion Application Programming Interface shall consider
  • a list of available units

• The design of CCEF allows for multiple perspectives when solving exposure problem. By utilizing this approach in defining difference between models and frameworks, solutions to problems can be designed to best meet needs of client.

  For example, best features of micro-environmental exposure modeling can be combined with Environmental Protection Agency's standard fate and transport, exposure modeling. In this example, analyst is interested in using a micro-environmental model to track ramifications of chemical exposures, including a discrete (i.e., short period of time) exposure from a nearby waste site. Because fate and transport models and their results are considerably more accurate, using standard risk assessment approaches, than those inherently included in micro-environmental model, they can be linked to micro-environmental.

  A similar design could be established when a more accurate lung model is needed to produce/consume information for/from micro-environmental model. Not only , but user could set up a comparison between two different micro-environmental models to determine differences between them using same input data, and which ones would best meet needs of problem.

• Software linkage tools allow for communication between host (i.e., local) and remote systems (i.e., running models remotely or accessing data from remote databases). relationships between Linkage and Module Servers, Host Client, and Remote Databases and Models are presented in Figure 3.4.3 (below).

  The explanation of Figure 3.4.3, as it relates to components comprising server side of CCEF design is presented in the Appendix. The various editors represent software for accessing remote databases. The Model Owner Tool, Module Execution Tool, and Remote Module Client represent software for accessing and running remote models (i.e., remote computing).

• The design of the CCEF would allow the user to store and access files, programs, databases, and models on different systems and in directories are different than those housing executables.

• With the advent of Dictionary files and a system-based Application Programming Interface, the fundamental responsibility of the framework shifts from being model-oriented to being object-oriented, where the framework is charged with the transfer of information between components and not what calculations are being performed within each component. In other words, the framework is associated with arrows connect models and databases, and not what is inside of the models and databases. The models and databases are the responsibility of the technical users and researchers. Because of the object-oriented approach, the frameworks can be viewed as just another object with specific inputs and outputs. The

  tiered icon system allows for the CCEF to link to outside frameworks, especially those at remote locations. The icon pallet includes a Class for Frameworks, both Closed and Linkable, and therefore, represents the icon choice under Class type. If these Frameworks have correct linkage specifications to communicate with other icons, then they could be pictorially connected directly to those icons. It is anticipated that Frameworks could be located in different directories, as a "remote" application. The server side of CCEF design accounts for linkages to remote locations, where models, databases, or other frameworks might be housed. Frameworks would be linked with the system in a manner in which all components are linked, using Application Programming Interface with the consuming and producing Dictionaries.

• Different databases will be represented by different icons. Datasets are slightly different from models. Under the Class of Database, there will be two Groups: System and Module. System refers to those databases that all modules have access to. The Module identifies those databases that can be specifically connected to certain icons. Under the Group or SubGroup, specific types of databases are identified (e.g., eco-benchmarks, physical properties of chemicals).

  If the system provides a database, it has responsibility to "support" the database. This means the system developers (i.e., system) are responsible for the content of the database and to ensure that the database is consistent and conforms to the description files, dictionary files, and Date Client Editor specifications and linkage protocols; therefore, the Date Client Editor, dictionary and description files are system's responsibility.

  A system database (i.e., original database) can be located on the local server or at a remote location. As with models, anyone can "access" a new database, not supported by system (i.e., system developers), but supported by someone else. They can "add" functionality to access the new database. Note this procedure is similar to someone adding a new model to system, a model is only applicable to their needs. To add a new model, the developer addresses protocols for a dictionary file and description file. The main difference between model-based icons and database icons is the linkage information between the model icons must be complete, but the linkage information between a database icon and other icons can be incomplete, because the database may not be able to service all of the data needs of the model.

  System databases are supported by the system (e.g., chemical or lifeform lists). To a certain extent, the system also services and supports the content of databases. For example, if the analyst is implementing a chemical assessment, all of the modules need to know what the chemical is; otherwise, all the modules will expect a different name and identifier, and none of the models will understand which chemical is being passed. This information is global and needs to reside in a system database. Currently envisioned system databases will be separated out from module databases. Because system databases are global, they do not need to be physically linked into the conceptual site model as they are already available to all modules in the system.

  Module databases are module specific and those databases are linked directly to models to which they will supply information. These databases are identified through traditional Drag & Drop features of conceptual site model work space. These Module databases (which constitute linkages to databases outside system) are not supported by the system but link into the system through editors, which are system-supported, universal software works for most well-structured and -designed databases. These "other" databases support specific models or model types. The Date Client Editor is database-specific and has a specific dictionary file associated with it. These databases are akin to models in thesystem. The system takes no responsibility for the models, only ensures that when specifications are met, the information is transferred properly. The same is true for the databases. In effect, the module-linkage philosophy is being reused for database linkage.

• transfer of information from a database to a downstream icon (module or another database) conceptually can be viewed the same as when two module icons are linked. When two modules are linked, the producing (i.e., upstream) module, provides information and stores it in a location the consuming (i.e., downstream) module can access. The downstream module reads the file and transfers data for its consumption. In effect, the downstream module "takes" the data needs from the intermediate file. Conceptually, it is important to note the upstream module DOES NOT populate downstream module. Similarly, when two database icons are linked, the upstream database does not populate downstream database. In reality, the upstream database populates intermediate file, which the downstream database accesses and only utilizes those data which do not overlap with its own data. In effect, downstream database takes those data only fill data gaps in its database. This implies there is priority associated with the data. In other words, the data in downstream database has priority over the data in upstream database.

  For example, when linking national and regional databases, the national database would be associated with upstream database icon, and the regional database would be associated with the downstream database icon. Under this situation, regional database would populate its data gaps with data from the national database. The conceptual site model icon linkage sequence would have a national database icon linked to a regional database icon linked to module icon. Because the regional database and module icons are directly linked, the user is being informed that the most detailed and appropriate data are being used in assessment, that is, the regional database is the primary database supplying information to module. The design for this requirement will be enforced for each system-supported Date Client Editor. This will also be strongly recommended for each Date Client Editor not supported by the system (i.e., developed by those not representing the system).

• The essential spatial information required to define conceptual site model is passed, via th edictionary data file specifications, containing all the spatial modeling data. The dictionary files have been structured to allow for the model developer to specify those parameters that are spatially aware. Data are spatially aware, when they have been designated as having a Location index, constituting coordinates of vertices associated with a polygon. Clear distinctions have to be made between spatial system data (i.e., spatial layout of components, such as sources and receptors) and non-spatial model data (i.e., porosity, temperature, Kds, toxicity, age, etc.). The spatial data entered through the conceptual site model Graphical User Interface is divided into three object categories: points, lines, and polygons, all requiring coordinates of their vertices.

Modular

• The fundamental responsibility of the framework is associated with the arrows connecting models and databases. Those arrows represent the transfer of information from one component to another. The system is charged with managing the model and database linkages, firing sequence of models, and data transfer between components. The system is not responsible for what happens within models. The key to a successful transfer is to ensure the producing component provides information and meets the needs of the consuming component and the information is in a form that is recognizable by both components. This shared responsibility for managing data transfer is based on datasets, whose meta data information is described by the Dictionary files. Data specifications, between communicating models, represent the "contract" between what the upstream model produces and what the downstream model consumes.

  The Application Programming Interface and Dictionary file design allows for the "Plug & Play" feature, which is the most important feature of design. By ensuring Plug & Play, CCEF inherently includes the ability to
  • link any type of model, database, or framework into the system to communicate with any other component.
  • allow model developers, government organization, private companies, etc. to incorporate their own models and databases into the system without the necessity of going through the system developer as a middle-man.
  • ensure backward compatibility between legacy models and databases, and new models and databases.
  • allow linkage specifications to change with time and company.
  • link to remote databases or models.
  • link to remote frameworks, without having to integrate remote frameworks into CCEF.
  • link to remote databases and only download information necessary for assessment.
  • integrate change into system without having to redesign components are already included in system.

• The basic design of the CCEF allows for data to be imported to or exported from system at specified locations correspond to the Dictionary files. A user can also enter the system at any specified location, and they do not have to begin with a source module. Importing a file is different from importing a file that meets the specifications of a Dictionary file. System will allow for access into system though boundary conditions between icons. The imported information may be provided by a module, file, spreadsheet, etc. Regardless of importation mechanism, information must match the Dictionary file information (e.g., boundary condition file specifications associated with the boundary condition or system specifications), where appropriate. For example, chemical names must coincide with those recognized by system.
• The icon pallet in the System would be designed to expand into unlimited number of tiered levels. Because usability is severely compromised when too many tiered levels are at disposal of the user, only four main levels will be utilized in the first version of the system with first level or Domain being icon-less level identifies type of assessment being performed [e.g., Chemical Life Cycle, Travel Life Cycle, Human Life Cycle, Process Life Cycle, Activities Life Cycle, Idea Life Cycle, or some other unique Domain].
• The icon pallet in the System will allow for the unlimited number of icons from which to choose. The design is to have a vertical scroll bar from which the user can choose the most appropriate icon. Text will be permanently visible with all icons.
• With the Drag & Drop feature, the user will have the icon pallet from which to chose their modeling categories, which contains the choice of models. The icon pallet will be tiered, so intricate divisions in simulations can be captured. For example in transport and fate, surface water modeling can be divided into rivers, lakes, reservoirs, estuaries, bays, oceans, etc. Exposure route modeling can be divided into inhalation, oral, and dermal contact. The icons and icon categories can be changed to meet whatever need is identified. The standard Environmental Protection Agency risk assessment paradigm and micro-environmental modeling would have separate Domains associated with it, as such would have its own Classes, Groups, and SubGroups.
• The icon pallet is designed to allow new module icons, in addition to expanding icon list.
• Using Application Programming Interface, the linkage of disparate models in space and time will follow approach outlined elsewhere in document. The linkage will occur through boundary conditions. Supplemental linking software will be provided for those consuming models that do not have a protocol for converting information from a producing model.

User-Friendly

• The System will be designed to operate on a PC, with Microsoft NT or Win2000 platforms with a minimum of 128MB RAM Pentium or equivalent, and 1GB free disk space.
• The System should at least support latest versions of Borland C++ Builder, Microsoft Visual C++, Lahey FORTRAN-90, and Digital Visual FORTRAN-90 compilers. Supporting these compilers are not necessarily issue, unless the number of compilers propagate to unmanageable number, as Application Programing Interface calling conventions in Dynamic Link Library are a function of compiler. The users need to meet the standard calling convention to Application Programming Interface.
• The CCEF would provide a standardized set of reports and plots correspond to typical information currently requested from assessments (e.g., time-varying concentrations at a location, spatially varying concentrations for a given time, probability of excedence versus risk, etc.). The user would also have theability to link model-specific unique graphical and tabular interfaces (e.g., report generator and Environmental Protection Agency's RAGS Part D tables). These features would be associated with the Viewers.
• The first version of the System will print, as a minimum, tables and figures, designated as system Viewers. A print feature will be available to print on-screen information (e.g., conceptual site model), viewers, tables, figures, and files.
• The HTML procedure will be utilized to provide on-line help for system components. The models are the responsibility of the modelers. The linkage specifications are the responsibility of the system. On-line help for system components will be provided such that links back to a standard "document" containing necessary information, which lends itself to be updated and modified independent of software system. On-line help would include Date Client Editor associated with system-supported databases, interface requirements at boundary condition (i.e., system-supported, user-specified boundary conditions). System databases would also need a database editor for system-supported databases.
• A Units Conversion Dynamic Link Library will be provided to ensure models work with their specific units and all conversions between models will be handled by the system. The Data Owner Tool and database server will include units with database information.
• A conceptual site model work space, similar to that exhibited by FRAMES, GoldSim, or MMS will form the basis for representing user-friendly graphical interface. This interface would be developed using Visual Basic, possibly American National Standards Institute C, or Java.
• The Drag & Drop design will be incorporated into System. The System will allow a user to develop a conceptual site model with Drag & Drop features, similar to existing state-of-the-art graphically based interfaces (e.g., Stella, FRAMES, ARAMS, GoldSim, MMS, etc.).
• Based on Input and Boundary Condition Dictionary files, a summary of data requirements will be made available for models chosen under conceptual site model.

Multi-route

• The design of the CCEF promotes the ability of the system to respond to the user-specified conceptual site model are applicable to exposures via inhalation, oral, and dermal contact with consumer products. If models, databases, or frameworks exist, which provide adequate description of these exposures, then the framework allows for the user to address these conceptual site models. The user could use the Environmental Protection Agency standard risk models, which typically integrates exposure routes and pathways, not modularizing them by inhalation, dermal contact, or inhalation.

Multi-pathway

• As with exposure routes, the CCEF design promotes the ability of the system to specify, not only exposure route but, specific exposure pathways associated with the route, for example when a more accurate lung model is needed to produce/consume information for/from micro-environmental model for air-to-lung exposures. The CCEF design allows the user to design the conceptual site models within conceptual site models to telescope into the problem and allow for most applicable tools to be used to solve the problem.

Multi-source

• The design of the CCEF anticipates the transfer of data associated with multiple constituents from one component to another within the system. The design promotes not only the ability to transfer the degradation/decay products but allows the user to chemicals and lifeforms when data associated with those classifications do not exist. The framework provides the model developer with the ability to transfer computer synergistic or other forms of impacts from exposures to multiple constituents.
• The Data Client Editor will allow for the aliasing of chemicals and/or life forms, where appropriate. If the database is supported by System, then the Data Client Editor is supported by the system. If a new database is added to the system and is not supported by the system but is unique to support a given module, then the Data Client Editor is the responsibility of the database and module owners. A Data Client Editor would need to be written for each of modules. The Data Client Editor will allow for surrogates on chemicals and lifeforms. Data Client Editor will allow the user to change any value at any point in time. If the user changes a value, a reference note will be invoked, tracking and noting the value was "Entered by User." The Data Owner has the responsibility to provide a reference for every value in the database. When extracting data, data editors will have the functionality to extract references.

Varying Duration

• Time can be handled in several manners within the design of the CCEF. The information is provided to the models has aspect of time associated with it, and the models themselves are designed with respect to a particular reference time:

  A. The CCEF design allows for time-varying concentrations or doses to be expressed in fractions of seconds, minutes, hours, days, years, or millennia. Each model, especially numerical models, calculate time stepping and have a nodal-spacing mesh are consistent with their own model, while ensuring numerical convergence and stability. Temporal considerations for linking models with disparate time-stepping requirements are independent of any model. To remove model-specific time stepping from dictating manner in which models communicate, each of model's time-stepping requirements are accounted for when passing information between models. Each producing model will provide time-varying output corresponding with each producing model's area-based polygons, if polygons describe boundary interface between models. The time-varying output from producing model is a function of time steps used in generating time-varying curve. system does not know if time information between data-points on time-varying curve is linear, constant, nonlinear, etc., as such, each producing model's time-varying curves will have their own time-stepping protocol for each parameter for each polygon. When consuming model maps producing model's polygon outputs and transfers information from producing model's gridding system its own, the consuming model is responsible to account for time-stepping system producing models provides.

  B. The models are inherently designed with respect to a particular reference time. For example, the standard Environmental Protection Agency's risk paradigm assumes long-term, chronic exposures in their assessments. Acute exposures traditionally are not part of SUPERFUND calculations and Risk Assessment Guidelines for SUPERFUND (RAGS). Models that are designed for acute exposures would typically expect time-varying data from producing models or databases, which are consistent with design of model. For example, the upstream model produces the time-varying output in thousand-year increments that would not be a good candidate to link to acute exposure model expects variations in data in terms of hours. The CCEF design allows for the Dictionary files to be designed to specifically filter acute versus chronic forms of information. As an example, the air pathway traditionally has Dictionary files that are specific to Gaussian, sector-averaged models and a different set associated with puff models. A similar solution to the problem can be implemented for other components in CCEF.

Accurate

• Each model or database inherently contains implied assumptions that are not always known as a priority by the user. Similar models do not necessarily produce similar results, as developers tend to factor unintended differences into their models. By coupling the Plug & Play features with Drag & Drop approach, the CCEF design provides the user with the ability to directly compare ramifications of different models or databases are intended to have the same functionality. The user would have the ability to benchmark these models or databases to support more accurate assessments by allowing the analyst to the determine most appropriate components for addressing the problem.
• The CCEF design allows the user to select the most appropriate state-of-the-art estimation methods and databases to estimate or reasonably overestimate the "ground-truth" of the actual exposure. The framework is flexible enough to allow the user to also select the most appropriate time and spatial requirements. The modularity of CCEF design supports the notion that the best science-support tools can be utilized to more accurately address the problem at hand.
• A Password-protection system will form the basis for allowing the user to lock the conceptual site model (i.e., icon picture screen) and/or the model selections associated with each icon. To provide the ability to easily reproduce the standard assessments, the CCEF design will incorporate lock and key features that allow a user to: a) fix the conceptual site model by locking icon types and connections between icons, and b) lock the models that are available under each icon.

  The user should be allowed to choose either option or both options together. The first option implies the conceptual site model picture (i.e., user-defined icons and connections) is locked and the user cannot make new connections between icons. The second option restricts models that are available to user, greying out those models that are not allowed as a choice. Lock and Key software shall
  a. allow for a user option to have the conceptual site model locked.
  b. allow for a user option to have the models beneath icons locked.
  c. allow for a user option to have the conceptual site model and models beneath icons locked.
  d. allow for a user-defined password
  e. allow for use of no password.
  f. include algorithms that will alert users when source codes have been modified when system is locked.
  g. include algorithms that will prevent users from using modified source codes when system is locked.
  h. design the CCEF so the framework works the same, regardless of whether the lock-and-key option is implemented.

Open Code

• The design of the CCEF is based on the premise all software associated with framework is nonproprietary. This does not, though, preclude the user from linking the proprietary software into the system.
• The design of the CCEF allows for the inclusion of commercial-off-the-shelf software (e.g., Risk*Assistant, Risk*Works, LifeLine, LCAdvantage, etc.).
• A file will be available for documenting scenarios. The "Pop-Up Notes" will be used to document module assumptions by using the "Right Click" feature. Summary files and tables will be generated summarize assumptions used in problem. The user will be allowed to modify data retrieved from a database using Date Client Editor at time data are retrieved. The user will also be allowed to view, but not change, data in module user interface of modules database icons are connected to. A file will be developed to document assessment name and associated files, assumptions of assessment; conceptual site model; databases and models chosen for assessment; descriptions of databases and models; input requirements, descriptions, and references for data; dates and versions of databases and models, etc. This may be HTML file. Some of this information may be captured in a report generator, which summarizes the assessment.

Probabilistic

• Using Application Programming Interface design and the Dictionary files, the System design allows for multistage sensitivity uncertainty analyses by allowing sensitivity uncertainty modules to be connected to the framework at multiple specified locations. For example, the sensitivity uncertainty module could be connected to outside of module, representing a framework, which contains sensitivity uncertainty module. In other words, one could literally link the sensitivity uncertainty to frameworks, treating them as objects, or one could place them inside the Framework conceptual site model, treating sensitivity uncertainty as the object. Sensitivity uncertainty models could also be nested with sensitivity uncertainty modules, as long as appropriate Dictionary files are compatible.

Dose-response

• The design of the CCEF allows the user the ability to link in the most appropriate models and databases to convert exposure estimates to corresponding dose and risk values, whenever appropriate. The system also allows the user to view these estimates with either system or unique graphical or tabular viewers.

Mass-conservative

• One of the linkage requirements of each model, where appropriate (e.g., transport models) will be to report total mass leaving module. This information will be the responsibility of the module not the system. The system will only pass this information along to downstream modules and user. This is a requirement of every model in the system to conserve mass and account for mass balance in their model. Each model is responsible to ensure mass is conserved within its system. As a minimum, the system will provide to the user, if produced by the module:
  a. total mass exiting, associated with each of its boundary conditions [i.e., leaving system through a particular mechanism (e.g., leaching, volatilization, suspension, runoff, etc.].
  b. mass flux rate versus time for boundary conditions requiring mass flux rate.
  c. mass versus time remaining in module.

Figure 3.4.3 CCEF Design Relationships between Linkage and Model Servers, Host Client, and Remote Databases and Models

Return to text.