wiki:tickets/182

The Wiki page for documenting progress on the ConCIM activity package:  http://metaforclimate.eu/trac/browser/CIM/branches/activityPackage/activity

"You should use iterative development only on projects that you want to succeed" [from UML Distilled by Martin Fowler]

Tuesday 25th November

 http://metaforclimate.eu/trac/browser/CIM/branches/activityPackage/activity/mip-cmip5-control-eg0.xml

I have completed an instance for the CMIP5 Pre-Industrial Control and in doing so I am beginning to be of the opinion that the simulation class should not be abstract because I want to be able to say that "my numerical experiment requires a simulation", and it just so happens that my simulation is simulation composite. In practice I don't think I'd say that "my numerical experiment requires a simulation composite", how would I know that a-priori?

Of course it would make sense to say "my numerical experiment required a simulation composite."

So if I'm planning an experiment the simulation class needs to be tangible (not abstract)
But if I'm writing about an experiment I have done then it does make sense for the simulation class to be abstract.

I remember from the potential model debate that metafor is about describing things that have happened so I guess I can clear this up by going through the activity UML and putting all the connector names into the past tense.

Monday 10th November

Simulation and Diagnostic. (Science and Engineering)
simulation is the implementation of a numerical experiment
diagnositc is some kind of data processing...
Diagnostic can refer to the processing of observation data or post processing of data from a simulation (ie CMOR).

Is diagnostic a simulation? My instinct says no because the simulation class is part of the description of numerical experiment and is about climate modelling. Diagnostic simply inputs data, does something then outputs data.

Simulations are about science. Diagnostics are for doing engineering.

For diagnostic to be a simulation it needs to be linked to a numerical experiment but experiments are for trying to answer questions ie doing science. Diagnostics are for doing stuff to data ie fixing negative temperatures (kelvin), engineering, so diagnostic doesn't really fit into the experiment framework that a simulation implements.

Metafor is about describing climate models, ie simulations, and linking the descriptions to the data in archives. So we need to describe the diagnostics that we do on the output from climate simulations so that we end up with a true description of how we created the data in the archive. So there is a place for a diagnostic class, and I think it is a different thing to a simulation.

Questions
Is diagnostic a class through which we can connect simulation output to the data package?
Perhaps I have just argued that diagnostic is really a quality thingie?

Tuesday 4th November

I have had a go at making xml documents to describe a simulationComposite. The documents need fleshing out but the basic structure is there. The documents use the naming convention: SimulationRun?-runid.xml and SimulationComposite?-runid.xml and they represent the idealised example in the powerpoint document: ActivityInstanceCMIP5_1.ppt

The documents are here:  http://metaforclimate.eu/trac/browser/CIM/branches/activityPackage/activity/

Thursday 23rd October

Because Allyn does not yet have subversion integrated with enterprise architect I have created a new eap file which contains the latest developments in the Activity package:

 http://metaforclimate.eu/trac/browser/CIM/branches/activityPackage/activity/ActivitySVN.eap

I’ll keep updating this into subversion as I commit changes to Activity.eap from EA. It’s a work around until everyone has their technology sorted out.

Thursday 23rd October

I am trying out a new idea for describing simulationCollection:

 http://metaforclimate.eu/trac/browser/CIM/branches/activityPackage/activity/BrownActivityImplementation.png

It makes use of the design pattern for describing composites structures

 http://en.wikipedia.org/wiki/Composite_pattern

The idea is that Simulation becomes an abstract class that is implemented as either a SimulationRun, SimulationComposite or Assimilation (which I think we’ve been neglecting because its been hiding on the other side of the UML). Jigging things around has made the relationship between SimulationRun and SoftwarePackage::ModelComponent more intuitive.

The 1--0..* relation between SimulationComposite? and Simulation implies a tree structure where a SimulationComposite? can contain other SimulationComposites?. To have a flat SimulationComposite? we need to move the relation to: "SimulationComposite? 1--1..* SimulationRun?", then SimulationComposites? only contain SimulationRuns.

Wednesday 22nd October

Added SimulationCollection? class to main uml diagram with notes on it's usage (on the "uses" connector), updated multiplicites on Simulation attributes and added dateDeployed to Simulation attributes.

Tuesday 21st October

I have integrated the activity package with enterprise archetect, notes on how I did this to follow.

Brian and I spent some time tinkering with attributes this morning and this is a brief record of what we changed.

Numerical Requirement: Control boolean moved up to Numerical Experiment

Changed cardinality on Numerical requirement

"consists of" association names added to numerical requirement

Changed cardinality on Experiment attributes

Numerical Activity has been given new attributes: name, description

"URI" association name added to the link from conformance to numerical requirement

"conforms to" association name added to the link from conformance to simulaiton

Simulation Collection Class added in place of the self-referencing simulationCollection aggregation

Added attributes to simulation: but my laptop is not booted up right now so I don't recall them all but it was something along the lines of, ancillaryFile, initialCondition, outputFile

Simulation is now a document sterotype so each member of the simulation collection will be instantiated as a separate document.

Friday 10th October: Changes to Activity.eap

The connections to the classes under Numerical Requirement have been made into specialisations again.

Added the Conformance class to the Activity Implementation classes.

Moved PhyisicalModification to become a specialisation of Conformance rather than a specialisation of NumericalRequirement.

Changed colour of ConfiguredModel and ConfiguredModelComponent from turquoise to Brown.

Put a composition connector from ConfiguredModelComponent to itself to reflect the fact that a component say atmosphere can be made of sub components eg radiation scheme, advection scheme, gravity wave scheme etc. NumSim think.

Monday 6th October: Changes to Activity.eap

I have moved calendarType:Calendar from Experiment and into Numerical Experiment.

There was a general consensus that the info about the particular kind of calendar used in a numerical experiment needed to be in the Numerical Experiment class and not in the scientific description (why) in the Experiment class.

I have changed the aggregation in MIP from Numerical Experiment to Experiment.

The Scientific description (why) is in the Experiment class so if a MIP aggregates directly to Numerical experiment then that misses out the scientific reasoning. My brain sees arrows and interprets them as having a sense of the flow through the logical steps to describe an Activity description. OK so I changed it and then saw how it looked and changed my mind and put the aggregation back to Numerical Experiment.

The connections to the classes under Numerical Requirement have been made into aggregations rather than specialisations.

Added unique identifier to be an attribute of numerical requirement.

I have put the concepts of “Physical Modification” and “Boundary Condition” into a single boundary condition class. I expect that we can probably bundle Spatio temporal constraints in there too with appropriate attributes.

Moved the green observation classes away to the top right hand corner of the Activity class diagram.

Renamed the class diagrams to better reflect what they are about and also to indicate the meaning of the colour coding.