From dj.cowan at auckland.ac.nz  Fri Mar  5 07:33:18 2010
From: dj.cowan at auckland.ac.nz (Dougal Cowan)
Date: Fri, 05 Mar 2010 07:33:18 +1300
Subject: [cellml-discussion] ABI CellML meeting minutes 2010-03-03
Message-ID: <4B8FFCEE.2010807@auckland.ac.nz>

I have put the minutes from Wednesday's meeting up at:

http://www.cellml.org/community/meeting/minutes/2010/03.03

Thanks,
Dougal


From c.lloyd at auckland.ac.nz  Mon Mar  8 14:13:05 2010
From: c.lloyd at auckland.ac.nz (Catherine Lloyd)
Date: Mon, 8 Mar 2010 14:13:05 +1300
Subject: [cellml-discussion] Workshop presentations now online
Message-ID: <A4CD8431-BA48-4143-8F25-91234379B760@auckland.ac.nz>

Dear All

Please find pdfs of all the CellML workshop presentations online at:

http://www.cellml.org/community/events/workshop/2010

Best wishes
Catherine


From ak.miller at auckland.ac.nz  Thu Mar 11 09:33:02 2010
From: ak.miller at auckland.ac.nz (Andrew Miller)
Date: Thu, 11 Mar 2010 09:33:02 +1300
Subject: [cellml-discussion] Fwd: Haugh 2004b
In-Reply-To: <051AAD3C-2797-4825-B31F-93929EB76A77@auckland.ac.nz>
References: <20100310200127.GI94556@strackenz.spod-central.org>
	<051AAD3C-2797-4825-B31F-93929EB76A77@auckland.ac.nz>
Message-ID: <4B9801FE.8040909@auckland.ac.nz>

Catherine Lloyd wrote:
> Hi Andrew and Randall
> 
> This has gone beyond a curation question...  Can one of you please 
> explain daes to Lucian and also how OpenCell handles them?

In a CellML model, if you have two equations:
   f(x, y, z, a, b, c) = g(x, y, z, a, b, c)
   h(x, y, z, a, b, c) = i(x, y, z, a, b, c)
then this means that both equations in the model are true simultaneously 
(CellML is declarative, not procedural).

The CellML Integration Service included with the CellML API currently 
handles this case by using the Levenberg-Marquardt non-linear 
optimisation algorithm to look for a solution to
   (f(x, y, z, a, b, c) - g(x, y, z, a, b, c))^2 = 0
   (h(x, y, z, a, b, c) = i(x, y, z, a, b, c))^2 = 0
It will satisfy as many of x, y, z, a, b, and c as possible using other 
equations first.

Work is also in progress towards supporting IDA.

Best wishes,
Andrew

