CellML Discussion List

Text archives Help


[cellml-discussion] Precise semantics of generateFlattenedModel()


Chronological Thread 
  • From: d.nickerson at auckland.ac.nz (David Nickerson)
  • Subject: [cellml-discussion] Precise semantics of generateFlattenedModel()
  • Date: Fri, 24 Feb 2006 10:56:39 +1300

Am I correct in reading this as saying that metadata contained in
imported components/variables/units... would not be present in the
flattened model?

If so, is it a bad thing to be discarding such metadata in the
flattening process??


Andrew Miller wrote:
> Hi all,
>
> There is currently no precise specification of the semantics for the
> generateFlattenedModel() operation on the cellml_api::Model interface.
>
> I propose the following:
>
> Flattening CellML models:
> --- The flattened model should contain:
> 1) Components => All components in the base model, including any
> components
> which have been imported into the base model. Also all components
> which
> are connected to any component that is to be included in the
> flattened
> model. Components in the base model shall always adopt their original
> names, and components which are imported into the base model shall
> always adopt the name of the ImportComponent. In all other cases, the
> API implementation shall attempt to assign the preferred name
> according
> to the following rules, but where that would result in a conflict
> with
> another component, the CellML API shall rename the component to
> another
> implementation defined, non-conflicting name. Such components shall
> have the preferred name of the shallowest ImportComponent referring
> to
> them, or where no such ImportComponent exists, the name of the
> Component.
> 2) Groups => All groups containing one or more selected top-level
> ComponentRefs. Selected ComponentRefs are ComponentRefs which either:
> 1) Have a group element as their parent, and refer to a component
> which
> has been put into the flattened model, and have one or more
> ComponentRef children which refer to a component which has been
> put
> into the flattened model, or
> 2) Have a selected ComponentRef as a parent and refer to a component
> which has been put into the flattened model.
>
> The groups should refer to components by their name in the flattened
> model.
> 3) Units => All units from any models from which any components have
> been
> used(including those imported into such models).
> Units in the base model shall always adopt their original
> names, and components which are imported into the base model
> shall always adopt the name of the ImportUnits. In all other
> cases, the API implementation shall attempt to assign the
> preferred name according to the following rules, but where
> that
> would result in a conflict with another units definition,
> the
> CellML API shall rename the units definition to another
> implementation defined, non-conflicting name. Such units
> shall have the preferred name of the shallowest ImportUnits
> referring to them, or where no such ImportUnits exists, the
> name of the Units.
> 4) Connections => All connections which involve any component which has
> been put into the flattened model.
>
> The connections should refer to components by their name in the
> flattened model.
>
> Any other elements in the top level model from any namespace will also be
> duplicated(including reactions, metadata, and extension elements), except
> that
> import elements in either of the CellML namespaces will not be included.
> Only
> the top-level elements from imported models mentioned in the above list will
> be included. Where an element is included, all child elements will also be
> included.
>
> Opinions?
>
> Best regards,
> Andrew Miller
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion




Archive powered by MHonArc 2.6.18.

Top of page