Required CIM Software Component Properties

The CIM development has (quite rightly) been strongly influenced by the CMIP5 use case. However, one other use case, for which the CIM is intended, is the description of software components and their coupling. The idea is that the CIM would be able to describe software components and their coupling to the detail of being able to use the CIM to drive the OASIS4 and BFG2 couplers. Two deliverables rely on this fact D5.7 and D5.8. Separately, the NUOPC project has decided to use the CIM to describe ESMF components.

OASIS4 have reported that they are able to use the CIM in its latest form (after some OASIS4 modifications). This page describes the metadata required by BFG2 to describe components and outlines where this information is missing in the CIM.

Looking at the bigger picture, Metafor has the opportunity to develop a standard way to describe software and software coupling in a generic way (in the same way as it describes science in a generic way for CMIP5). As BFG2 is designed to be generic and its model interface is not dissimilar to ESMF's it is expected that the additions being described here will also be of use to ESMF. I hope to add a section on this.

BFG2 has already defined a schema which describes a (BFG2) software component. The elements - and the related elements in the CIM - are:

BFG2 schema elementsBFG2 Cardinality within a documentBFG2 element descriptionCIM equivalentCIM notes
definition1Top level document elementmodelComponent
definition/name1component name - this is assumed to be the software container name unless this is explicitly providedmodelComponent/shortName
definition/type1scientific or transformation (BFG2 CV)modelComponent/typeWe could use processorComponent for type transformation. But there are potentially other types which would not necessarily fit e.g. service models in FLUME.
definition/class0..1type of science (atmosphere,ocean,...) Use METAFOR CV?modelComponent/typeCIM cardinality changed to 1..n
definition/language1language that the interface is coded in (f90,f77,intrinsic,...)modelComponent/componentLanguageAssume all entry points have the same language at the moment.
definition/gridType0..1grid for all properties unless overridden. Ian Hendersons gridspec schemamodelComponent/grid
definition/languageSpecific0..1container for any language specific informationmodelComponent/componentLanguagePropertyImplement as property/value pairs for the moment.
definition/languageSpecific/fortran/moduleName0..1for fortran90 modules we need a module name which may differ from the component namemodelComponent/componentLanguageProperty/valuemodelComponent/componentLanguageProperty/name = moduleName
definition/languageSpecific/fortran/reservedUnits0..nfortran code may reserve units internallymodelComponent/componentLanguageProperty/valuemodelComponent/componentLanguageProperty/name = reservedUnits
definition/languageSpecific/fortran/reservedNames0..nfortran code may have reserved global names i.e. common and modulesmodelComponent/componentLanguageProperty/valuemodelComponent/componentLanguageProperty/name = reservedNames
definition/multiInstanceSupport0..1Container for all multiInstanceSupport optionsmodelComponent/componentLanguageProperty/name = multiInstanceSupport
definition/multiInstanceSupport/stateless0..1should really be under language specific? or perhaps fortran/stateless. stateless code can be replicated with no side effectsmodelComponent/componentLanguageProperty/value = statelessmodelComponent/componentLanguageProperty/name = multiInstanceSupport
definition/multiInstanceSupport/id0..1if we are supporting multiple instances we need a way of referencing which one in our couplingMissingThis should really be part of the composition
definition/timestep0..1a scientific model will have an associated timestep (which may be variable)modelComponent/timing/rate
definition/timestep@units0..1Should use a standard here e.g. udunits. Currently an unrestricted stringmodelComponent/timing@units
definition/timestep@type0..1fixed or variablemodelComponent/timing@variableRate
definition/entryPoints0..1entryPoint containermodelComponent/dependencies
definition/entryPoints@description0..1General information about the entrypoints. Not sure why this is here.MissingNo equivalant in the CIM
definition/entryPoints/inPlaceCallStructure0..1Allows you to change the default structure of the call as implemented in your codeMissingNo equivalent in the CIM
definition/entryPoints/entryPoint1..infsubroutines. methods or functions depending on the languagemodelComponent/dependencies/entryPoint
definition/entryPoints/entryPoint@type1init, iteration, once, final.modelComponent/dependencies/entryPoint@typeinit, run, finalise is supported at the moment
definition/entryPoints/entryPoint@name1name of the entrypointmodelComponent/dependencies/entryPoint/name
definition/entryPoints/entryPoint@gridType0..1You can override any parent gridtype hereMissing
definition/entryPoints/entryPoint/data0..infData accessible via the entrypointmodelComponent/dependencies/entryPoint/argument
references modelComponent/componentProperties/componentProperty'
reference to a componentProperty
definition/entryPoints/entryPoint/data@units0..1datatype of the data. Should use a standard. Currently an unrestricted string.modelComponent/componentProperties/componentProperty/units
definition/entryPoints/entryPoint/data@name0..1Optional label to use when referencing the data.modelComponent/componentProperties/componentProperty/shortName
definition/entryPoints/entryPoint/data@direction1in, out or inoutmodelComponent/componentProperties/componentProperty@intent
definition/entryPoints/entryPoint/data@form1argpassing or inplaceMissingStated in the composition?
definition/entryPoints/entryPoint/data@id1Id to reference the data. For argpassing it is the position in the argument list.Missing
definition/entryPoints/entryPoint/data@dataType1Type of the data. integer, logical, character, string, real, ... Should use a standard here.Missing
definition/entryPoints/entryPoint/data@precision0..1Size of the data if explicitly stated.Missing
definition/entryPoints/entryPoint/data@dimension1Dimensions if an array. 0 is scalar.Missing
definition/entryPoints/entryPoint/data@shape0..1assumed (for Fortran).Missing
definition/entryPoints/entryPoint/data@gridType0..1You can override any parent gridtype heremodelComponent/componentProperties/componentProperty/grid
definition/entryPoints/entryPoint/data/stringSize0..1Can be an expression and can reference other dataMissing
definition/entryPoints/entryPoint/data/dim0..infDepends on the value in dimensionMissing
definition/entryPoints/constraints0..1Container for constraint informationmodelComponent/dependencies/entryPoint/entryPoint/precedes or followstypo in CIM1.5 at the moment which uses proceeds rather than precedes.
definition/entryPoints/constraints/constraint1..infany ordering constraints between entryPoints (ep1 precedes ep2 or ep1 follows ep2)modelComponent/dependencies/entryPoint/entryPoint/precedes or followsChoose either precedes or follows
definition/partition0..1Not yet implemented in BFG2. Look at existing solutionsMissingNeed to look at extracting metadata structure from existing solutions e.g. OASIS, MCT.
n/a - implicitly BFG2Type of interface the component conforms to (ESMF,BFG2,OASIS4,...). Implicitly BFG2modelComponent@couplingFramework

Are we only dealing with configured components here i.e. ones that can not change their interface via compile time switches?