Chronological Thread 

< Chronological >      < Thread >

---

> Alan Garny wrote:
> >> Again, this is a feature that it would be useful to be able to turn
> on
> >> and off. However I think in most cases the software will not be
> smart
> >> enough to figure out what the units should be.
> >>
> >
> > Wrong, it can easily be done. I was about to work on that in COR
> when Peter
> > got me to move over to "PCEnv". Check also JSim, it does units
> conversion
> > and, as far as I know and can tell, it does a pretty good job at it.
> >
> This only applies if the model was initially coded with the intention
> that such a feature be used. If the model empirically works despite
> units issues, which is probably quite common, attempting to 'fix' the
> model will actually break it (for example, it might have conversion
> factors in there, but marked as dimensionless).

Agreed and this is exactly the reason I intended to make that units
conversion feature optional (as, I believe, it is the case in JSim).

Still, I would personally warn against conversion factors marked as
dimensionless. To take my previous example: A = B+C (with A and B in mV and
C in V), to allow A = B+1000{dimensionless}*C would be wrong to me. If
anything, I would consider 1000 as being a scaling factor, not a conversion
factor. For me to consider it a conversion factor, it would need to have
units of millivolt_per_volt.

> It would require a lot
> more intelligence from a tool to work out if the conversion factors
> are
> there, perhaps folded into other conversion factors, and add the
> appropriate metadata. This is why doing automated conversions at this
> level would be a bad idea for a CellML tool.

Disagreed. If the right units information is given as part of those
conversion factors, then I cannot see how you could go wrong. Now, if you
think that marking a conversion factor as dimensionless is acceptable, then
we are in big trouble indeed!

> In light of the fact that:
> a) from a specification point of view, it is much better to make
> people
> write good equations and validate them than to have modellers rely on
> some feature which converts them, given that a single component is
> designed by a single person, and

Yes, that's why we (at Oxford) take the view that models should only have
strict units equivalence (as opposed to dimensional equivalence).

> b) the current specification isn't supposed to request that such
> conversion be performed automatically (although it could be construed
> in
> such a way), and changing something this major will cause problems
> with
> models which already work empirically,
>
> I would recommend that we keep the status quo and not perform
> conversions within equations.

I would rather be in favour of making it optional.

Alan.

---

• [cellml-discussion] how to units make a difference to simulation, James Lawson, 08/06/2007
  • [cellml-discussion] Best Import/Encapsulation methods, ----- -----, 08/07/2007
    • [cellml-discussion] Best Import/Encapsulation methods, David Nickerson, 08/13/2007
  • [cellml-discussion] how to units make a difference to simulation, Alan Garny, 08/07/2007
    • [cellml-discussion] how to units make a difference to simulation, Alan Garny, 08/07/2007
      • [cellml-discussion] how to units make a difference to simulation, Andrew Miller, 08/07/2007
        • [cellml-discussion] how to units make a difference to simulation, Alan Garny, 08/07/2007
    • [cellml-discussion] how to units make a difference to simulation, James Lawson, 08/07/2007
      • [cellml-discussion] how to units make a difference to simulation, Alan Garny, 08/07/2007
        • [cellml-discussion] how to units make a difference to simulation, Andrew Miller, 08/07/2007
          • [cellml-discussion] how to units make a difference to simulation, Alan Garny, 08/07/2007

---

Archive powered by MHonArc 2.6.18.