Title Page

1.0 Introduction
1.1 Terminology
1.2 Modeling Background
1.3 Framework Background

2.0 Literature Review

3.0 Model Framework

4.0 Scenarios

5.0 Qualitative Analysis

6.0 Recommendations

7.0 References

Appendix A

1.2 Modeling Background

To meet the current and future intent of the CCEF, as stated by the requirements, six development goals will be considered when formulating the design of the CCEF:

1. Provide a platform that allows "objects" to access information generated/produced by other "objects."  For example, a model or database produces a set of data for consumption by another model.  The downstream model accesses the information it needs and expects from the upstream model or database, but it does not have to accept all of the information.  There is no requirement on the consuming model to utilize all of the information that is made available to it.  A consuming model should not have to consume information that it does not use.

2. Keep it simple, not simplistic.  By definition, simple means "easy to understand, deal with, use, etc" (Barnhart 1970).  Simplistic refers to "making complex problems unrealistically simple" (Guralnik 1976).  One of the major problems associated with other frameworks that never became deployable is that they could not capture the essence of the problem that they were trying to solve.  The elegance of a simple design is that it captures the essence of the problem without burdening the user with unnecessary extraneous information or components.

3. Make it understandable (shared responsibility).  A simple design allows for the developers and users to understand the design and structure of the framework.  Not only that, but to maximize the ability for two disparate components to seamlessly communicate, each component must share in the responsibility for communication.  For example, who should be charged with transferring information from a database to a model:  the database owner (i.e., information producer) or the model owner (information consumer)?  It is not the responsibility of the model owner to understand the structure of the database; likewise, it is not the database owner’s responsibility to understand the model that is consuming the data.  Therefore, each owner must share some of the burden to ensure that the appropriate data are transferred to the model in a form that the model understands.  This philosophy is applicable for communication between all types of components (e.g., models, databases, and other frameworks).

4. Develop consistent and repeatable protocols.  By developing a conceptual consistency in the design of the system, the design of the framework is more easily understood by those who use it.  For example, all databases should link to models in the same manner.  In addition, since models, databases, and other frameworks can be considered "objects" in this system, the conceptual philosophy for linking any object should be similar.  By developing repeatable protocols, software developed for one aspect of the system can by reused to support other aspects of the system.  Reusing the same software results in a simpler QA/QC program, easier maintenance, and more universal trouble shooting, as one fix corrects many problems.

5. Identify the MINIMUM linkage information.  All models have been developed to solve specific problems in certain way, regardless of how generic the models are.  As such, each model requires "typical" and "unique" data.  Typical data include information expected from an upstream model or from a database.  Unique data tends to be user supplied and tends to be unique to that model. For example, an atmospheric model may expect emission rates from a source-term model, joint frequency distributions, and the number and types of surface disturbances from the user.  When linking to an upstream model, a minimum set of information is traditionally expected to be made available by that upstream model.  If the two models want to communicate, they must agree as to what that minimum set is because neither model wants to have to produce or consume unnecessary information that is irrelevant to its design.  Focusing on the truly relevant data requirements helps to ensure a higher probability that two models will be able to communicate.

6. Recognize that this is an iterative process to meet these goals.  A well-designed framework will have the ability to solve today’s problems, yet contain the flexibility and robustness to be modified to address future problems.  This is not to say that the framework needs to include unnecessary components, but the design should contain the structure to allow it to be modified to account for new models, new data, new parameters, etc., yet maintain backward compatibility for the components existing in the system.  Each problem requires a unique solution; therefore, the framework needs a design that expects change.