First login?
Lost password?
 
 
cellml-discussion AT lists.cellml.org 
CellML Discussion List

Text archives Help


[cellml-discussion] how to units make a difference to simulation


Chronological Thread 
  • From: alan.garny at dpag.ox.ac.uk (Alan Garny)
  • Subject: [cellml-discussion] how to units make a difference to simulation
  • Date: Tue, 7 Aug 2007 03:27:25 +0100
> >> As you know we (Catherine, you and I) spent a bit of time this
> morning
> >> trying to understand some models. One of the models that Catherine
> has
> >> been
> >> working on had problems with units. My understanding is that PCEnv
> >> didn't
> >> pick those problems up, while COR did. Correcting the problems,
> >> Catherine
> >> was able to get the model to "work" (I believe there might still be
> >> another
> >> problem, but not related to units this time).
> >>
> >> Anyway, the view we have now taken in Oxford is that models
> shouldn't
> >> have
> >> any problem related to units. This means that, dimensional
> >> equivalences,
> >> which are allowed in the CellML specification, are not "acceptable"
> to
> >> us.
> >> We should always have strict equivalences. E.g. A = B+C (with A and
> B
> >> in mV,
> >> while C in V) would be seen as being dimensionally equivalent and
> "OK"
> >> in
> >> regards to the CellML specification (and therefore COR, since it
> will
> >> only
> >> generate a warning). Yet, we would modify the equation so that it
> now
> >> reads:
> >> A = B+1000{millivolt_per_millivolt}*C. This may not be a great
> >> example, but
> >> I think you got the gist of it.
> >>
> >> The idea is, therefore, to have models that have no unit issues *at
> >> all*. I
> >> appreciate that this may seem a bit restrictive, but we have had so
> >> many
> >> issues with units over the years that we believe it will be worth
> it
> >> in the
> >> long term.
> >>
> >> Alternatively, we could have the software doing units conversion
> for
> >> the
> >> user... but that's another issue... and I understand that some are
> >> against
> >> that idea.
> >>
> > I have just realised that though the above might be an "acceptable"
> approach
> > for CellML 1.0 models, it might potentially be somewhat tricky to
> implement
> > for CellML 1.1 models... which makes me wonder whether we shouldn't
> be more
> > strict when it comes to units. At the end of the day, units are a
> very
> > common source of problems in model curation.
> >
> I'm not sure what you mean by 'the above', are you referring to units
> checking or automated units conversion?

I was referring to the model being modified so that no more unit problems
would be reported by the CellML software.

> I don't follow how there would be any difference between 1.1 and 1.0
> models, because in both cases there is an equally clear model for how
> connections work (the CeVAS service in the CellML API makes this very

Agreed, I have just realised (again!) that we could do 'the above' for both
CellML 1.0 and CellML 1.1 models, since units conversion will be done at the
connections level (something that COR doesn't currently do in fact).

> easy to work with, because it ties together variables which are the
> same
> as a result of connections, regardless of whether those connections
> are
> cross-imports or not). It is also very easy to work out from the
> context
> component exactly what units a particular variable should have in a
> particular equation - having the CeVAS and CUSES services means that
> other services, like the CCGS, which are built on top of them don't
> have
> to worry about CellML 1.1, connections, and so on at all, because they
> are built on top of a layer which already handles this.

Do you have some documentation about CeVAS, CUSES, etc.? I recall reading
some emails about those, but I must confess that I have forgotten what they
refer to.

> The technical details of implementation aside, my view is as follows:
> 1) Model authors should not write models with inconsistent units.

Well... :)

> 2) CellML must be able to represent models with inconsistent units,
> although tools can draw attention to such inconsistencies. This is not
> a
> contradiction with 1, but simply a reflection on the fact that many
> models published in journals have units problems, and we still want to
> represent such models even if we consider the way they were developed
> to
> be bad practice.

Agreed and that's what COR does at the moment. I was merely pointing out
that we want to avoid to minimise the occurrence of such models by 'fixing'
them and thus allowing people to use them (otherwise what would be the point
of having those models in the first place?).

> 3) Tools should (ideally must, but for historical reasons, we can't
> mandate this at least until CellML 1.2) perform unit conversions at
> the
> connection level. For example, if you connect a variable in mm to a
> variable in m, the conversion factors should be implicitly inserted by
> the tool.

Agreed.

> 4) Tools should never change the meaning of equations automatically
> under any circumstances. They can have features which flag potential
> problems and even suggest changes, but if the model has a particular
> equation in it, tools should respect this equation and assume that the
> model has been tested to work empirically even if the units appear
> wrong. In other words, assisted manual changes are a good thing, but
> fully automatic silent changes are very bad.

Fully agreed on that one. I know that JSim does units conversion but doesn't
tell you about what it converts. Jim Bassingthwaighte agreed that this
should be changed, so that the user is told whenever something is converted.

Alan.



Archive powered by MHonArc 2.6.18.

Top of page