> 
> That would be much appreciated - Thank you :)
> 
> Best wishes
> Catherine
> 
> 
> 
> Begin forwarded message:
> 
>> *From: *Lucian Smith <lpsmith at spod-central.org 
>> <mailto:lpsmith at spod-central.org>>
>> *Date: *11 March 2010 9:01:27 AM
>> *To: *Catherine Lloyd <c.lloyd at auckland.ac.nz 
>> <mailto:c.lloyd at auckland.ac.nz>>
>> *Subject: **Re: Haugh 2004b*
>>
>> Aha, thanks!  So, I don't know anything about differential algebraic
>> equations, and I'm afraid the wikipedia page about it is opaque to me.  
>> But the loop in question occurs with a couple 'Assignment rules' (as
>> they're known in SBML), with the first variable depending on the second
>> variable, and the second depending on the first.  Is the claim that if 
>> the
>> system is set up correctly, there is always a set of variables such that
>> those assignment rules will both be satisfiable?  And that this 
>> relates to
>> differential algebraic equations somehow?  Or does OpenCell simply 
>> execute
>> the first in each iteration based on the previous iteration's values, and
>> then execute the second based on those results?
>>
>> (We're probably moving away from curation questions at this point...)
>>
>> Thanks for the assistance!  And I'm glad you appreciated the follow-up
>> post--I had been hoping to get at least a little bit of discussion out of
>> it, but I'll settle for a thanks ;-)
>>
>> -Lucian
>>
>> * Catherine Lloyd <c.lloyd at auckland.ac.nz 
>> <mailto:c.lloyd at auckland.ac.nz>> [2010-03-10 01:15] writes:
>>> Hi Lucian
>>>
>>> Yes, it's a curation question :)
>>>
>>> OK, so Haugh_2004 has this curation statement:
>>>
>>> This CellML model runs in both COR and OpenCell.  The units have been  
>>> checked and they are consistent.  The CellML model may recreate the  
>>> results of the original published model but there is no simple  
>>> validation method as there are no "concentration against time" figures  
>>> in the paper. The CellML model is based on equations A1a, A1b, A1c,  
>>> A1d and A1e from the Appendix. Parameter values were taken from table  
>>> 1 in the paper and were also supplied through correspondence with the  
>>> original model author.
>>>
>>> I checked the model in COR and in OpenCell and it runs fine in both.
>>>
>>> HOWEVER, Haugh_2004b has this statement:
>>>
>>> This CellML model runs in OpenCell (but not COR due to the presence of  
>>> differential algebraic equations).  The units have been checked and  
>>> they are consistent.  The CellML model may recreate the results of the  
>>> original published model but there is no simple validation method as  
>>> there are no "concentration against time" figures in the paper. The  
>>> CellML model is based on equations A2-A5 from the Appendix (steady  
>>> state model). Parameter values were taken from table 1 in the paper  
>>> and were also supplied through correspondence with the original model  
>>> author.
>>>
>>> COR reports an error similar to your tool - that the model has  
>>> "circular arguments".  OpenCell can handle differential algebraic  
>>> equations though so the model runs in OpenCell - but whether or not it  
>>> makes any sense we don't know as there were no results figures in the  
>>> published paper to compare the CellML to.
>>>
>>> Regarding the stars - this is an unfortunate problem in PMR2 that we  
>>> are aware about - we can only assign a star rating once in a model  
>>> exposure - regardless of how many different models there may be.   
>>> Tommy knows this and hopefully it will be fixed in the not too distant  
>>> future.
>>>
>>> I hope this makes some sense - please let me know if it doesn't or  
>>> if you need more information.
>>>
>>> Also thank you for your feedback post-meeting - I spotted it on cellml  
>>> discuss when I got back to work on Monday.
>>>
>>> Best wishes
>>> Catherine
>>>
>>>
>>>
>>> On 10/03/2010, at 12:41 PM, Lucian Smith wrote:
>>>
>>>> So, I have a question that essentially amounts to a curation  
>>>> question (I
>>>> think), so I figured I'd ask you directly instead of the list.  But  
>>>> I am
>>>> happy to ask the list if you think that would be better!
>>>>
>>>> When translating the model haugh_2004b.cellml from
>>>>
>>>> http://models.cellml.org/exposure/4ce2912573256c6a5483da117ed26d9e
>>>>
>>>> my software found an error:  The definition of 'C' in component 'C'
>>>> includes a variable 'R', and the the definition of 'R' in component  
>>>> 'R'
>>>> includes a variable 'C'.  Then there is a connection between C.C and  
>>>> R.C,
>>>> and between R.R and C.R.  Which I *think* should end up with an
>>>> overdetermined model.  In all other cases when I've found such a  
>>>> loop, if
>>>> I look at the model's curation status, it will say something like  
>>>> "this
>>>> model is overdetermined".  But this has a two-star curation, and  
>>>> claims
>>>> there are no problems (of this nature, at least).  So is there not
>>>> actually a problem and my software thinks there is, or is there a  
>>>> problem
>>>> that is not mentioned in the curation paragraph?  Or was the model  
>>>> changed
>>>> since its last curation?  Or is the curation paragraph about
>>>> haugh2004.txt, and not haugh2004b.txt?
>>>>
>>>> Thanks!
>>>>
>>>> -Lucian
>>>>
>>>>
>>>
> 


From p.nielsen at auckland.ac.nz  Thu Mar 11 16:27:53 2010
From: p.nielsen at auckland.ac.nz (Poul Nielsen)
Date: Thu, 11 Mar 2010 16:27:53 +1300
Subject: [cellml-discussion] Leftover thoughts from the CellML workshop
In-Reply-To: <20100226194341.GB66438@strackenz.spod-central.org>
References: <20100226194341.GB66438@strackenz.spod-central.org>
Message-ID: <3F2BE684-F890-4050-B43E-D7E0DD2E0371@auckland.ac.nz>

Dear Lucian

Many thanks for your participation in the CellML workshop and subsequent comments.

On 2010-02-27, at 08:43, Lucian Smith wrote:

> Thanks to all of you who were at the workshop for letting me attend 
> remotely.  I found it quite valuable, and hope you didn't mind me asking 
> you all to repeat the questions too often.  And special thanks to 
> Catherine for being the driving force behind getting it all set up!
> 
> I had a couple extra thoughts on some of the presentations, which I 
> probably would have chatted with you about had I been there, but since I 
> wasn't, here they are in email instead.
> 
> The OpenCell network visualization tool:  
>     I agree that there is definitely a need both for automatically-
> generated network visualization and for human-arranged network 
> visualization.  One thing that might help this is to have a standard for 
> exchanging or at least storing these--I know SBML has a 'layout extension' 
> that stores the visual representation of SBML models.  I don't know if a 
> CellML extension is the right way to go or if that information is better 
> suited to storing in a separate file, but you could at least look at that 
> extension for an example of the information you'd want to store.
Being able to store useful layouts of CellML model visualisations would be a very worthwhile addition. I think, however, that this is a nontrivial problem. If one is only wishing to reproduce the biophysical representation of a model by associating components with processes and variables with entities, the resulting visualisation will in general be very complicated. Aside from the obvious collapsing of connected variables, there is no unique way of generating simpler diagrammatic representations. Sarala's PhD work indicated how annotations and simple rules can be used to simplify the biophysical view to something more resembling a biological view, but the result is dependent upon the ordering of rules applied by the user. It would be useful formalise the process into a sequence of rules so that it could be applied to several related models to generate similar views. The graph could then be manipulated and the resulting diagram stored for future use. So it seems to me that there are several distinct parts to this workflow: simplification based upon annotations and a sequence of graph reduction rules; laying out the nodes (processes and entities) after simplification. I think that both are candidates for expressing in a marked up form so that they can be re-run to generate the same or similar diagram.
> 
> CellML 1.2:
>    One thing I noticed was the claim that events could be stored in 
> CellML as piecewise formulas.  I'm pretty sure that won't be the case with 
> SBML events, which are 'fire once' events instead of 'true while' events.  
> Maybe one could come up with a piecewise hack to store SBML events, but if 
> a goal is to become more amenable to SBML-translated models, you might 
> want to think about how best to translate SBML events.  Or maybe I'm wrong 
> and there's already a way to do it?
>    Another thing I noticed was a reluctance to add too many new features 
> to the language in the fear that interpreters might not be able or willing 
> to handle them.  One way to mitigate this would be to allow models to 
> claim somewhere in the header whether the model required that feature or 
> not--an interpreter could then more cleanly note whether it was able to 
> correctly interpret a given model, while still being able to interpret 
> other 1.2 models.
I don't think the goal is necessarily to become more amenable to SBML-translated models. What we are most strongly motivated by is to come up with simple, powerful generic mechanisms for representing events and behaviours that depend on them. I would value your thoughts on why piecewise representations are insufficient for handling events.

It is correct that we are reluctant to add features to CellML. This is only partly motivated by a desire to ease the burden on tool developers. The stronger motivation is to keep the language as simple as possible by ensuring that any new feature is orthogonal to existing features. I agree that tools should reserve the right to declare that they cannot handle particular features.
> 
> Roundtrip translators:  
>    I think I'm coming around to the theory that we don't need non-lossy 
> translators--that's probably an unattainable goal.  What might be more 
> helpful instead is roundtrop re-integrators.  What I mean by that is that 
> nobody actually needs a way to round-trip a model that has never been 
> modified, because you still have the original.  Instead, what you need is 
> a way to translate a model to a new format, modify it in that new format, 
> translate it back to the original format, and end up with a model that is 
> identical to the original model except for those bits that have been 
> changed.  I think the best hope for this is if you take the original model 
> and the round-tripped-and-modified model, and re-integrate the two.
> 
> Obviously, the trickiest bit of this is if you've modified the model by 
> deleting something--you need to know that the round-tripping was *able* to 
> keep the information, so that if it's gone, that means it's been deleted 
> on purpose.  But everything else can stay.  Similarly, you need to know if 
> the format of the information will have changed, and if so, how to map the 
> new format to the old format.  This may well be the trickier bit--I 
> certainly don't know off the top of my head what a good algorithm would be 
> to track CellML's modularity through modularless SBML, for example.  But 
> perhaps with the Hierarchical Modeling extention up and running SBML, this 
> would become attainable?
> 
> At any rate, I'd be interested in others' thoughts on this.  I'm certainly 
> not saying that translators should discard information they could have 
> saved--the more information they save, the better.  I just think there 
> will alwaybe be information they can't save (even if it's just some 
> proprietary annotations), and re-itegration seems like the way to go here.
Yes, demanding the ability to 'round-trip' is a big ask!  As you point out, correctly handling models, if the model is modified, is especially difficult. My interest in round-tripping is motivated by the fact that doing so provides a good demonstration (but no guarantee) that no information loss is incurred during translation. The advantage of striving for round-tripping is that it should become clearer exactly what information is lost (and thus has to be encoded as annotations - such as modularity) when translating from one format to another. If we can better formalise the information loss during translation then we might improve the process of automatic conversion, enabling us to more reliably carry curation and annotation information in the process.
> 
> -Lucian
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

Best wishes
Poul


From j.marsh at auckland.ac.nz  Fri Mar 12 18:34:06 2010
From: j.marsh at auckland.ac.nz (Justin Marsh)
Date: Fri, 12 Mar 2010 18:34:06 +1300
Subject: [cellml-discussion] Announcement of OpenCell 0.7rc3
Message-ID: <4B99D24E.9080609@auckland.ac.nz>

Hi all,

The third release candidate for OpenCell version 0.7 has been released.

More information, and the released files themselves, are available at 
http://www.cellml.org/tools/downloads/opencell/releases/0.7rc3
or alternatively, from SouceForge at
https://sourceforge.net/projects/cellml-opencell/files/

A release candidate will become a release one week from announcement on 
this list if there are no problems identified with it.

Please report any bugs you find at https://tracker.physiomeproject.org/,
or to this list, or directly to me at j.marsh at auckland.ac.nz

Best regards,
Justin Marsh.


From david.nickerson at gmail.com  Mon Mar 15 12:37:51 2010
From: david.nickerson at gmail.com (David Nickerson)
Date: Mon, 15 Mar 2010 12:37:51 +1300
Subject: [cellml-discussion] Announcement of OpenCell 0.7rc3
In-Reply-To: <4B99D24E.9080609@auckland.ac.nz>
References: <4B99D24E.9080609@auckland.ac.nz>
Message-ID: <b966f9391003141637n3c4f7b28t976527604092352d@mail.gmail.com>

Hi Justin,

Does this also serve notice that there is a version 1.7 release
candidate of the API available for testing as well?

Thanks,
Andre.

On Fri, Mar 12, 2010 at 6:34 PM, Justin Marsh <j.marsh at auckland.ac.nz> wrote:
> Hi all,
>
> The third release candidate for OpenCell version 0.7 has been released.
>
> More information, and the released files themselves, are available at
> http://www.cellml.org/tools/downloads/opencell/releases/0.7rc3
> or alternatively, from SouceForge at
> https://sourceforge.net/projects/cellml-opencell/files/
>
> A release candidate will become a release one week from announcement on this
> list if there are no problems identified with it.
>
> Please report any bugs you find at https://tracker.physiomeproject.org/,
> or to this list, or directly to me at j.marsh at auckland.ac.nz
>
> Best regards,
> Justin Marsh.
>
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>

From lpsmith at spod-central.org  Wed Mar 17 11:02:31 2010
From: lpsmith at spod-central.org (Lucian Smith)
Date: Tue, 16 Mar 2010 22:02:31 +0000
Subject: [cellml-discussion] Leftover thoughts from the CellML workshop
In-Reply-To: <3F2BE684-F890-4050-B43E-D7E0DD2E0371@auckland.ac.nz>
Message-ID: <20100316220231.GE62846@strackenz.spod-central.org>

(Whoops, I meant to send this to the list, but replied directly to Poul 
instead...)

----- Forwarded message from Lucian Smith <lpsmith at spod-central.org> -----

A couple follow-up thoughts:

* Poul Nielsen <p.nielsen at auckland.ac.nz> [2010-03-11 03:28] writes:
> Dear Lucian
> 
> Many thanks for your participation in the CellML workshop and subsequent comments.
> 
> On 2010-02-27, at 08:43, Lucian Smith wrote:
> 
> > CellML 1.2:
> >    One thing I noticed was the claim that events could be stored in 
> > CellML as piecewise formulas.  I'm pretty sure that won't be the case with 
> > SBML events, which are 'fire once' events instead of 'true while' events.  
> > Maybe one could come up with a piecewise hack to store SBML events, but if 
> > a goal is to become more amenable to SBML-translated models, you might 
> > want to think about how best to translate SBML events.  Or maybe I'm wrong 
> > and there's already a way to do it?
> >    Another thing I noticed was a reluctance to add too many new features 
> > to the language in the fear that interpreters might not be able or willing 
> > to handle them.  One way to mitigate this would be to allow models to 
> > claim somewhere in the header whether the model required that feature or 
> > not--an interpreter could then more cleanly note whether it was able to 
> > correctly interpret a given model, while still being able to interpret 
> > other 1.2 models.
>
> I don't think the goal is necessarily to become more amenable to 
> SBML-translated models. What we are most strongly motivated by is to 
> come up with simple, powerful generic mechanisms for representing events 
> and behaviours that depend on them. I would value your thoughts on why 
> piecewise representations are insufficient for handling events.

Certainly I don't think SBML translation is *the* goal of CellML 1.2, I 
just posited that it might be *a* goal.

Piecewise functions say "while (condition), the following is always true".  
SBML events say "when (condition) becomes true, set the following to be 
true at that instant, and let it change after that."

Depending on the nature of the condition, these can be very different 
beasts.  As an example, you could have a species X controlled by various 
reactions, and at regular intervals, it's being injected into the system 
(daily feeding, say).  An SBML event would just say something like 'when 
time is a multiple of 24, X = X+5'.  A piecewise function would have to 
incorporate that event into all the other things that change X.  It might 
be possible, but the resulting expression will probably be very 
complicated.  And it might be impossible to write any sort of automatic 
translator that translated SBML events to CellML.

At the core, SBML events allow you to separate 'the sort of math the 
normally happens to these variables' from 'these things happen every so 
often, and the model adjusts accordingly'.  If you require those two 
things to be mushed together into piecewise functions, I *think* you could 
probably end up with a function that produced the same output (though 
there might be some counter-examples), but it would be complicated.  I'm 
not saying you definitely should add SBML-style events to CellML, but the 
tradeoff is simplicity for interpreters if you leave it as-is vs. 
simplicity for modelers if you add some new construct.

-Lucian

From c.lloyd at auckland.ac.nz  Wed Mar 17 11:43:09 2010
From: c.lloyd at auckland.ac.nz (Catherine Lloyd)
Date: Wed, 17 Mar 2010 11:43:09 +1300
Subject: [cellml-discussion] Leftover thoughts from the CellML workshop
In-Reply-To: <20100316220231.GE62846@strackenz.spod-central.org>
References: <20100316220231.GE62846@strackenz.spod-central.org>
Message-ID: <2AB0AA99-97E2-4F72-8691-A732B414C8FB@auckland.ac.nz>

Funny - we just realised this ourselves in this morning's CellML  
meeting.  Lukas is talking with Andrew right now about events - and I  
think he wants to talk with Poul about this too...  I'm sure you'll  
get some more feedback.

Best wishes
Catherine

On 17/03/2010, at 11:02 AM, Lucian Smith wrote:

> (Whoops, I meant to send this to the list, but replied directly to  
> Poul
> instead...)
>
> ----- Forwarded message from Lucian Smith <lpsmith at spod-central.org>  
> -----
>
> A couple follow-up thoughts:
>
> * Poul Nielsen <p.nielsen at auckland.ac.nz> [2010-03-11 03:28] writes:
>> Dear Lucian
>>
>> Many thanks for your participation in the CellML workshop and  
>> subsequent comments.
>>
>> On 2010-02-27, at 08:43, Lucian Smith wrote:
>>
>>> CellML 1.2:
>>>   One thing I noticed was the claim that events could be stored in
>>> CellML as piecewise formulas.  I'm pretty sure that won't be the  
>>> case with
>>> SBML events, which are 'fire once' events instead of 'true while'  
>>> events.
>>> Maybe one could come up with a piecewise hack to store SBML  
>>> events, but if
>>> a goal is to become more amenable to SBML-translated models, you  
>>> might
>>> want to think about how best to translate SBML events.  Or maybe  
>>> I'm wrong
>>> and there's already a way to do it?
>>>   Another thing I noticed was a reluctance to add too many new  
>>> features
>>> to the language in the fear that interpreters might not be able or  
>>> willing
>>> to handle them.  One way to mitigate this would be to allow models  
>>> to
>>> claim somewhere in the header whether the model required that  
>>> feature or
>>> not--an interpreter could then more cleanly note whether it was  
>>> able to
>>> correctly interpret a given model, while still being able to  
>>> interpret
>>> other 1.2 models.
>>
>> I don't think the goal is necessarily to become more amenable to
>> SBML-translated models. What we are most strongly motivated by is to
>> come up with simple, powerful generic mechanisms for representing  
>> events
>> and behaviours that depend on them. I would value your thoughts on  
>> why
>> piecewise representations are insufficient for handling events.
>
> Certainly I don't think SBML translation is *the* goal of CellML  
> 1.2, I
> just posited that it might be *a* goal.
>
> Piecewise functions say "while (condition), the following is always  
> true".
> SBML events say "when (condition) becomes true, set the following to  
> be
> true at that instant, and let it change after that."
>
> Depending on the nature of the condition, these can be very different
> beasts.  As an example, you could have a species X controlled by  
> various
> reactions, and at regular intervals, it's being injected into the  
> system
> (daily feeding, say).  An SBML event would just say something like  
> 'when
> time is a multiple of 24, X = X+5'.  A piecewise function would have  
> to
> incorporate that event into all the other things that change X.  It  
> might
> be possible, but the resulting expression will probably be very
> complicated.  And it might be impossible to write any sort of  
> automatic
> translator that translated SBML events to CellML.
>
> At the core, SBML events allow you to separate 'the sort of math the
> normally happens to these variables' from 'these things happen every  
> so
> often, and the model adjusts accordingly'.  If you require those two
> things to be mushed together into piecewise functions, I *think* you  
> could
> probably end up with a function that produced the same output (though
> there might be some counter-examples), but it would be complicated.   
> I'm
> not saying you definitely should add SBML-style events to CellML,  
> but the
> tradeoff is simplicity for interpreters if you leave it as-is vs.
> simplicity for modelers if you add some new construct.
>
> -Lucian
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion


From j.marsh at auckland.ac.nz  Wed Mar 17 12:08:55 2010
From: j.marsh at auckland.ac.nz (Justin Marsh)
Date: Wed, 17 Mar 2010 12:08:55 +1300
Subject: [cellml-discussion] CellML DOM API 1.7rc3 (release candidate for
 CellML DOM API 1.7) out
Message-ID: <4BA00F87.8000603@auckland.ac.nz>

Hi all,

The third release candidate for the CellML DOM API, version 1.7, has 
been released. Information about the released files is available at:
http://www.cellml.org/tools/downloads/cellml_api/releases/1.7rc3

A release candidate will become a release one week from announcement on 
this list if there are no problems identified with it.

Please report any bugs you find at https://tracker.physiomeproject.org/,
or to this list, or directly to j.marsh at auckland.ac.nz

Best regards,
Justin Marsh.

From dj.cowan at auckland.ac.nz  Fri Mar 19 13:57:19 2010
From: dj.cowan at auckland.ac.nz (Dougal Cowan)
Date: Fri, 19 Mar 2010 13:57:19 +1300
Subject: [cellml-discussion] ABI CellML meeting minutes 2010-03-17
Message-ID: <4BA2CBEF.6060007@auckland.ac.nz>

I have put the minutes from Wednesday's meeting up at:

http://www.cellml.org/community/meeting/minutes/2010/3.17

Thanks,
Dougal


From j.marsh at auckland.ac.nz  Wed Mar 24 16:48:02 2010
From: j.marsh at auckland.ac.nz (Justin Marsh)
Date: Wed, 24 Mar 2010 16:48:02 +1300
Subject: [cellml-discussion] Announcement of OpenCell 0.7
Message-ID: <4BA98B72.6000209@auckland.ac.nz>

Hi all,

OpenCell version 0.7 has been released.

More information, and the released files themselves, are available at 
http://www.cellml.org/tools/downloads/opencell/releases/0.7
or alternatively, from SouceForge at
https://sourceforge.net/projects/cellml-opencell/files/

Please report any bugs you find at https://tracker.physiomeproject.org/,
or to this list, or directly to me at j.marsh at auckland.ac.nz

Best regards,
Justin Marsh.


From j.marsh at auckland.ac.nz  Wed Mar 24 17:05:35 2010
From: j.marsh at auckland.ac.nz (Justin Marsh)
Date: Wed, 24 Mar 2010 17:05:35 +1300
Subject: [cellml-discussion] CellML DOM API 1.7 out
Message-ID: <4BA98F8F.6030002@auckland.ac.nz>

Hi all,

The CellML DOM API version 1.7 has been released. Information and the 
released files are available on both cellml.org and sourceforge, at:
http://www.cellml.org/tools/downloads/cellml_api/releases/1.7
https://sourceforge.net/projects/cellml-api/files/

Please report any bugs you find at https://tracker.physiomeproject.org/,
or to this list, or directly to j.marsh at auckland.ac.nz

Best regards,
Justin Marsh.

From dj.cowan at auckland.ac.nz  Thu Mar 25 11:27:02 2010
From: dj.cowan at auckland.ac.nz (Dougal Cowan)
Date: Thu, 25 Mar 2010 11:27:02 +1300
Subject: [cellml-discussion] ABI CellML meeting minutes 2010-03-24
Message-ID: <4BAA91B6.6050703@auckland.ac.nz>

I have put the minutes from yesterday's meeting up at:

http://www.cellml.org/community/meeting/minutes/2010/3.24

Thanks,
Dougal


From tommy.yu at auckland.ac.nz  Mon Mar 29 13:42:43 2010
From: tommy.yu at auckland.ac.nz (Tommy Yu)
Date: Mon, 29 Mar 2010 13:42:43 +1300
Subject: [cellml-discussion] Upgrading models.cellml.org
Message-ID: <4BAFF783.7050506@auckland.ac.nz>

Hi,

On 29 March 2010, 10:00 NZDT (2010-03-28 21:00 UTC), the CellML model repository hosted at models.cellml.org will be taken down briefly to expand the storage capacity of its host.

Regards,
Tommy.

From tommy.yu at auckland.ac.nz  Mon Mar 29 13:50:54 2010
From: tommy.yu at auckland.ac.nz (Tommy Yu)
Date: Mon, 29 Mar 2010 13:50:54 +1300
Subject: [cellml-discussion] Upgrading models.cellml.org
In-Reply-To: <4BAFF783.7050506@auckland.ac.nz>
References: <4BAFF783.7050506@auckland.ac.nz>
Message-ID: <4BAFF96E.4000800@auckland.ac.nz>

Correction, the downtime should be on 30 March 2010, 10:00 NZDT (2010-03-29 21:00 UTC).  Its anticipated length is about ten minutes.

Regards,
Tommy.

Tommy Yu wrote:
> Hi,
> 
> On 29 March 2010, 10:00 NZDT (2010-03-28 21:00 UTC), the CellML model 
> repository hosted at models.cellml.org will be taken down briefly to 
> expand the storage capacity of its host.
> 
> Regards,
> Tommy.
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion