[cellml-discussion] Best Import/Encapsulation methods
Hi everyone, Ive been creating a few models and Importing them and such to create more complex model. Example : I have 2 existing files (models) promoter-RBS_repressed and protein. These 2 respectively contain components promoter-RBS_repressed and Protein. promoter-RBS_repressed has an input of repressorConcentration and an output of synthesisRate. protein has an input of synthesisRate and an output of proteinConcentration. I want to create a single file with input: repressor concentration and output: protein concentration. What I have done is to create a 3rd file : repressed_protein-generator , create a component : repressed_protein-generator, create connections and groups such that variables are recieved (from other models) by repressed protein generator and 'relayed' to promoter-RBS_repressed and any output variables from Protein are relayed to repressed_protein-generator which can output them. Segments of code from repressed_protein-generator: .. . My question is : Is there a better way (more natural way..) to do this in CellML ? Thank you. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] how to units make a difference to simulation
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:cellml-discussion-
> [EMAIL PROTECTED] On Behalf Of James Lawson
> Sent: 06 August 2007 00:40
> To: For those interested in contributing to the development of CellML.
> Subject: [cellml-discussion] how to units make a difference to
> simulation
>
> Hi all,
>
> Recently Catherine said that she had a model that was running but not
> producing the right output. Instead of producing a train of spikes, it
> was just producing some kind of curve flattening off at an asymptote.
> Then when she changed some units on a relevant variable from
> dimensionless to the right units, she got the nice spiking output.
>
> As for myself, I've been looking at a model which has both a normal
> version and a scaled/non-dimensionalized version. When I consulted him
> about the output I was getting and which equations I should be using
> from his paper, the model author suggested that I use the
> non-dimensionalised set of equations, since the model describes a very
> stiff problem, and as such, that is what the ND'd equations are there
> for. Wheras before I was just getting curves that looked nothing like
> I
> want, I am now getting trains of spikes.
>
> I realise the first example might be slightly different from the first
> (damn I am sick of people who don't know how to write English, the
> Americans, that is, telling me I need a 'z' everywhere!) but...
>
> The point/question I want to raise here, is how does PCEnv / other
> simulators treat units? Is it possible that some of the models in the
> repository simply don't run or produce the right outputs because of
> the
> units? If so, this would be news to me! It would also be frustrating
> given the number of times we have to guess or spend hours poring over
> equations trying to work out the units of a variable.
Hi James,
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.
Alan.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] how to units make a difference to simulation
Alan Garny wrote:
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:cellml-discussion-
>> [EMAIL PROTECTED] On Behalf Of James Lawson
>> Sent: 06 August 2007 00:40
>> To: For those interested in contributing to the development of CellML.
>> Subject: [cellml-discussion] how to units make a difference to
>> simulation
>>
>> Hi all,
>>
>> Recently Catherine said that she had a model that was running but not
>> producing the right output. Instead of producing a train of spikes, it
>> was just producing some kind of curve flattening off at an asymptote.
>> Then when she changed some units on a relevant variable from
>> dimensionless to the right units, she got the nice spiking output.
>>
>> As for myself, I've been looking at a model which has both a normal
>> version and a scaled/non-dimensionalized version. When I consulted him
>> about the output I was getting and which equations I should be using
>> from his paper, the model author suggested that I use the
>> non-dimensionalised set of equations, since the model describes a very
>> stiff problem, and as such, that is what the ND'd equations are there
>> for. Wheras before I was just getting curves that looked nothing like
>> I
>> want, I am now getting trains of spikes.
>>
>> I realise the first example might be slightly different from the first
>> (damn I am sick of people who don't know how to write English, the
>> Americans, that is, telling me I need a 'z' everywhere!) but...
>>
>> The point/question I want to raise here, is how does PCEnv / other
>> simulators treat units? Is it possible that some of the models in the
>> repository simply don't run or produce the right outputs because of
>> the
>> units? If so, this would be news to me! It would also be frustrating
>> given the number of times we have to guess or spend hours poring over
>> equations trying to work out the units of a variable.
>
> Hi James,
>
> 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.
I absolutely agree that models should not have units problems. The
problem is that many of them do, and, speaking for myself, I do not have
the skills or the knowledge to know how to rearrange someone else's
model to fix the units. Especially with big models, it can just get too
complex. I'd like to see unit checking in PCEnv, but I wouldn't want a
model with bad units to not run - I'd just want error messages telling
me there is a problem.
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.
This would be great. I think it needs to start with the model authors
though, which is where standards such as MIRIAM come in.
>
> 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.
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.
>
> Alan.
>
> ___
> cellml-discussion mailing list
> cellml-discussion@cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] how to units make a difference to simulation
> 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.
Alan.
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] how to units make a difference to simulation
> > Anyway, the view we have now taken in Oxford is that models > shouldn't have > > any problem related to units. > I absolutely agree that models should not have units problems. The > problem is that many of them do, and, speaking for myself, I do not > have > the skills or the knowledge to know how to rearrange someone else's > model to fix the units. Especially with big models, it can just get > too > complex. I'd like to see unit checking in PCEnv, but I wouldn't want a > model with bad units to not run - I'd just want error messages telling > me there is a problem. That's exactly the way COR works. It will just generate a warning wherever there is a problem related to units. Doing mainly maintenance work on COR, I haven't gone very far in the warning message COR generates. In other words, it will just tell the user there is a problem, while it could easily tell you where exactly the problem is. > > 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. > > This would be great. I think it needs to start with the model authors > though, which is where standards such as MIRIAM come in. Yes and you will realise that some models authors have made mistake themselves. We came across such a model back in Oxford where units were simply wrong and there is nothing we could do about that. Pretty bad indeed, but nothing we can help unfortunately. > > 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. > 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. Alan. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] how to units make a difference to simulation
Alan Garny wrote:
>> 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 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
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.
The technical details of implementation aside, my view is as follows:
1) Model authors should not write models with inconsistent units.
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.
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.
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.
Best regards,
Andrew
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] how to units make a difference to simulation
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). 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. 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 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. Best regards, Andrew ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] how to units make a difference to simulation
> >> 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
Re: [cellml-discussion] how to units make a difference to simulation
> 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 mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion
