headers
Andrew Miller | 2 Aug 2007 01:19
Picon
Picon
Favicon
Gravatar

Re: CellML technical question.

----- ----- wrote:
> Hi,
>
> Thanks for the quick reply,
>
> I am using CellML 1.1....PCEnv
>
> To put the (...And when I have imported the same component twice,....) 
> question into context:
>
> I have created an import file consisting of 2 components (a and b).
> I have created another import file consisting of 2 components (a and c).
>
> I have imported both of the IMPORT files into 1 single file
> ( But in the 2nd file, I have renamed 'a' as 'a2'....using 
> component_ref:a and name_ref:a2)
>
> Everything works fine, but when I am selecting properties to be shown 
> on the graph, My options (for components) are :  a
>                                  a
>                                  c.
>
> My question is
> : Is there anyway to name them such that my
> components options when drawing a graph are :     a
>                                                                        a2
>                                                                         
> c                            ?
Hi Habib,
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Nickerson | 2 Aug 2007 03:14
Picon

Re: CellML technical question.

A compatible alternative might be to use metadata to annotate 
components, variables, imports, etc. with human readable names (see 
section 4.7 in the metadata specification, for example). Model authors 
could then give descriptive names to whatever they wish possibly making 
it easier to locate specific variables in a GUI. Might be nicer than 
rendering long URI's.

Of course, getting the user navigation of the hierarchy of such names to 
be sensible and intuitive would still be essentially the same problem as 
below. But at least the model author could give clues to distinguish the 
high level imported components.

Andre.

Andrew Miller wrote:
> ----- ----- wrote:
>> Hi,
>>
>> Thanks for the quick reply,
>>
>> I am using CellML 1.1....PCEnv
>>
>> To put the (...And when I have imported the same component twice,....) 
>> question into context:
>>
>> I have created an import file consisting of 2 components (a and b).
>> I have created another import file consisting of 2 components (a and c).
>>
>> I have imported both of the IMPORT files into 1 single file
>> ( But in the 2nd file, I have renamed 'a' as 'a2'....using
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Lawson | 6 Aug 2007 01:40
Picon
Picon
Favicon

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.

Thanks,
James Lawson
(Continue reading)

Permalink | Reply | 3 comments |
headers
----- ----- | 6 Aug 2007 15:15
Picon
Favicon

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:

<group>
<relationship_ref name="repressed_protein-generator" 
relationship="encapsulation"/>
    <component_ref component="repressed_protein-generator">
       <component_ref component="promoter-RBS_repressed"/>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alan Garny | 7 Aug 2007 03:35
Picon
Picon

Re: how to units make a difference to simulation

> -----Original Message-----
> From: cellml-discussion-bounces@... [mailto:cellml-discussion-
> bounces@...] 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...
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Lawson | 7 Aug 2007 03:50
Picon
Picon
Favicon

Re: how to units make a difference to simulation

Alan Garny wrote:
>> -----Original Message-----
>> From: cellml-discussion-bounces@... [mailto:cellml-discussion-
>> bounces@...] 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...
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alan Garny | 7 Aug 2007 03:49
Picon
Picon

Re: 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Garny | 7 Aug 2007 03:56
Picon
Picon

Re: 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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Miller | 7 Aug 2007 04:07
Picon
Picon
Favicon
Gravatar

Re: 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.
>>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Andrew Miller | 7 Aug 2007 04:18
Picon
Picon
Favicon
Gravatar

Re: 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,
(Continue reading)

Permalink | Reply | 1 comment |

Gmane