Definition of unconfigured vs configured model

This page is being used to document the discussion regarding the accepted terminologies for unconfigured model vs configured model (ticket:888) . Additional discussion can be found on the ticket:868 web page. We'll amalgamate this stuff as soon as is practicable.

I have copied in the current understandings of the terms to date:

1) Unconfigured model = component tree minus the binding information Configured model = component tree with binding info VS

2) Questionnaire Output:

Unconfigured model:

  • A model component tree with DEFAULT parameters set (one value not a range)
  • Input/Coupling? bindings identified

Configured model:

  • The unconfigured model tree document
  • An additional document listing the changes to the parameters for a particular simulation

3) Curator:

  • Our goal is to come up with an agree upon definition that will inform the CIM and how the CIM is used in the future. The questionnaire is an artifact and not a true representation of the CIM. We should be careful that Questionnaire-isms don't effect future structure.
  • This discussion is primarily about what the CIM XML looks like and how that structure travels "backwards" to inform the CIM itself.
  • Unconfigured model:
    • A model component tree that includes the range of choices a particular parameter can take
    • The different software architectures a model can run on
    • The fields within the model and whether they can be imported, exported, or both
  • Configured model:
    • Synonymous with simulation
    • A model component tree with the specific parameters set for the simulation identified
    • The platform used in the simulation identified
    • The Input/Coupling? bindings identified

Here is how I think CIM1.5 fits into Curators view.

CIM1.5 does not directly capture the range of choices that a component property/parameter can take, or any constraints in component and property hierarchy. Instead CIM1.5 captures the actual choices that have been made. CIM1.5 therefore captures a configured model in terms of property values and component hierarchy. Valid choices (and hierarchies) are defined by an external controlled vocabulary and associated constraints.

I do not believe that CIM1.5 allows one to say what valid software architectures a model may run on.

One can use CIM1.5 to describe a software interface so it can capture information about data (fields) that can be in, out or inout. OASIS4 already uses the CIM to do this. However, there is plenty of information that it does not capture e.g. datasizes, datatypes, partitions and model behaviour.

CIM1.5 separates the concepts of a simulation, a model, and a configuration. A platform is a separate entity to a model (a simulation runs a model on a platform). Input/coupling bindings may be specified with the model or with the simulation.

So in summary I think CIM1.5 supports all the things you ask for except for property value choices which are managed externally to the CIM as controlled vocabularies.

As for terminology, I propose we separate the configuration of the science in a component (component configuration) from the configuration of the coupled model (coupling configuration). I also think the act of choosing appropriate resources (hardware and software) should be called deployment, but we are now talking about software, rather than science. Whilst we are on software I would say that capturing ESMF import and export states, and OASIS4 puts and gets (and BFG descriptions) is an interface definition

So we have:

  • interface definition (primarily a software concept?)
  • component configuration (software or science concept)
  • coupled model configuration (software or science concept)
  • deployment (software concept)