1.0 Introduction
1.1 Terminology
1.2 Modeling Background
1.3 Framework Background
1.3 Framework Background
The world is traditionally compartmentalized with the flow of information from compartment to compartment. The basic conceptualization of the problem begins with a flow of information from beginning to end. If this happens to be over the "life cycle" of a 1) a person (e.g., conception to death), 2) a process (e.g., production life cycle), 3) an activity (e.g., certain job type), and 4) a compound (e.g., traditional U.S. Environmental Protection Agency risk assessment), a beginning and end can be defined, and, hence, a flow diagram can be constructed to link the individual components. Each of the “life cycles” listed above represents, in effect, types of frameworks. To capture the structural relationship among the principle components required in estimating human exposure to chemicals, multiple frameworks, representing existing legacy software, may need to be linked to provide the most scientifically defensible picture of the impacts to non-agricultural chemical exposure. Because the real world is compartmentalized, each of these life cycles are also compartmentalized, meaning that the various life cycles can be linked to address the demanding questions associated with the identification, facilitation, and communication of generic research that will characterize people’s exposure to chemicals and raise the confidence and lower the uncertainty for quantitative estimates of exposure associated with potential human effects to chemicals.
An abstract view of these various life-cycle "ribbons" is illustrated in Figure 1.3.
To meet this requirement for current and future situations, the CCEF design needs to have a System User Interface that is flexible enough to capture not only the current linkages of models and databases but also other frameworks (i.e., ribbons in figure) that provide the essence of relationships in general. These linkages need to be visual so the analyst can immediately construct and understand the problem. A visual interface is also very effective in conveying simulation results to various stakeholders.
A software framework integrates the different components of a modeling system to provide a consistent and efficient architecture to conduct scientific research and analyses. The components of a framework are 1) a user interface, 2) module and model types, and 3) system databases. This section will discuss the different aspect of these framework components.
The most effective interfaces, which are currently being used to help construct a conceptual site model, use a drag & drop approach on a workspace. Drag & drop is where a user double clicks on icons contained in an icon pallet, the selected icons appear on the work space, icons are rearranged and connected according to the flow of information (i.e., lines with arrows, indicating the direction of data flow), and the user chooses the most appropriate model from a list of models that represent the icon. This type of approach is fairly common and used by a number of successful frameworks (e.g., Stella, FRAMES, MMS, ARAMS, and GoldSim). The following figure illustrates the drag & drop work space for FRAMES (Whelan and Nicholson 2001).
With the Drag & Drop feature, the user will have an icon pallet from which to choose their modeling categories, which contain the choice of models. The user will have the ability to expand the icon pallet to include new types of models, databases, system supported software, or unique categories. The icon pallet will also 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. Typical icon categories for the standard EPA risk assessment paradigm is presented in Table 1.3.1 (pdf format). Micro-environmental modeling would have a separate Domain associated with it, as such it would have its own Classes, Groups, and SubGroups.
A module consists of a model
description, module user interface (i.e., input), and the execution
code (i.e., run model), which contains pre- and post-processors for converting
the models input/output for recognition by the model/system. The following figure illustrates these three basic components of a module.
The code description
provides what the model is, who you should contact for questions, what
information it consumes and produces, the connection schemes with other
models that it allows, how the model fits into the system and how it should
be perceived of by the system.
Figure 1.3.2
The user would have the option of listing modules by alphabetical order or by conceptual site model sequencing. For example, under the Chemical Life Cycle paradigm, the modules are sequenced and grouped by source, fate and transport, and human exposure/intake/effects, which follows the intuitive conceptual site model development structure. Also, when viewing the conceptual site model, the user would have the option of hiding the connections between the Database icons and Simulation Modules, to help reduce the number of connecting lines that would be on the conceptual site model screen. The connections would still be there, only the user could choose to not show them.
1.3.1 System User Interface
The conceptualization of the problem is the conceptual site model, which represents the analyst’s understanding of the problem, problem components, spatial relationships, and flow of information among components. The real world is very complicated and the traditional way to approximate the real world is to simplify and compartmentalize it into more manageable "pieces." These generally represent what we understand, tending to group all of the things that we do not know or understand into a selected group of parameters; hence, our conceptualization of the real world tends to be a function of what we know and understand. The intent of the CCEF is to design a framework that allows this conceptualization to change and grow more sophisticated as our understanding of the real world grows, so we may more accurately estimate the impacts associated with our anthropogenic activities.
1.3.2Model vs. Module
A model or code is the mathematical representation
of a process, device, or concept (Sippl and Sippl 1980) coded into a computer
language for execution on a computer, which is consistent with current
preconceived notions of what a model is intended to represent.
shows that the Module User Interface, input files, and executable
are separate from each other. By separating these, any Module User Interface associated
with a legacy code can remain unchanged, so the user will see no change
from expectations developed when they used the original code outside of
the framework. The input may come from the user, which is traditionally
associated with the Module User Interface, database(s), and upstream models supplying boundary
conditions. By distinctly separating the input from the executable,
sensitivity/uncertainty analyses on the input data is possible.
As such, batch files can be established for multiple runs. Finally,
the execution code is represented by the legacy code and its pre- and post-processors.
The pre-processor converts the input data that the system recognizes into
a format that the model recognizes, while the post-processor converts the
model output into the standardized system format.
1.3.3 System Databases
Specific databases would be available for user choice, as multiple databases may be required to meet the needs of a model. Upstream data are accessed by down stream connections in the conceptual site model (i.e., an inherent priority is built into the system), and all of the linkage protocols establish procedures to "access" executables and files containing data. Because the conceptual site model is only a vehicle for communication, the modules require information to complete datasets, which may be fulfilled by multiple databases; as such, the icons are linked to databases to complete a dataset, although the dataset may only be partially completed with the available databases.
