Re: [cellml-discussion] Java error on Mac OSX10.8.2

2013-02-26 Thread Andrew Miller

On 27/02/13 10:09, Mark Cannell wrote:

Hi Randall

I installed the tools and the repository code does runs in OpenCell. However 
when I clone the distribution and edit anything I get the same java error I got 
before the Xcode tools were installed. I have no idea what I could be doing 
wrong..


So just to clarify: you are loading a model, running a simulation by 
clicking the Integrate button, cloning the model by right clicking on it 
in the left pane, editing an initial condition in OpenCell, and clicking 
Integrate, without leaving OpenCell in the interim, and the first time 
you click Integrate, it works and you get results, but the second time 
you get the Javascript error about it failing in 
cellml_servicesICellMLIntegrationService.compileModelODE?


This is not something I have seen before, the only possibility I can 
think of is that the edit you are making might be introducing a change 
that is tripping a bug in the code generator - what edit are you making, 
and does it happen if you only make a simple change like changing an 
initial condition?


Best wishes,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] CellML API Survey

2012-11-19 Thread Andrew Miller

Dear CellML community member,

We are conducting a survey to understand how the CellML API is being 
used, and what the
requirements for the CellML API by the community are. The responses from 
this survey will be
made public except where participants opt out of sharing particular 
information, and will be used to
guide the development of the CellML API, and to support future grant 
applications.
You are invited to participate in the survey, which should take less 
than ten minutes to complete
(depending on the level of detail you want to provide in your answers). 
Please visit
 https://cellmlapisurvey.appspot.com/survey_followup.html to 
participate in the survey.


Yours Sincerely,
Andrew Miller (ak.mil...@auckland.ac.nz, phone 09-3737599 ext 85122)
Auckland Bioengineering Institute

APPROVED BY THE UNIVERSITY OF AUCKLAND HUMAN PARTICIPANTS
ETHICS COMMITTEE ON 7th Nov 2012 for (3) years, Reference Number 8688.

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Solicitation of feedback on CellML 1.2

2012-11-04 Thread Andrew Miller

On 05/11/12 10:10, Jonathan Cooper wrote:

Hi all,

Just wanted to respond to a couple of points.

On 30/10/2012 02:53, Andrew Miller wrote:

On 29/10/12 22:36, David Nickerson wrote:

In addition, we specifically ask for feedback on the issue of moving to
MathML 3.0 (tracker item 67
https://tracker.physiomeproject.org/show_bug.cgi?id=67) and the
inclusion of stochastic variation in models (tracker item 2809
https://tracker.physiomeproject.org/show_bug.cgi?id=2809). The 
editors

generally agree that switching to MathML 3.0 at this time provides too
little benefit (mathematical clarity) for the cost involved in making
the change (tool support, interoperability with other exchange 
formats).


I think that it would be worth including MathML 3.0 in CellML 1.2 
because:
  1. It makes implementation easier by providing clear rules about 
the mathematical interpretation of models.
  2. It is more cleanly extensible through the use of OpenMath 
content dictionaries.
  3. It is mostly forwards and backwards compatible with MathML 2.0 - 
nearly every MathML 2.0 expression is valid MathML 3.0, and you can 
write MathML 3.0 so it is valid MathML 3.0.
  4. The only implementation of the CellML 1.2 proposals so far has 
already been coded to use MathML 3.0 - so the cost in terms of tool 
support so far would actually be higher to change that implementation 
to support MathML 2.0.


For the sake of those not at the ABI, could you give more details of 
this implementation? Is it an API library that can be used from 
multiple programming languages?


The implementation is intended as a demonstration of CellML 1.2 
features, and so design decisions have primarily focused on minimising 
development costs and maintaining agility rather than providing the best 
possible interface.


It is written in Haskell, but with the work currently being completed, 
limited C++ bindings to access generated code and run simulations will 
also be available.


Best wishes,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Announcing CellML API 1.12

2012-11-01 Thread Andrew Miller

Hi all,

The CellML API release candidate version 1.11rc2 has been released with 
a minor change to correct uncertainty solvers as CellML API version 1.12.


The files making up this release candidate are available here:
  * http://cellml-api.sourceforge.net/download.html#1.12

This release candidate has a number of significant improvements over the 
CellML API 1.12:
  * Extra attributes are provided to make accessing a variable's 
initial value more convenient.
  * IVs on algebraic variables is supported with initial_value rather 
than RDF.

  * Documentation on using the CellML API from Java has been improved.
  * KINSOL, rather than LEVMAR, is used as the non-linear system 
solver. This avoids the global state used by LEVMAR, allowing multiple 
simulations to be working concurrently to return results more efficiently.
  * Error reporting for models underconstrained due to missing initial 
values has been added.
  * It is now possible to use the DOM to determine the order of 
elements in the CellML model and map from the DOM element to the CellML 
element.
  * An ambiguity in the TeLICeMS serialiser around the nesting of the 
equals operator has been fixed.

  * You can now create a CellML model from an existing DOM representation.
  * The C++ interface for performing query interfaces has been improved.
  * The generated binaries are smaller due to several changes, 
including not generating unnecessary Java bridges.
  * pcmpy has been completely removed from the source tree now that 
better Python bindings are provided by cgrspy.
  * More comprehensive tests have been written for (and passed by) the 
units validation part of the Validation Against CellML Specification 
Service.

  * The precedence rules in the MATLAB CeLEDS XML file have been corrected.
  * The error handling in TeLICeMS has been improved.
  * A number of minor issues with the Doxygen generated documentation 
has been cleaned up so it is now easier to use.
  * A number of problems that made the PCM - Java bindings used for 
callbacks like the IntegrationProgressObserver unusable have been fixed.
  * Threading issues in the Java bindings have been fixed, preventing 
crashes when multiple threads are used.
  * The CellML API no longer automatically retrieves DTDs over the 
network, giving API users complete control over how models are loaded.

  * More sample code on how to use the RDF container APIs has been written.
  * The CellML API libraries now use versioning to avoid accidentally 
using the wrong version of the API; this allows multiple versions of the 
API to co-exist in the paths on the same system.
  * It is now possible to use a native libxml2 and SUNDIALS instead of 
the one shipped with the API by selecting an option at CMake configure time.

  * The order RDF triples are returned in is now more predictable.
  * Parallel builds now work correctly.
  * An RDF triple object can retrieved by subject, predicate, and 
object, allowing it to be unasserted straightforwardly.
  * A bug in CeVAS that meant it didn't look at nested encapsulation 
relationship_refs has been fixed.
  * New API operations have been added for retrieving annotations that 
don't throw exceptions (which are inefficient) when there is no 
annotation found.
  * A bug in the Java - PCM bridge enumeration support (important for 
public / private interface retrieval) has been corrected.


Best wishes,
Andrew
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Announcing CellML API 1.12

2012-11-01 Thread Andrew Miller

On 01/11/12 23:05, Andrew Miller wrote:

Hi all,

The CellML API release candidate version 1.11rc2 has been released with


Sorry, that should of course be 1.12rc2.


a minor change to correct uncertainty solvers as CellML API version 1.12.

The files making up this release candidate are available here:
   * http://cellml-api.sourceforge.net/download.html#1.12

This release candidate has a number of significant improvements over the
CellML API 1.12:


and that should be 'over the CellML API 1.11'.


   * Extra attributes are provided to make accessing a variable's
initial value more convenient.
   * IVs on algebraic variables is supported with initial_value rather
than RDF.
   * Documentation on using the CellML API from Java has been improved.
   * KINSOL, rather than LEVMAR, is used as the non-linear system
solver. This avoids the global state used by LEVMAR, allowing multiple
simulations to be working concurrently to return results more efficiently.
   * Error reporting for models underconstrained due to missing initial
values has been added.
   * It is now possible to use the DOM to determine the order of
elements in the CellML model and map from the DOM element to the CellML
element.
   * An ambiguity in the TeLICeMS serialiser around the nesting of the
equals operator has been fixed.
   * You can now create a CellML model from an existing DOM representation.
   * The C++ interface for performing query interfaces has been improved.
   * The generated binaries are smaller due to several changes,
including not generating unnecessary Java bridges.
   * pcmpy has been completely removed from the source tree now that
better Python bindings are provided by cgrspy.
   * More comprehensive tests have been written for (and passed by) the
units validation part of the Validation Against CellML Specification
Service.
   * The precedence rules in the MATLAB CeLEDS XML file have been
corrected.
   * The error handling in TeLICeMS has been improved.
   * A number of minor issues with the Doxygen generated documentation
has been cleaned up so it is now easier to use.
   * A number of problems that made the PCM - Java bindings used for
callbacks like the IntegrationProgressObserver unusable have been fixed.
   * Threading issues in the Java bindings have been fixed, preventing
crashes when multiple threads are used.
   * The CellML API no longer automatically retrieves DTDs over the
network, giving API users complete control over how models are loaded.
   * More sample code on how to use the RDF container APIs has been
written.
   * The CellML API libraries now use versioning to avoid accidentally
using the wrong version of the API; this allows multiple versions of the
API to co-exist in the paths on the same system.
   * It is now possible to use a native libxml2 and SUNDIALS instead of
the one shipped with the API by selecting an option at CMake configure
time.
   * The order RDF triples are returned in is now more predictable.
   * Parallel builds now work correctly.
   * An RDF triple object can retrieved by subject, predicate, and
object, allowing it to be unasserted straightforwardly.
   * A bug in CeVAS that meant it didn't look at nested encapsulation
relationship_refs has been fixed.
   * New API operations have been added for retrieving annotations that
don't throw exceptions (which are inefficient) when there is no
annotation found.
   * A bug in the Java - PCM bridge enumeration support (important for
public / private interface retrieval) has been corrected.

Best wishes,
Andrew
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Solicitation of feedback on CellML 1.2

2012-10-29 Thread Andrew Miller

On 29/10/12 22:36, David Nickerson wrote:

*Dear all,

At the 5th International CellML Workshop
http://www.cellml.org/community/events/workshop/2011/, we discussed
the main list of features that were desirable to have in CellML 1.2. The
CellML Editorial Board has been discussing the implementation of these
features in regard to the next version of the CellML standard. Early on,
we decided that the entire list of features arising from the workshop
was too broad and far reaching to accommodate an easy transition from
CellML 1.1 to CellML 1.2 in a timely manner. We have therefore selected
a subset of these features which we feel address immediate shortcomings
in the CellML 1.1 specification and introduce a minimal set of often
requested new features.

Tracker item 55
https://tracker.physiomeproject.org/showdependencytree.cgi?id=55shows
a detailed overview of our current plans. This is by no means meant to
be the final composition of CellML 1.2, but it reflects the current view
of the editorial board as to the types of models users wish to encode in
CellML and what is possible to implement in both the specification and
software tools.

Jonathan Cooper presented our thoughts on CellML 1.2 at the recent
COMBINE 2012 meeting http://co.mbine.org/events/COMBINE_2012/agenda.
Please see the slides and video of the presentation to get a more
consumable view of the proposed changes.

This email is to solicit specific feedback from the community regarding
the subset of changes that we have selected for inclusion in CellML 1.2.
The CellML 1.2 specification will mark a significant change in the way
the CellML standard is specified, and we hope that this change will
enable a more rapid process for standardising new features that
modellers require in order to encode and share their models using CellML.

 From tracker item 55
https://tracker.physiomeproject.org/show_bug.cgi?id=55, we would like
to highlight the following main changes that we think should be in
CellML 1.2:

  * Remove reaction element (tracker item 49
https://tracker.physiomeproject.org/show_bug.cgi?id=49);


+1


  * Remove the directional aspect of connections (tracker item 337
https://tracker.physiomeproject.org/show_bug.cgi?id=337);


+1


  * Replace grouping with a simplified encapsulation-only mechanism
(tracker item 356


+1


https://tracker.physiomeproject.org/show_bug.cgi?id=356);
  * Delayed variables (introduction of the evaluatedAtoperator with
reduced functionality to allow infinitesimal delays and initial
values) (tracker item 70
https://tracker.physiomeproject.org/show_bug.cgi?id=70).


+1




In addition, we specifically ask for feedback on the issue of moving to
MathML 3.0 (tracker item 67
https://tracker.physiomeproject.org/show_bug.cgi?id=67) and the
inclusion of stochastic variation in models (tracker item 2809
https://tracker.physiomeproject.org/show_bug.cgi?id=2809). The editors
generally agree that switching to MathML 3.0 at this time provides too
little benefit (mathematical clarity) for the cost involved in making
the change (tool support, interoperability with other exchange formats).


I think that it would be worth including MathML 3.0 in CellML 1.2 because:
  1. It makes implementation easier by providing clear rules about the 
mathematical interpretation of models.
  2. It is more cleanly extensible through the use of OpenMath content 
dictionaries.
  3. It is mostly forwards and backwards compatible with MathML 2.0 - 
nearly every MathML 2.0 expression is valid MathML 3.0, and you can 
write MathML 3.0 so it is valid MathML 3.0.
  4. The only implementation of the CellML 1.2 proposals so far has 
already been coded to use MathML 3.0 - so the cost in terms of tool 
support so far would actually be higher to change that implementation to 
support MathML 2.0.



While the proposal for stochastic variation is fairly mature, we feel
that it requires further work to meet the requirements for inclusion in
the CellML standard. We also think that given sufficient impetus from
the community this could be one of the first proposals to pass through
the new development process for CellML.


I'm not sure there even is a stochastic variation proposal (unless it is 
private to the editorial board). I put together a proposal for parameter 
uncertainty (which is different from stochastic variation - a system is 
stochastic if the relationship between the initial and a later state is 
not deterministic, while it has parameter uncertainty if the true 
initial state is not known).


I don't think there needs to be 'one CellML' that every tool implements 
exactly - parameter uncertainty is probably most appropriate as an 
officially endorsed secondary specification that adds to core CellML.


Best wishes,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Announcing CellML API 1.12 release candidate 2

2012-10-22 Thread Andrew Miller

Hi all,

The second release candidate for the CellML API 1.12 (1.12-rc2) has been 
released. This release candidate will become the CellML API 1.12 if 
no-one reports any problems with it by next Tuesday (New Zealand time). 
Please try out the the API and report any problems on the Physiome 
Tracker at https://tracker.physiomeproject.org/, by e-mailing 
cellml-tools-develop...@cellml.org (you will need to subscribe to the 
list first using this page: 
http://lists.cellml.org/mailman/listinfo/cellml-tools-developers), or by 
e-mailing ak.mil...@auckland.ac.nz.


The files making up this release candidate are available here:
  * http://cellml-api.sourceforge.net/download.html#1.12rc2

This release candidate has a number of significant improvements over the 
CellML API 1.12rc1:
  * Don't load DTDs when loading a document from text, as well as when 
loading from the network.
  * Increment the restart counter when trying to solve for initial 
conditions so we eventually fail after too many random re-starts.

  * Minor changes to the packaging scripts.

Best wishes,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Announcing CellML API 1.12 release candidate 1

2012-10-09 Thread Andrew Miller

Hi all,

The first release candidate for the CellML API 1.12 (1.12-rc1) has been 
released. This release candidate will become the CellML API 1.12 if 
no-one reports any problems with it by next Wednesday (New Zealand 
time). Please try out the the API and report any problems on the 
Physiome Tracker at https://tracker.physiomeproject.org/, by e-mailing 
cellml-tools-develop...@cellml.org (you will need to subscribe to the 
list first using this page: 
http://lists.cellml.org/mailman/listinfo/cellml-tools-developers), or by 
e-mailing ak.mil...@auckland.ac.nz.


The files making up this release candidate are available here:
  * http://cellml-api.sourceforge.net/download.html#1.12rc1

This release candidate has a number of significant improvements over the 
CellML API 1.11:
  * Extra attributes are provided to make accessing a variable's 
initial value more convenient.
  * IVs on algebraic variables is supported with initial_value rather 
than RDF.

  * Documentation on using the CellML API from Java has been improved.
  * KINSOL, rather than LEVMAR, is used as the non-linear system 
solver. This avoids the global state used by LEVMAR, allowing multiple 
simulations to be working concurrently to return results more efficiently.
  * Error reporting for models underconstrained due to missing initial 
values has been added.
  * It is now possible to use the DOM to determine the order of 
elements in the CellML model and map from the DOM element to the CellML 
element.
  * An ambiguity in the TeLICeMS serialiser around the nesting of the 
equals operator has been fixed.

  * You can now create a CellML model from an existing DOM representation.
  * The C++ interface for performing query interfaces has been improved.
  * The generated binaries are smaller due to several changes, 
including not generating unnecessary Java bridges.
  * pcmpy has been completely removed from the source tree now that 
better Python bindings are provided by cgrspy.
  * More comprehensive tests have been written for (and passed by) the 
units validation part of the Validation Against CellML Specification 
Service.

  * The precedence rules in the MATLAB CeLEDS XML file have been corrected.
  * The error handling in TeLICeMS has been improved.
  * A number of minor issues with the Doxygen generated documentation 
has been cleaned up so it is now easier to use.
  * A number of problems that made the PCM - Java bindings used for 
callbacks like the IntegrationProgressObserver unusable have been fixed.
  * Threading issues in the Java bindings have been fixed, preventing 
crashes when multiple threads are used.
  * The CellML API no longer automatically retrieves DTDs over the 
network, giving API users complete control over how models are loaded.

  * More sample code on how to use the RDF container APIs has been written.
  * The CellML API libraries now use versioning to avoid accidentally 
using the wrong version of the API; this allows multiple versions of the 
API to co-exist in the paths on the same system.
  * It is now possible to use a native libxml2 and SUNDIALS instead of 
the one shipped with the API by selecting an option at CMake configure time.

  * The order RDF triples are returned in is now more predictable.
  * Parallel builds now work correctly.
  * An RDF triple object can retrieved by subject, predicate, and 
object, allowing it to be unasserted straightforwardly.
  * A bug in CeVAS that meant it didn't look at nested encapsulation 
relationship_refs has been fixed.
  * New API operations have been added for retrieving annotations that 
don't throw exceptions (which are inefficient) when there is no 
annotation found.
  * A bug in the Java - PCM bridge enumeration support (important for 
public / private interface retrieval) has been corrected.


Best wishes,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Auckland CellML Meeting planned for Wednesday July 4th from 9-10 AM (NZST)

2012-07-02 Thread Andrew Miller

Hi,

There will be a meeting in Auckland to discuss the development of the 
CellML specifications tomorrow (Wednesday the 4th of July, at 9 AM 
NZST). The idea of this meeting is that it will allow members of the 
CellML community based in Auckland to express their views on development 
of the CellML specifications, and provide input to the CellML editors 
about the level of consensus on different matters about the 
specification within this subset of the CellML community.


Venue: Level 6 Access Node Room, 70 Symonds St, Auckland Bioengineering 
Institute.


If anyone wants to participate in the meeting remotely (e.g. over 
Skype), please let me know in advance and I can arrange remote access.


Proposed agenda:
  1. Discussion and confirmation of agenda (target: 9:00 - 9:05).
  2. Should CellML 1.2 be an incremental change over CellML 1.1, with 
another version planned shortly after, or should it try to incorporate a 
wider set of changes? (target: 9:05 - 9:25)

  3. Should MathML 3 be included in CellML 1.2? (target: 9:25-9:45)
  4. When should namespaces change? (target: 9:45-10:00)

Please let me know if you want to propose any additions or changes to 
the agenda.


Best wishes,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Auckland CellML Meeting planned for Wednesday July 4th from 9-10 AM (NZST)

2012-07-02 Thread Andrew Miller

On 03/07/12 11:34, Lucian Smith wrote:

I have one comment:

* Andrew Millerak.mil...@auckland.ac.nz  [2012-07-03 00:07] writes:

   2. Should CellML 1.2 be an incremental change over CellML 1.1, with
another version planned shortly after, or should it try to incorporate a
wider set of changes? (target: 9:05 - 9:25)

This strikes me as being the wrong question.  Instead I would ask, What
do we want to accomplish with CellML that cannot be accomplished with
1.1?  Then you look at the list of things you came up with, and classify
each into 'would be a small change' vs. 'would be a large change'.  Then,
finally, you look at the list of small changes and decide whether it's
worth it to have a release with just those changes vs. the whole list.  I
would think the MathML 3.0 question would fall out of this discussion,
too, rather than having to be a separate agenda item.
I would think that this could be part of the discussion, but not the 
whole discussion.


If the plan was to make the smallest possible incremental set of 
changes, then it absolutely would make sense to only change things if 
they currently impose a hard constraint on what can be modelled in CellML.


However, for CellML to be more useful, it needs wider tool support and a 
wider collection of available models, which means it needs a wider 
community. To expand the CellML community, barriers to community uptake 
need to be addressed. One barrier might be that people want to create 
types of models that cannot currently be represented in CellML. However, 
an even larger barrier is likely to be the complexity of implementing 
CellML and the ambiguities in its specification. Therefore, changes to 
the design which simplify the language, make it less ambiguous and more 
interoperable and extensible could be very important, even if they don't 
directly expand the range of models which can be represented in CellML.


Therefore, there are two competing approaches:
  1. smallest possible change set to represent additional types of 
models we want to represent.
  2. redesigning the language so that it is cleaner and more 
extensible, with the extensibility mechanisms meaning it might be a long 
time before we need to do another major compatibility breaking redesign.


I personally think that if 1 is going to break backwards compatibility 
anyway, we would be better off doing 2, and developing tools to convert 
between the new redesigned language and the old one.


Best wishes,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] New draft secondary specification: Uncertainty

2012-05-29 Thread Andrew Miller

On 29/05/12 20:17, Michael Clerx wrote:

Dear all,

I'm glad to see uncertainty being taken into acount in cell models.
Perhaps it would be worthwhile to add the scenario where no assumptions
are made about the uncertainty and a parameter value is simply given by
its upper and lower bounds.


I agree that there needs to be some way to handle that scenario. 
However, it might be that in most cases where people do that, a uniform 
distribution with upper and lower bounds will suffice - it seems to me 
that saying a random variable is distributed uniformly between an upper 
and lower bound is an explicit statement that the modeller knows that 
the value falls in certain bounds, but has no reason to believe it is 
any more likely to fall in one place within those bounds than anywhere else.


Such distributions already have a precedent of being used in Bayesian 
statistics as uninformative prior distributions.


Best wishes,
Andrew



kind regards,
Michael

On 05/29/2012 01:28 AM, Andrew Miller wrote:

Hi all,

I've just put up a draft secondary specification on how we could
represent parameter uncertainty within the context of my CellML 1.2
draft.

The secondary specification can be viewed here:
http://www.cellml.org/Members/miller/draft-secondary-spec-uncertainty/
The DocBook it is generated from can be checked out here:
https://github.com/A1kmm/cellml-uncertainty-secondary

It is written against this draft CellML 1.2 specification:
http://www.cellml.org/Members/miller/draft-normative-spec-andrews-preferred/

It builds upon, and refers to, the draft secondary specification for
models of differential-algebraic equations with optional events,
available here:
http://www.cellml.org/Members/miller/draft-secondary-spec-dae-events

Best wishes,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] New draft secondary specification: Uncertainty

2012-05-28 Thread Andrew Miller

Hi all,

I've just put up a draft secondary specification on how we could 
represent parameter uncertainty within the context of my CellML 1.2 draft.


The secondary specification can be viewed here:
  http://www.cellml.org/Members/miller/draft-secondary-spec-uncertainty/
The DocBook it is generated from can be checked out here:
  https://github.com/A1kmm/cellml-uncertainty-secondary

It is written against this draft CellML 1.2 specification:
  
http://www.cellml.org/Members/miller/draft-normative-spec-andrews-preferred/
It builds upon, and refers to, the draft secondary specification for 
models of differential-algebraic equations with optional events, 
available here:

  http://www.cellml.org/Members/miller/draft-secondary-spec-dae-events

Best wishes,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] trouble building on Ubuntu: for opencell build, told to build CellML API with XPCOM, but CellML API does not CMake with XPCOM support

2012-05-08 Thread Andrew Miller

On 09/05/12 16:43, Audette, Michel A. wrote:

Dear CellML users,

I have a recent version of Ubuntu, and when I try to build opencell, configure 
tells me

configure: error: The CellML API directory /usr/local did not contain 
interfaces/ICIS.xpt. Give the path to the CellML API with 
--with-cellml_api=/path/to/cellml_api. Ensure you built the API with XPCOM, 
Context, CCGS, CIS and CeLEDS support.

When I download the source tarball of cellml-api-1.10 or 1.11, in either case, 
when I set XPCOM support to ON with CMake, I get

CMake Error at build/xpcom.cmake:1 (MESSAGE):
XPCOM support needs to be ported to cmake; please do this and submit a
patch if you want to use it!

How can I simply get through the two builds?
OpenCell is no longer maintained in Auckland; instead, Alan Garny (based 
at Inria) is working on a complete rewrite which he is calling OpenCOR 
(Website: http://opencor.ws).


If you want to build OpenCell, you would need to use a version of the 
CellML API that was released around the same time as the version of 
OpenCell you are trying to build (note: the last release of OpenCell 
pre-dates the change to the CMake buildsystem), as the CellML API has 
changed over time and OpenCell isn't being updated to stay up to date 
with the changes.


I think Alan will be able to give you more information about OpenCOR and 
its status, such as whether it is suitable as a replacement for 
particular applications of OpenCell yet, and if not when it will be.


Best wishes,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] CellML API version 1.11 has been released

2012-05-01 Thread Andrew Miller

Hi all,

The CellML API release candidate version 1.11rc2 has been released 
unmodified as CellML API version 1.11. It can be downloaded from 
http://www.cellml.org/tools/downloads/cellml_api/releases/1.11


CellML API version 1.11 fixes a number of bugs in the CellML API version 
1.10, including some affecting code generation. It adds a new service, 
the CellML Generics and Reflection Service, and features improved 
documentation.  The C++ interface has changed to allow more idiomatic 
STL-based C++ code to be written. Python support has been separated out 
into a separate package that provides more convenient, more idiomatic 
Python support.


Please report any issues you find with the CellML API version 1.11, or 
direct any requests for support, to the Physiome tracker at 
https://tracker.physiomeproject.org/, to 
cellml-tools-develop...@cellml.org, or directly to ak.mil...@auckland.ac.nz.


Best wishes,
Andrew Miller

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Announcing CellML API 1.11 release candidate 2

2012-04-17 Thread Andrew Miller

Hi all,

The second release candidate for the CellML API 1.11 (1.11-rc2) has been 
released. This release candidate will become the CellML API 1.11 if 
no-one reports any problems with it by next Wednesday (New Zealand 
time). Please try out the the API and report any problems on the 
Physiome Tracker at https://tracker.physiomeproject.org/, by e-mailing 
cellml-tools-develop...@cellml.org (you will need to subscribe to the 
list first using this page: 
http://lists.cellml.org/mailman/listinfo/cellml-tools-developers), or by 
e-mailing ak.mil...@auckland.ac.nz.


The files making up this release candidate are available here:
  * http://www.cellml.org/tools/downloads/cellml_api/releases/1.11rc2

This release candidate fixes a few bugs found since the last release 
candidate - thanks to those who reported these bugs.


Additionally, it includes an extra build target on Windows - a Visual 
C++ build linked against MSVCRTD (the Debug CRT), suitable for use with 
code that is linked against the Visual C++ Debug CRT. The build target 
linked against the Visual C++ release CRT will continue to be included.


Best wishes,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Announcing CellML API 1.11 release candidate 1

2012-04-10 Thread Andrew Miller

Hi all,

The first release candidate for the CellML API 1.11 (1.11-rc1) has been 
released. This release candidate will become the CellML API 1.10 if 
no-one reports any problems with it by next Wednesday (New Zealand 
time). Please try out the the API and report any problems on the 
Physiome Tracker at https://tracker.physiomeproject.org/, by e-mailing 
cellml-tools-develop...@cellml.org (you will need to subscribe to the 
list first using this page: 
http://lists.cellml.org/mailman/listinfo/cellml-tools-developers), or by 
e-mailing ak.mil...@auckland.ac.nz.


The files making up this release candidate are available here:
  * http://www.cellml.org/tools/downloads/cellml_api/releases/1.11rc1

New features and bugfixes:
  * The CellML Generics and Reflection Service lets you write code that 
can access the list of available API services, operations, and 
attributes. This can be used to write generic code that works over the 
entire API without needing to hard-code the details of the part of the 
API being called. This has application for creating certain types of 
user interfaces, as well as for creating language bindings.
  * The Python bindings have been re-written and are now shipped as a 
Python egg, separately from the CellML API itself. The new Python 
bindings use the Generics  Reflection service to provide a more 
idiomatic and more convenient interface to the CellML API from Python.
  * A number of bugfixes have been made, including bugfixes to the code 
generation which could have resulted in bad numerical results.
  * The C++ interface has been revised to be more idiomatic - strings 
are now returned using the STL std::string and std::wstring types, and 
sequences are returned as std::vector types. Objects are returned using 
the already_AddRefd wrapper so users no longer need to use the 
RETURN_INTO_OBJREF macro to manage reference counts easily, instead they 
can simply assign into an ObjRef. The RETURN_INTO_OBJREF macros remain 
available for legacy code.


Best wishes,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] cellml-discussion Digest, Vol 87, Issue 10

2011-10-24 Thread Andrew Miller

On 25/10/11 09:14, David Nickerson wrote:

Hi Maxwell,

If you wrap the MathML into a CellML model/component, COR does a good
job generating Matlab. OpenCell should work as well. Actually, I think
OpenCell might be able to generate all the variables for you from the
equation, whereas in COR you might also have to create the variables
before it will let you export to Matlab.


To add to what David said, the CellML API includes a general facility 
for translating CellML into imperative languages, and a specific 
description of how to do this for MATLAB, and this was exposed in OpenCell.


There are a few problems with the generated MATLAB that have been found 
since the final release of OpenCell (which is no longer maintained in 
Auckland) that have been fixed in the API.


There is a program that comes with the API (and which exists purely for 
testing the API, rather than as a user friendly program) - if you build 
the CellML API from source code, you can run it as follows:


cd cellml-api
./testCeLEDS urlToModelHere ./CeLEDS/languages/MATLAB.xml

Hopefully OpenCOR, which is based on the CellML API, and being developed 
in Oxford, will expose this functionality in a user friendly way.


Best wishes,
Andrew



Cheers,
David.

On Tue, Oct 25, 2011 at 7:58 AM, Maxwell Nealmn...@u.washington.edu  wrote:

Hi all,

Does anyone know of a good java package for translating MathML into MATLAB?
Many thanks,

M

-
Maxwell Neal

Post-doctoral researcher
University of Washington
mn...@uw.edu
(206) 543-8769
-




On Oct 23, 2011, at 4:00 PM, cellml-discussion-requ...@cellml.org wrote:


Send cellml-discussion mailing list submissions to
   cellml-discussion@cellml.org

To subscribe or unsubscribe via the World Wide Web, visit
   http://lists.cellml.org/mailman/listinfo/cellml-discussion
or, via email, send a message with subject or body 'help' to
   cellml-discussion-requ...@cellml.org

You can reach the person managing the list at
   cellml-discussion-ow...@cellml.org

When replying, please edit your Subject line so it is more specific
than Re: Contents of cellml-discussion digest...


Today's Topics:

   1. Re: cellml-discussion Digest, Vol 87, Issue 9 (Maxwell Neal)


--

Message: 1
Date: Sat, 22 Oct 2011 19:02:16 -0700
From: Maxwell Nealmn...@u.washington.edu
Subject: Re: [cellml-discussion] cellml-discussion Digest, Vol 87,
   Issue 9
To: cellml-discussion@cellml.org
Message-ID:28198366-57cf-471f-8882-34e73fc05...@u.washington.edu
Content-Type: text/plain; charset=us-ascii

Great. Thanks, Lucian and David.

M

-
Maxwell Neal

Post-doctoral researcher
University of Washington
mn...@uw.edu
(206) 543-8769
-




On Oct 22, 2011, at 4:00 PM, cellml-discussion-requ...@cellml.org wrote:


Send cellml-discussion mailing list submissions to
  cellml-discussion@cellml.org

To subscribe or unsubscribe via the World Wide Web, visit
  http://lists.cellml.org/mailman/listinfo/cellml-discussion
or, via email, send a message with subject or body 'help' to
  cellml-discussion-requ...@cellml.org

You can reach the person managing the list at
  cellml-discussion-ow...@cellml.org

When replying, please edit your Subject line so it is more specific
than Re: Contents of cellml-discussion digest...


Today's Topics:

  1. Re: nested components in CellML (David Nickerson)


--

Message: 1
Date: Sat, 22 Oct 2011 14:30:37 +1300
From: David Nickersondavid.nicker...@gmail.com
Subject: Re: [cellml-discussion] nested components in CellML
To: CellML Discussion Listcellml-discussion@cellml.org
Message-ID:
  CADizRjhqHMOpDDm=8xoZLAD=bcognsm0xdlfma6yeox20k-...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Oct 22, 2011 at 10:10 AM, Lucian Smithlpsm...@spod-central.org  wrote:

* Maxwell Nealmn...@u.washington.edu  [2011-10-21 22:03] writes:

Hi all,

I was wondering - can CellML models have nested components? ?That is, are there 
instances where some model component is a component in another model component?
Thanks,


Yes--this is covered by the concept of encapsulation. ?See
http://www.cellml.org/getting-started/tutorials/tutorial/best_practice/#grouping
for more detail, but basically you set up a whole tree of nested
components, and this nesting determines the rules for how you can connect
the variables in those components.

Also, an imported component from another file that encapsulates other
components brings those components (and corresponding connections) with
it in the import.

Is that a reasonable summary, list denizens?


yep, I think that summarises it nicely. Importing along with
encapsulation allows the definition of models where some components
are components from another model.


Cheers,
Andre.



Re: [cellml-discussion] [cellml-dev] Draft DAEs / events secondary specification for CellML 1.2

2011-09-12 Thread Andrew Miller

On 12/09/11 20:30, Jonathan Cooper wrote:

Dear all,

I haven't gone through the detail of Andrew's draft, but a general point
occurred to me on reading the features list. Many tools would only
support a subset of these features (the most common being just ODEs with
no events). Does it make sense to require a secondary specification for
each combination of features, or should secondary specifications allow
for being combined to build up a desired feature set? In other words,
should the example instead be 3 specs (ODEs, DAEs, events) that can be
combined as a model author wishes?


Hi Jonathan,

I think the features potentially interact to some extent, so I don't 
think they are entirely directly composable. However, it would certainly 
be possible to build one secondary specification on top of one or more 
other specifications with same manual work to sort out some semantics.


I think we certainly could produce an ODEs spec, and a DAEs spec (so 
that software which suppports the DAEs spec would also support all 
models coded to ODEs), and a DAEs + events spec that would support 
models coded to the former two specs, as well as the infinitesimally 
delayed / boolean variables features needed for events.


Best wishes,
Andrew



Also, I can't recall whether there will be any mechanism for a model
document to declare which secondary specification(s) it uses, if any?

Best wishes,
Jonathan


On 12/09/2011 03:27, Andrew Miller wrote:

Hi all,

The draft CellML 1.2 specification I sent out last week
(http://www.cellml.org/Members/miller/draft-normative-spec-andrews-preferred/toplevel.xhtml)

is very generic and delegates the responsibility for narrowing down the
scope of CellML to something that can be implemented to secondary
specifications.

To get an idea of what a secondary specification might look like, I've
created a draft for models with the following features:
* Differential algebraic equations (including ODEs) are supported.
* There can be multiple dependent variables, but only one independent
variable.
* Basic events can be handled using boolean variables and piecewise
based rules to make changes when events happen.

The draft is available at:

http://www.cellml.org/Members/miller/draft-secondary-spec-dae-events/toplevel.xhtml


It is also up on GitHub:
https://github.com/A1kmm/cellml-dae-events-secondary

Best wishes,
Andrew
___
cellml-tools-developers mailing list
cellml-tools-develop...@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-tools-developers

___
cellml-tools-developers mailing list
cellml-tools-develop...@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-tools-developers


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] CellML API 1.10rc2 available now

2011-09-06 Thread Andrew Miller

Hi all,

I have just made release candidate 2 for the CellML API, version 1.10.

This release candidate will become the CellML API 1.10 if no-one finds 
any problems with it by next Wednesday (New Zealand time).


Please try it out and let me know if there are any problems with it.

The page about the release candidate:
  http://www.cellml.org/tools/downloads/cellml_api/releases/1.10rc2

Changes since rc1:
=
A reference counting race condition with CIS and SRuS was fixed by 
making reference counting threadsafe everywhere.


The .hg subdirectory containing the revision history is no longer 
packaged up into the source tarball, making it much smaller.


The binary installers no longer force you to click through the license, 
making it easier to automate installation (there is no actual change to 
the license, just how it is displayed).


The Linux SDK packages now include the processor type in the file name.

Best wishes,
Andrew Miller
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Proposed write-up

2011-09-05 Thread Andrew Miller

Hi all,

I've written a draft CellML 1.2 Core Specification that tries to put 
together all the current proposals the community seems to have reached 
consensus on.


It is available at:

http://www.cellml.org/Members/miller/draft-normative-spec-andrews-preferred/toplevel.xhtml

Please send any feedback to the cellml-discussion mailing list, or put 
it up on the tracker.


Best wishes,
Andrew
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Minutes of Auckland CellML Meeting, 24th of August

2011-08-28 Thread Andrew Miller

Hi all,

Please find the minutes at:
  http://www.cellml.org/community/meeting/minutes/2011/08.24

Best wishes,
Andrew
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] CellML API 1.9 released

2011-05-31 Thread Andrew Miller

Hi all,

Release version 1.9 of the CellML API and CellML API implementation has 
been made. This release implements a number of important new features 
over version 1.8, as well as providing a number of bug fixes:
* passthrough support added to CIS, making it easier for tools to 
embed code in expressions (for example, as a first stage in transforming 
a model).
* A new optional extension service called TeLICeMS has been 
implemented, allowing CellML models to to be converted to a text-based 
representation, and vice versa.
* A new optional extension service for working with SED-ML has been 
added; so far, only SED-OM manipulation is supported (no ability to 
actually run simulations yet, only to manipulate descriptions of them).

* Better Python and Java binding support.
* Support for building an 'SDK' - a collection of all the needed 
files. These are now shipped with releases.


The release (including source code and binary SDKs for x86 Linux, x86 
Mac, and Windows 32 bit) can be downloaded from:

  http://www.cellml.org/tools/downloads/cellml_api/releases/1.9

A new page has been put together to help developers who are new to the 
CellML API get going with the binary releases of the API, and is 
available at:

   http://www.cellml.org/tools/api/docs/getting-started-with-the-cellml-api

Best wishes,
Andrew Miller
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] First unofficial draft of specification on CellML parameter uncertainty

2011-05-29 Thread Andrew Miller

Hi all,

I've put together an unofficial draft specification on how uncertainty 
in CellML parameters could be represented.


The first draft of this document is attached as a PDF; please let me 
know what you think.


The specification is in DocBook; the source code and scripts to generate 
PDF and XHTML from it are on github at:

  https://github.com/A1kmm/cellml-uncertainty

If you are proposing substantial changes, the preferred format is as a 
change to the DocBook in a public git repository, but I am willing to 
manually merge in suggested changes in any form.


Please let me know if you have any comments on the document.

The next stage will be to try to implement the specification so the 
specification has some implementation experience.


Best wishes,
Andrew


CellML-Uncertainty.pdf
Description: Adobe PDF document
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] SBML L3 dist package

2011-05-24 Thread Andrew Miller

Hi Darryl,

I'm working on approaches for representing parameter uncertainty in 
CellML, and was wondering if you had any more recent draft 
specifications for the SBML dist package than the 2005 version on the 
SBML site (which currently only seems to have the 2005 draft and your 
presentation from 2010) that you were willing to share?


I think the realisastions based approach discussed in your 2010 
presentation could be a good way to go in CellML for representing 
distributions, alongside either a fixed set of univariate and 
multivariate distributions or a general facility for describing a 
distribution (possibly as a series of univariate distributions, 
optionally conditional on other parameters, including other randomly 
sampled parameters) from p.d.fs (solver software would either pattern 
match for known p.d.fs, or try to analytically or numerically invert the 
function).


We obviously also need some kind of operator to say that a parameter has 
a fixed but uncertain value, and that a given distribution is the 
probability distribution for the parameter (I think using MathML to 
describe that, with a csymbol operator, would be the most consistent 
with the approach taken in CellML); for example, if we believe that 
parameter x has a fixed value:


e.g. x(0) ~ N(mu=0, sigma^2 = 1)

  apply
csymbol 
definitionURL=http://www.cellml.org/1.2#uncertainWithDistribution/

apply
  csymbol 
definitionURL=http://www.cellml.org/1.2#atBoundVariableValue/

  cix/ci
  cn cellml:units=second0/cn
/apply
apply
  csymbol 
definitionURL=http://www.cellml.org/1.2#distributionFrompdf/

  apply
csymbol definitionURL=http://www.cellml.org/1.2#normalpdf/
cn cellml:units=metre0/cn
cn cellml:units=square_metre1/cn
  /apply
/apply
  /apply

Or (x(0), y(0)) ~ a distribution from realisations...

  apply
csymbol 
definitionURL=http://www.cellml.org/1.2#uncertainWithDistribution/

vector
  apply
csymbol 
definitionURL=http://www.cellml.org/1.2#atBoundVariableValue/

cix/ci
cn cellml:units=second0/cn
  /apply
  apply
csymbol 
definitionURL=http://www.cellml.org/1.2#atBoundVariableValue/

ciy/ci
cn cellml:units=second0/cn
  /apply
/vector
apply
  csymbol 
definitionURL=http://www.cellml.org/1.2#distributionFromRealisations/
  !-- For consistency with the univariate case, this represented 
in MathML as a 'vector of vectors' rather than a matrix; we could 
perhaps treat a MathML matrix as syntactic sugar for a vector of vectors 
anyway. --

  vector
vectorcn units=metre1/cncn units=metre2/cn/vector
vectorcn units=metre3/cncn units=metre3/cn/vector
vectorcn units=metre1/cncn units=metre5/cn/vector
vectorcn units=metre2/cncn units=metre4/cn/vector
vectorcn units=metre1/cncn units=metre5/cn/vector
vectorcn units=metre1/cncn units=metre3/cn/vector
vectorcn units=metre3/cncn units=metre5/cn/vector
vectorcn units=metre2/cncn units=metre5/cn/vector
vectorcn units=metre1/cncn units=metre4/cn/vector
vectorcn units=metre3/cncn units=metre5/cn/vector
!-- And so on - obviously this could lead to big files... --
  /vector
/apply
  /apply

Any comments you may have on this approach would be greatly appreciated.

Best wishes,
Andrew
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] CellML API Release Candidate 4 out

2011-05-23 Thread Andrew Miller

Hi all,

Release candidate 4 for the CellML API 1.9 has been released at:
  * http://www.cellml.org/tools/downloads/cellml_api/releases/1.9rc4

The only difference from the previous release candidate is that this one 
adds a missing header file to the SDK binary packages.


If no further problems with the release candidate are identified, a 
release of CellML API 1.9 will be made shortly.


Please report any bugs you find on the tracker at 
https://tracker.physiomeproject.org/, or failing that to 
cellml-tools-develop...@cellml.org, or to ak.mil...@auckland.ac.nz.


Best wishes,
Andrew Miller
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] CellML API 1.9 release candidate 3 out

2011-05-17 Thread Andrew Miller

Hi all,

A further release candidate for CellML API version 1.9 has just been 
released, and can be seen at:

   http://www.cellml.org/tools/downloads/cellml_api/releases/1.9rc3

The SDK binaries have been tested to work for compiling a simple program 
(in both C++ and Java), as documented at:

  http://www.cellml.org/tools/api/docs/getting-started-with-the-cellml-api

Please report any bugs you find on the tracker at 
https://tracker.physiome-project.org/ or failing that, to the 
cellml-tools-developers list or directly to me.


Best wishes,
Andrew
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] CellML API 1.9 Release Candidate 2 available now

2011-05-03 Thread Andrew Miller

Hi all,

Release candidate 2 for the CellML API 1.9 has been released, and can be 
downloaded from:

  * http://www.cellml.org/tools/downloads/cellml_api/releases/1.9rc2

The following are provided with this release candidate:
  * Source code
  * Binary CellML API SDK packages for:
  * Linux - x86 (32 bit) built with gcc4.
  * Mac OS X - x86 built with gcc4.
  * Windows x86 built with MSVC9.

This release candidate fixes issues with the binary packaging from the 
previous release candidate (the Java jar files are now included, the .so 
files are included on Mac OS X, and the symbolic links are stored in the 
tarball as symlinks now, so there is no need to manually create symbolic 
links to particular versions to make the program run). Some limited 
documentation has been developed, and is available at:

  http://www.cellml.org/tools/api/docs/getting-started-with-the-cellml-api

This is the second release candidate ahead of the first release to 
include binaries with it, so I would particularly appreciate feedback 
about whether or not the binary 'SDK' builds include everything you need.


All going well, the CellML API version 1.9 will be released shortly.

Problems should be reported to the tracker at:
  https://tracker.physiomeproject.org/
or failing that, directly to ak.mil...@auckland.ac.nz or the 
cellml-tools-develop...@cellml.org mailing list.


Best wishes,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] CellML API 1.9 Release Candidate 1 available now

2011-04-26 Thread Andrew Miller

Hi all,

Release candidate 1 for the CellML API 1.9 has been released, and can be 
downloaded from:

  * http://www.cellml.org/tools/downloads/cellml_api/releases/1.9rc1

The following are provided with this release candidate:
  * Source code
  * Binary CellML API SDK packages for:
  * Linux - x86 (32 bit) built with gcc4.
  * Mac OS X - x86 built with gcc4.
  * Windows x86 built with MSVC9.

This is the first release to include binaries with it, so I would 
particularly appreciate feedback about whether or not the binary 'SDK' 
builds include everything you need.


All going well, the CellML API version 1.9 will be released shortly.

Problems should be reported to the tracker at:
  https://tracker.physiomeproject.org/
or failing that, directly to ak.mil...@auckland.ac.nz or the 
cellml-tools-develop...@cellml.org mailing list.


Best wishes,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Unofficial draft CellML specification - backwards compatibility, type attributes on variables

2011-02-01 Thread Andrew Miller

Hi all,

I've just put up an unofficial draft CellML specification up at 
http://www.cellml.org/Members/miller/draft-normative-spec-andrews-preferred/toplevel.xhtml 
to prototype what some of the new features could look like.


This version has the following features:
  Backwards and forwards compatibility with CellML 1.1.
  A new attribute, type, on variables. It defaults to real, but can 
alternatively point to a URL defining the type (it is up to secondary 
specifications to define the meaning of URLs other than the one for real 
values defined in the specification).


The source for generating the specification and creating your own draft 
version is up at http://repo.or.cz/w/cellml-draft-miller.git - the 
andrews-preferred-version branch was used to generate the XHTML linked to.


Best wishes,
Andrew
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] ABI CellML Meeting Minutes, 15th December 2010

2010-12-16 Thread Andrew Miller

Hi all,

I have put the minutes from this week's meeting up at:
  http://www.cellml.org/community/meeting/minutes/2010/12.15

Best wishes,
Andrew
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Exponentiating in OpenCell

2010-09-07 Thread Andrew Miller

On 08/09/10 08:38, Erin wrote:

Hello,

I'm trying to use OpenCell to structure a model, but I'm having trouble
using the equation editor.  I'm typing in equations like the tutorial
recommends and I'm using the character ^ to exponentiate.  OpenCell
doesn't seem to recognize that character, so how I should I express
exponents?


Hi Erin,

You can use exp(number) or equivalently power(exponentiale, number)

I think the tutorial might need updating.



Also, is there a better way to export the cellML that is more readable
than what is in the XML tab?  The XML tab is not formatted at all and is
very difficult to read, and that is also how the saved file looks when
opened in a text editor.  The export feature does not work at all for me.


You can right click on the model in the left hand 'model listing' 
control (or the equivalent for Mac), then choose 'Format nicely'. Then 
save the model, and it will be formatted according to standard rules.


Best wishes,
Andrew



I'm using OpenCell 0.7 for Mac OSX with OSX version 10.6.4.

Thanks,

Erin

--
Erin Rachael Shellman
The University of Michigan
Bioinformatics PhD Candidate
http://www.erinshellman.com
shell...@umich.edu mailto:shell...@umich.edu
(937) 321.1129



___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Fwd: Multiple independent parameter support in the CellML API

2010-07-20 Thread Andrew Miller

Hi all,

This may be of interest to some people on this list.

Best wishes,
Andrew

 Original Message 
Subject: Multiple independent parameter support in the CellML API
Date: Thu, 15 Jul 2010 12:05:40 +1200
From: Andrew Miller ak.mil...@auckland.ac.nz
To: Chris Bradley c.brad...@auckland.ac.nz,  Randall Britten 
r.brit...@auckland.ac.nz, David Nickerson d.nicker...@auckland.ac.nz


Hi Chris, Randall, and Andre (please forward on to any other developers
who may also be useful if I missed anyone).

The CellML API that OpenCMISS has been waiting for a long time for,
namely the ability to choose which variables are independent parameters,
has now been implemented:
  Tracker item: https://tracker.physiomeproject.org/show_bug.cgi?id=1952

I have added a new feature to the CellML Code Generation Service, called
Custom Code Generation. With custom code generation, the user gets to
specify groups of computation targets (computation targets are a
particular derivative - including the '0th' derivative - i.e. the
undifferentiated value of a particular group of one or more connected
variables).

The groups are:
  known - that is, controlled externally from the code to be generated.
 Examples: independent variables like time.
   constants set from within the calling code.
   etc...
  wanted - these are what the code to be generated should compute.
 Example: the output wanted from a constitutive law.

  unwanted - these are variables that the code should not compute under
any circumstances, not even to use as intermediates.
 Example: known state variables when you are trying to work out
constants only.

Note that custom code generation does not take into account initial
value attributes at all, because it doesn't know if you will only run
the generated code at the intended point or not. It is the
responsibility of the programmer using the custom code generation to
handle initial values if required.

By default, storage for all computation target is allocated in one
array, but you can manually name computation target storage whatever you
like, and therefore control storage to your liking - look at the example
code in CellML2C for how to do this.

I would be grateful if you could have a look at the interface
(interfaces/CCGS.idl in the source tree, look at createCustomGenerator
on the CodeGenerator interface, and the CustomCodeGenerator and
CustomCodeInformation interfaces), and the test / example program in
CCGS/tests/CustomGen.cpp, and add comments to the tracker item if I have
missed anything you need for this.

Best wishes,
Andrew
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Fwd: Haugh 2004b

2010-03-10 Thread Andrew Miller

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 lpsm...@spod-central.org 
mailto:lpsm...@spod-central.org

*Date: *11 March 2010 9:01:27 AM
*To: *Catherine Lloyd c.ll...@auckland.ac.nz 
mailto:c.ll...@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.ll...@auckland.ac.nz 
mailto:c.ll...@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 

Re: [cellml-discussion] ABI CellML meeting minutes 2009-12-16

2009-12-18 Thread Andrew Miller

alan.ga...@dpag.ox.ac.uk wrote:

James Lawson wrote:

We (Catherine, Poul and I) were thinking that there are basically
three places where you'd want to display / store this information
within PMR2: in the metadata itself (thereby allowing it to be
rendered by software, indexed and searched etc.), on the exposure
somewhere (perhaps a rendering of the metadata,) and in the proposed
blanket, site-wide 'terms of use' page.

As Catherine has mentioned in the relevant tracker item (don't have
the number on hand,) one of the issues which we must now decide on is
whether to require that all models in the repository abide by CC
attrib 3 or whether users can specify special cases.


We should be open and therefore allow people to go for whatever license
they want. However, they should be made aware that by doing so, they take
the risk of their model not being used, etc. This being said, some authors
might still prefer that outcome to not having their model on the CellML
repository?


Hi Alan,

Allowing people the ability to choose other licenses is something that I 
think can go into later releases of the repository; however, until then, 
the simplest thing to do is just to require that people need to license 
the model under the Creative Commons Attribution License.


If we do allow other licenses, we do need to make sure that the license 
allows us to distribute the model to everyone who asks for it through 
the model repository - so a manual process of review of any new licenses 
would probably be required (but we could let users choose from several 
licenses we had pre-approved).


I don't think that requiring people to license their contributions under 
a particular license is contrary to the principle of being open - the 
copyright holder of the model can freely license it under the terms and 
submit the model, and this ensures that everyone can download and adapt 
models from the repository - which is more open than it would be if some 
parts of the repository were more restricted.


Best wishes,
Andrew



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


[cellml-discussion] Tracker / subversion outage tonight 9:30 PM to 11:30 PM

2009-12-16 Thread Andrew Miller

Hi all,

The Physiome tracker and Subversion repositories containing software 
snapshots will be unavailable tonight from 9:30 PM until 11:30 PM NZDT 
(8:30 AM - 10:30 AM GMT) when power will be switched from the generator 
to mains power, following the power failure last night affecting the 
building housing the Auckland Bioengineering Institute.


Hopefully everything should come back up after this, although there were 
some technical problems with the tracker following the power outage last 
night.


I apologise for any inconvenience this may cause people.

Best wishes,
Andrew
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Description of CellML groupings

2009-12-08 Thread Andrew Miller

Dominick Layfield wrote:

Hi Catherine,

Thanks for raising these issues.  I would be more than happy to read and 
comment on any material in the 1.2 spec or any revisions to the 
tutorial.  I appreciate that this is being looked into.


Hi Dominick,

Catherine has told me that you have found the part of the CellML 1.1 
specification relating to the interpretation of grouping to be 
ambiguous. I'm CCing this to the cellml-discussion mailing list, which 
is a good place to discuss the CellML discussions (you need to subscribe 
at http://www.cellml.org/mailman/listinfo/cellml-discussion before you 
can post to the list).


The plan going forward is to have two descriptions of CellML:
  - a normative description. This description uses precise technical 
language, and will be the official description of CellML which should be 
referred to in the case of any conflict between the documents, or 
ambiguity in the other documents. It won't contain any information which 
is unnecessary to achieve this purpose (so as to avoid accidentally 
contradicting itself).
  - an informative tutorial on CellML. This document will include 
examples, and will be based on the normative description. It can be 
updated to improve clarity and ensure that it properly reflects the 
normative description.


Because everything depends on the normative description, we are working 
on completing that first.


Due to the draft nature of the work, there is no one 'official' draft - 
but I will refer you to one draft which has been modified from the base 
to simply the connection element:

http://www.cellml.org/Members/miller/draft-normative-spec-simplify-connections/toplevel.xhtml

http://www.cellml.org/Members/miller/draft-normative-spec/toplevel.xhtml 
is more similar to CellML 1.1.


The section Interpretation of grouping provides precise rules, in 
terms of graph theory, about which elements can legitimately be connected.


Best wishes,
Andrew



-- Dominick


On 12/08/2009 03:47 PM, Catherine Lloyd wrote:

Dear Dominick

I raised your two comments about needing a better description of CellML
groupings and also a CellML 1.1 model building tutorial at today's team
meeting.

Regarding the first comment, Andrew Miller has been working on the
CellML 1.2 specification (currently a draft) and he will send you a link
to it - asking if the description is any clearer in the new spec (there
is a normative and an informative version of the 1.2 spec - hopefully
Andrew will send you both.

Regarding the second point (on the 1.1 tutorial) - the agenda item will
be raised again at next week's meeting when 3 other key people will be
present, and we will think about the best approach.

Thanks again for your interest in CellML.

Best wishes
Catherine






___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Stochastic support / non-exclusion in CellML 1.2

2009-10-13 Thread Andrew Miller

Michael Cooling wrote:

Hi

I'm still interested in the below. Does anyone have any information 
beyond the comment I cite below?


In particular, might I be able to read the document that Andrew wrote?


Hi Mike,

We don't have much in the way of a well-developed document; but a brief 
proposal was included in this message:

http://www.cellml.org/pipermail/cellml-discussion/2008-April/001231.html

This is something that we need to put more work into before we have 
anything generally useful, so please feel free to continue from where we 
are up to in that document.


Also, you might want to listen to my conversation with Kevin Burrage; 
although most of the call is really about trying to explain to Kevin 
that we are interested in declarative representations, rather than a 
specific algorithm. Go to http://www.gcast.com/u/millerak/main for the 
audiocast.


Best wishes,
Andrew



Cheers,



Quoting Mike Cooling m.cool...@auckland.ac.nz:


Hi



I would like to get a rough idea of the possibility of stochastic
modelling support by CellML in 'the future'.



There is a reference to some work done by Andrew in this area in a 
meeting

minute from mid 2008 (reproduced below).



Is this the last time work was done in this area ( to the best of your
knowledge ) and is there any way I can read a copy of some document
outlining 'Andrew's proposal on how to represent stochastic systems...' ?



Thanks for your time,



Mike.





CellML 1.2 specification update

*Andrew talked with Kevin Burrage last Friday about how stochastic
systems might potentially be represented in CellML 1.2
*The audiocast of this conversation can be found at:
http://www.gcast.com/u/millerak/main
*The conversation was useful but Andrew's proposal on how to
represent stochastic systems in CellML 1.2 still stands as it was.
*Presently no further discussions with Kevin Burrage are scheduled.
*There are a number of classes of stochastic systems we could
represent. Andrew's proposed approach is to allow generic representation
and then identify specific classes, such as systems described by the
Gillespie algorithm.
*Andrew noted that while we don't have to explicitly provide a
representation of stochastic systems in CellML 1.2, we should be making
1.2 generic enough to allow for a secondary specification representing
these systems.











This message was sent using IMP, the Internet Messaging Program.



___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] The CellML library basics

2009-07-27 Thread Andrew Miller

Lucian Smith wrote:

* Justin Marsh j.ma...@auckland.ac.nz [2009-07-28 00:31] writes:
  

Hi Lucian,

The basic C++ should have two functions for each member attribute,  
named after the attribute; one with no arguments, which returns the  
value of the attribute, and one with one argument which sets the value  
of the attribute.


So, to set the name you would call
model-name(Lmodelname);
And to get the name, you would call
model-name();

These specific functions are located in  
./sources/cellml/CellMLImplementation.cpp



Thanks!  Is there information like this in the documentation somewhere?  
I'd rather not have to bug you all every time I have a basic question like 
this.
  

Hi Lucian,

I'm moving this to the cellml-tools-developers list; it is a good one 
for questions relating to tools that process CellML as some people get 
upset if there is too much software related discussion on cellml-discussion.


We are a bit lacking on some aspects of documentation for API users, as 
you have discovered. We have some information on the PCM - Physiome C++ 
Mapping in the docs subdirectory, but maybe not enough high-level 
documentation to get people started. It is often difficult for people 
already familiar with things to identify what new developers need to 
know the most, and so if you have created any documentation / notes / 
comments on what you discovered early  on, it would be very useful to 
other people starting out with the API (or at least to aid the process 
of documentation), and so contributing it back would be useful. The 
Physiome Tracker would be a good way to manage correspondence with 
respect to documentation. See https://tracker.physiomeproject.org


Best wishes,
Andrew


-Lucian
___
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] 'Model' has pure virtual functions

2009-07-23 Thread Andrew Miller

Lucian Smith wrote:
I am just starting to use the CellML DOM API in C++, and am running into 
problems.  Everything compiled fine (I'm using v1.6), but I seem to be 
unable to declare 'Model' objects because they contain pure virtual 
functions:


This code:

 cellml_api::Model model;

Hi Lucian,

Model is an interface, not a concrete class. The way the API works is 
that you always work with interfaces, but you never directly create them 
directly. Instead, you need to use one of the bootstrap methods to get 
access to an interface for the first object, and then from there use the 
interfaces to get to everything else you need (working with pointers).


See the test programs like the unit tests, and CellML2C, to get an idea 
of how to call the API from C++.


Best wishes,
Andrew




gives me the error:

src/module.cpp:1570: error: cannot declare variable 'model' to be of 
abstract type 'iface::cellml_api::Model'
/usr/local/include/IfaceCellML_APISPEC.hxx:163: note:   because the 
following virtual functions are pure within 'iface::cellml_api::Model':
/usr/local/include/Ifacexpcom.hxx:25: note: 	virtual void 
iface::XPCOM::IObject::add_ref()
/usr/local/include/Ifacexpcom.hxx:26: note: 	virtual void 
iface::XPCOM::IObject::release_ref()


(etc. etc.)

Is there a subclass of 'Model' that I need to use instead?  The example 
seems to just use 'Model', but it's in Java.


-Lucian

(Also, the 'Issue tracker' and 'Support' links on 
http://www.cellml.org/tools/downloads/cellml_api are broken.)


(Also also, all mailman links are also broken, though mailman itself seems 
to be running.)

___
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] ABI Meeting minutes 2009-05-06

2009-05-06 Thread Andrew Miller

Dougal Cowan wrote:

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

http://www.cellml.org/meeting_minutes/abi-meeting-minutes-2009-05-06/
It is worth noting that the changes I sent earlier today weren't 
included in the minutes:



Hi all,

A few extra things:
4) Andrew will add a tracker item about [alternative graphical platforms]
Andrew has done this, and there has been some discussion on the tracker 
about the issue, including from David Nickerson, Alan Garny, and Carey 
Stevens.


and futher down add two bullet points to:

5) OpenCell development - update

Andrew mentioned that he had been looking into some of the options for 
the graphical platform.
He has also continued with the work on refactoring the model tree view 
so that the metadata support can be implemented more easily.


Best wishes,
Andrew


I also think we need to consider giving people a bit longer to reply to 
draft minutes (especially if there is not enough time to ensure that 
suggested changes get included).


It is important that if we are claiming that people have said things, 
they have a proper chance to review what we claim they said beforehand.


Best wishes,
Andrew



Dougal


This message was sent using IMP, the Internet Messaging Program.

___
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


[cellml-discussion] ABI Meeting minutes 2009-04-29

2009-05-05 Thread Andrew Miller

Hi all,

I have put the minutes from last Wednesday's meeting up at:
http://www.cellml.org/meeting_minutes/abi-meeting-minutes-2009-04-29/

Apologies to those who would have liked to see these sooner.

Best wishes,
Andrew
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Using a functional programming language to express models

2009-04-21 Thread Andrew Miller

Hi all,

I have created a tracker item to discuss the possibility of using a 
functional programming language to express models. Please see my 
description of how it could be done, add any comments you have on the 
idea there.


Best wishes,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Using a functional programming language to express models

2009-04-21 Thread Andrew Miller

Andrew Miller wrote:

Hi all,

I have created a tracker item to discuss the possibility of using a 
functional programming language to express models. Please see my 
description of how it could be done, add any comments you have on the 
idea there.


My apologies, I missed out the tracker item link. The relevant tracker 
item is tracker item 1727, at


https://tracker.physiomeproject.org/show_bug.cgi?id=1727



Best wishes,
Andrew

___
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


[cellml-discussion] Proposal to re-structure CellML mailing lists

2009-04-21 Thread Andrew Miller

Hi all,

I have created a tracker item for the proposal to restructure the CellML 
mailing lists, as the current structure of team and cellml-discussion 
(originally intended to avoid conflating technical and non-technical 
issues on the same list) isn't necessarily working as well as we would 
hope it would, as discussed in the tracker item.


The new proposal, to replace team and cellml-discussion with 4 lists is 
discussed at:

 https://tracker.physiomeproject.org/show_bug.cgi?id=1728

Please add any comments you may have to that tracker item.

Best wishes,
Andrew
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] cellml namespaces

2009-03-18 Thread Andrew Miller

Alan Garny wrote:

Agreed, that wouldn't harm.
  
A link to the CellML specification and some of the other existing 
content should be sufficient.


Best wishes,
Andrew


Alan

  

-Original Message-
From: cellml-discussion-boun...@cellml.org [mailto:cellml-discussion-
boun...@cellml.org] On Behalf Of James Lawson
Sent: 19 March 2009 14:35
To: CellML Discussion List
Subject: [cellml-discussion] cellml namespaces

Hi all,

I've been snooping around the website and I noticed that if you actually
go to the links for our current live namespaces, you don't find anything
particularly interesting.

See:

http://www.cellml.org/cellml/1.0/
http://www.cellml.org/cellml/1.1/
http://www.cellml.org/metadata/1.0/

The page for all these links currently says:

This is the target for the CellML 1.0 namespace prefix. Currently there
is nothing useful here. As the specification is developed, documentation
on each of the elements and attributes in the CellML namespace will be
added.

In the meantime, why not have a poke around the CellML website at

http://www.cellml.org/.

Note that a namespace URI provides a unique identifier for a particular
dictionary of CellML elements. It need not link to a schema or DTD.

Given that the meantime has now been a number of years, I propose that we
put something more useful up at these URLs.

What do people think?

Kind regards,
James




___
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


[cellml-discussion] Example models using possible CellML 1.2 lambda calculus type system notation

2009-02-17 Thread Andrew Miller

Hi all,

In response to a request by Poul Nielsen, I have produced a model 
demonstrating how this functionality might be used.


type_library.cellml is the beginnings of a type library, which provides 
a complex number type and some other types needed to support it. The 
complex number type is actually a function which takes a 'base type' and 
returns a type. For example, if you wanted to represent a 'vector' in a 
plane in metres as a complex number, you can call the function which 
returns a type with real_metres as the argument to get a type for 
storing a number of metres. This form implicitly requires that both 
cartesian co-ordinates have the same type.


Also included is a library of utilities for working with these complex 
numbers to get the cartesian and polar co-ordinates.


Writing this up has identified several places where there is room for 
improvement:
 = We require that the type attribute is present on variables in every 
component it is used (not just one of them), and these types are also 
variables which must be present everywhere. If types are all of type 
type, this isn't as bad, because it means that we only require one extra 
variable. However, if we only required that the type attribute was 
present in one of the connected network of variables (but allowed it to 
be present in more as long as the types match) we would reduce the 
burden on model authors.
 = Wildcard types, or even some sort of type inheritance scheme once 
more looks quite helpful. For example, we have a function called 'sign' 
which returns 1, 0, or -1 depending on the sign of the input. But we 
have to explicitly say what the type of the input is (not just 'any kind 
of real number' for instance). There will be many similar cases. 
Sometimes this is a good thing as it provides additional type safety, 
but in other cases, it is bad. We could have a unidirectional concept of 
compatibility as used in inheritance hierarchies (so for example, 
real_metre matches real_anything, but real_anything doesn't match 
real_metre, since real_metre inherits from real_anything). This can be 
worked around by using functions which return types, or by using the 
trick we used in type_utilities of having a variable you connect up to 
correct type, but the cost of having one import or defining a type just 
to call a basic function puts a lot of burden on model authors and makes 
models rather verbose.


Best wishes,
Andrew

c11:model xmlns:c11=http://www.cellml.org/cellml/1.1#; 
xmlns:c12=http://www.cellml.org/cellml/1.2#; 
xmlns:m=http://www.w3.org/1998/Math/MathML;
  c11:component name=TypeLibrary
!-- type_from_type_function_type: The type of a function which takes a 
type and returns a type. --
c12:variable name=type_from_type_function_type type=type 
public_interface=yes /
!-- cartesian_complex_type_function: A function which converts a scalar 
type (parameter)
   into the type of the cartesian form of the complex number as a 
vector of two reals
   having the type of the parameter. --
c12:variable name=complex_type_function 
type=type_from_type_function_type public_interface=yes/

!-- The following variables are used locally for bvars and the like 
only... --
c12:variable name=base_type type=type /

m:math
  m:apply id=type_from_type_function_eqnm:eq/
m:citype_from_type_function/m:ci
m:applyc12:function_type /
  m:citype/m:ci
  m:citype/m:ci
/m:apply
  /m:apply

  !-- We might want to build this into CellML 1.2 core (with the option
   that secondary specification don't support it) but if not, this is
   how complex numbers in their cartesian form could be defined. We
   probably should 
--
  m:apply id=cartesian_complex_type_function_eqnm:eq/
m:cicomplex_type_function/m:ci
m:lambda
  m:bvarm:cibase_type/m:ci/m:bvar
/m:lambda
m:applyc12:vector_type /
  !-- First argument: type of vector elements... --
  m:cibase_type/m:ci
  !-- Second argument: size of vector --
  m:cn c12:type=real_dimensionless2/m:cn
/m:apply
  /m:apply
/m:math
  /c11:component
/c11:model
c11:model xmlns:c11=http://www.cellml.org/cellml/1.1#; 
xmlns:c12=http://www.cellml.org/cellml/1.2#; 
xmlns:m=http://www.w3.org/1998/Math/MathML; 
xmlns:xlink=http://www.w3.org/1999/xlink;
  c11:component name=ComplexUtilities
!-- Connect up to the type you want this component to work with. --
c12:variable name=base_type type=type public_interface=yes/

!-- The complex_type (can be computed from base_type). --
c12:variable name=complex_type type=type public_interface=yes /
c12:variable name=complex_to_base_function_type type=type 
public_interface=yes /

!-- A function for fetching cartesian X co-ordinates. --
c12:variable name=complex_get_cartesian_x 
type=complex_to_base_function_type public_interface=yes /

c12:variable 

[cellml-discussion] Prototype SBML to CellML converter

2009-01-14 Thread Andrew Miller

Hi all,

I have recently coded up a prototype designed to demonstrate how a 
program to convert from SBML to CellML might work. This prototype is 
written in Ruby using the REXML XPath parser, which was rapid to develop 
but makes it very slow to run - the intention is that once the 
algorithms to used are worked out, it could be re-written in a more 
efficient language.


The code has been pushed onto github - the project page is at 
http://github.com/A1kmm/sbml2cellml/tree/master


Features supported at present:
 * SBML parameters, compartments, species, rules, and reactions are 
translated into the equivalent component, variable and math elements in 
CellML (the reaction element in CellML is not used because this is 
considered informally deprecated).
 * Functions are substituted and expanded in the code invoking the 
function, since CellML doesn't allow them at present.
 * Units on constants (MathML cn elements) are automatically inferred 
from the context, where possible.
 * I have attempted to support all of SBML except events, time delays 
and other features which don't have a parallel in CellML yet.
 * The csymbol for time is replaced with a new variable introduced for 
time.


Feedback and comments on this code would be greatly appreciated.

Best wishes,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] installation of CellML DOM API: Core implementation for all platforms

2008-10-07 Thread Andrew Miller

song zhen wrote:

Hi Alan,
I have read those documentations, but I am not familiar with this kind 
stuff, and the problem is that I don't really know what kind of the 
Linux systems I am using. Here is the information for my iMac: Mac OS 
X Version 10.4.11 (Tiger),  Fink installed. Could you tell me which 
documentation in the website you attached is useful for me?


And another question is that is CellML DOM API  enough to open and use 
the model file that I downloaded from CellML? Thanks!!

Hi Song,

The CellML DOM API is a programmatic interface, and is the thing to use 
if you want to write a program for processing CellML models. If you are 
looking for a program with a graphical user interface which can be used 
to edit CellML models and run simulations etc..., try PCEnv, which makes 
use of the CellML API but exposes it through a user interface.


Although PCEnv builds on Mac OS X, there are a number of usability 
issues at present, so I would recommend downloading a Linux snapshot and 
running the Linux version in a virtual machine. We are looking to 
improve OS X support in future.


Best wishes,
Andrew



Best,

Song

On Mon, Oct 6, 2008 at 4:17 PM, Alan Garny [EMAIL PROTECTED] 
mailto:[EMAIL PROTECTED] wrote:


Dear Song,

 


Did you have a look at the installation documentation?
https://svn.physiomeproject.org/svn/physiome/CellML_DOM_API/trunk/docs/

 


Hopefully, you use one of the Linux systems for which we have some
documentation.

 


Regards, Alan

 


*From:* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]] *On Behalf Of *song
zhen
*Sent:* 06 October 2008 20:58
*To:* cellml-discussion@cellml.org
mailto:cellml-discussion@cellml.org
*Subject:* [cellml-discussion] installation of CellML DOM API:
Core implementation for all platforms

 


Hi,
I have a trouble in installation of this source file. when I ran
./configure command in x11, there was an error message stating
that configure: error: GSL CBLAS library required. And actually,
I have updated fink and also installed the gsl package already.
What else should I do to fix this error?

Thanks in advance!

Song


___
cellml-discussion mailing list
cellml-discussion@cellml.org mailto: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
  


___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Finalising CellML Metadata 1.0 specification

2008-09-30 Thread Andrew Miller

Dear all,

I would like to draw your attention to tracker item 1405, which can be 
viewed at https://tracker.physiomeproject.org/show_bug.cgi?id=1405 . 
This tracker item proposes that a decision on finalising the CellML 
Metadata Specification be made on the 15th of October 2008. Please add 
any comments you may have on this on the tracker item (users without an 
account at the tracker already can create one), and add yourself to the 
CC list for the tracker item if you are interesting in receiving updates 
when others add comments.


From the tracker item:

The current draft of the CellML Metadata 1.0 specification has never been

finalised, but has been widely cited and adopted. The specification requires
work, but due to the number of people citing and adopting the draft, it would
make sense to finalise it as it is now, and then start work on the next value
of the specification to address these problems.

I propose that a decision on whether to finalise the specification be made on
the 18th of October 2008, by the group established for making such
specification decisions, based on community discussions prior to then.



Best regards,
Andrew
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] A typed lambda calculus system for CellML

2008-08-05 Thread Andrew Miller
Alan Garny wrote:
 Hi Andrew,

   
 I have been looking into how we could define a typed lambda calculus
 system in CellML, and have written up a document to collect ideas on this:
 http://www.cellml.org/Members/miller/outline-of-a-typed-lambda-calculus-
 system
 

 This is a good starting point, well done!

   
 Of particular interest is ideas about how this could be applied, and of
 anything that we could potentially be missing (for example, whether this
 is sufficient to support stochastic simulations with the addition of a
 few operators, or if it needs more fundamental changes to allow for
 that. This is something I am still looking into and would welcome ideas
 
 on).

 Regarding stochastic models and based on your current document, I am
 wondering whether it wouldn't be worth having/gathering (snippets of) models
 that would ideally be described in a typed CellML format?

 I don't know anything about stochastic modelling, but if we were to have
 such (snippets of) models, it might help us determining what is required to
 get a typed lambda calculus system [(TLCS)] could work in CellML.

 Anyway, back to your document (please keep in mind that I haven't really
 thought about TLCS):

 Variables as types:
 ---
 - Do we really want to allow generic types? I am concerned that this could
 lead to models that are not bullet-proof.
   
The core of CellML can be very generic, and then secondary 
specifications can narrow down CellML to a subset of CellML which can be 
implemented by a particular tool. Models would then be coded up in 
accordance with a secondary specification.

One secondary specification would likely only allow real numbers, and 
other parts of the secondary specification might also allow the use of, 
say, vectors of real numbers. But the core specification has to be more 
general so that more secondary specifications can be defined.

 - In order to provide built-in types, there will need to be built-in
 variables. I think I understand the concept of built-in types, but I am
 not sure what you mean by built-in variables. Could you please provide us
 with some concrete examples of those?
   
Remember that the core statement of how the TLCS works is that CellML 
variables are defined inside components to hold types. In other words, 
types are stored in variables. If we want to have built-in types, we 
need to have variables to store them in, hence built-in variables. I 
think that perhaps I need to emphasise the idea of variables holding 
types more somehow.

real_metre is an example of a built-in variable, which is given in the 
same paragraph.

 - It would be valid to connect a built-in type using the name of one
 component to another variable. I must confess that this doesn't really make
 sense to me. I think it would help if you were to give some concrete example
 (the example you give in your document is still somewhat abstract).
   
I could add in something like:
  Component A:
 Variable name=T type=type
 * Some more variables of type T *
 Maths in terms of variables of type T

  Component B:
 Empty

  Connection
Between Component A and Component B
Connect Component A.T to Component B.real_metre

This would cause all the variables in Component A to be in terms of 
real_metre. This is valid.

 - However, it would be invalid to connect two built-in variables to each
 other. I guess I will understand that statement once I know exactly what a
 built-in variable 'looks like'.
   
For example, the following would be invalid...
Component A:
  Empty

Component B:
  Empty

Connection
   Between Component A and Component B
   Connect Component A.real_metre to Component B.real_second

Here, real_metre and real_second are both built-in variables.

 - You mention real_metre as an example of a built-in variable. For some
 reason, I would have thought of real_metre as being an example of built-in
 type...
Because all types are stored in variables. So real_metre is a built-in 
variable of type type.
  Why would all components have a built-in variable called
 real_metre?
Because real_metre is 'superglobal' meaning that it is automatically 
present in all components, saving the need to connect it up and 
simplifying the common case.

  What used would such a variable have?
So that type=real_metre can be used on a variable... in which case, 
the variable real_metre would be searched for, and since it is present 
in every component, found. This is explained in the third paragraph of 
variables as types.

  On the other hand, I
 could see the need for such a type to be available everywhere. I have the
 feeling that this might be a matter of terminology?
 - Variables as types: Variables holding a type have type type, where type
 is a built-in variable which itself has type type. Could this be
 rephrased?!
   
I don't think we can avoid using the word type so many times, and IMHO 
it would be even more confusing to mix different words meaning type. 
Dealing 

Re: [cellml-discussion] A typed lambda calculus system for CellML

2008-07-31 Thread Andrew Miller
Randall Owen wrote:
 Andrew:

 This seems like a very good idea. How much work has actually been done in 
 this area?
   
Hi Randy,

I presume you are only asking about work in relation to CellML? The 
document I linked is pretty much it in terms of actual written up 
documents... once we allow more time for feedback we can actually start 
drafting specifications on this.

If we are not restricting this discussion to CellML, then it is worth 
noting that typed lambda calculus based systems have been a fairly 
popular area of study, and there are theorem proving environments based 
on similar ideas (Coq is a good example of such an environment). I 
expect that most CellML tools will not want to be as general as this... 
to start with, they will probably only support the TLCS equivalents of 
what can be done with CellML 1.1. The way we can allow this without 
hurting interoperability is to define 'secondary specifications' which 
further limit CellML for a class of tools.

It is also worth noting that OpenMath also has a document on a type 
system based on similar ideas.

Best regards,
Andrew

 Best regards,
 Randy Owen
 Software Engineering Group
 Oxford

 In message [EMAIL PROTECTED] CellML Discussion List 
 cellml-discussion@cellml.org writes:
   
 Hi all,

 I have been looking into how we could define a typed lambda calculus 
 system in CellML, and have written up a document to collect ideas on this:
 http://www.cellml.org/Members/miller/outline-of-a-typed-lambda-calculus-system

 This document does not yet aim to be a formal specification, but 
 instead, aims to outline all the ideas that we could use as a basis for 
 writing up the relevant parts of the formal specification.

 Please feel free to discuss this and / or suggest improvements. I have 
 enabled commenting on the document in Plone for people with an account, 
 and this mailing list would also be a suitable place for discussion of 
 the document to take place.

 Of particular interest is ideas about how this could be applied, and of 
 anything that we could potentially be missing (for example, whether this 
 is sufficient to support stochastic simulations with the addition of a 
 few operators, or if it needs more fundamental changes to allow for 
 that. This is something I am still looking into and would welcome ideas on).

 Best regards,
 Andrew
 ___
 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
   

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] A typed lambda calculus system for CellML

2008-07-23 Thread Andrew Miller
Hi all,

I have been looking into how we could define a typed lambda calculus 
system in CellML, and have written up a document to collect ideas on this:
http://www.cellml.org/Members/miller/outline-of-a-typed-lambda-calculus-system

This document does not yet aim to be a formal specification, but 
instead, aims to outline all the ideas that we could use as a basis for 
writing up the relevant parts of the formal specification.

Please feel free to discuss this and / or suggest improvements. I have 
enabled commenting on the document in Plone for people with an account, 
and this mailing list would also be a suitable place for discussion of 
the document to take place.

Of particular interest is ideas about how this could be applied, and of 
anything that we could potentially be missing (for example, whether this 
is sufficient to support stochastic simulations with the addition of a 
few operators, or if it needs more fundamental changes to allow for 
that. This is something I am still looking into and would welcome ideas on).

Best regards,
Andrew
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] CellML DOM API 1.4, CORBA and Java help

2008-06-18 Thread Andrew Miller
Randall Britten wrote:
 Hi

 While I think that the approach you are taking to use the CellML api via
 CORBA is probably your best option at the moment, there is one other option
 to consider.  There is a CellML-API that was developed in Java some years
 ago.  Sarala uses this for her work.  While it is not actively maintained,
 it may be worth looking at, and so should be mentioned.  I don't know of any
 locations on the web where it is available, but one or two people have
 copies of it on their systems.
   

Hi,

Please note that I have created a tracker item for the question at 
https://tracker.physiomeproject.org/show_bug.cgi?id=1119 and answered 
some of the questions there. If you are interested in following this 
issue, you will be able to create an account on the tracker and add 
yourself to the CC list, so you will receive mail every time a comment 
is added to the tracker item.

Best regards,
Andrew

 Does anyone else have some info on the old Java-CellML api?

 Also note that we do recognise the importance of making the CellML api
 accessible from Java, please see
 https://tracker.physiomeproject.org/show_bug.cgi?id=306, and we will try and
 help you with this.

 Regards,
 Randall

   
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:cellml-discussion-
 [EMAIL PROTECTED] On Behalf Of Morgan Taschuk
 Sent: Thursday, 19 June 2008 3:47 a.m.
 To: CellML Discussion List
 Subject: [cellml-discussion] CellML DOM API 1.4, CORBA and Java help

 Hello!

 Having failed using the CellML 1.1 spec to generate Java bindings, I'm
 trying to install the CellML DOM API 1.4 on Kubuntu Gutsty 7.10 and
 bind it to Java with CORBA. I'm having (several) problems.

 1) I can't start the CORBA server. I've found the appropriate files, I
 think, under CellML_DOM_API_1_4/sources/cellml_corba_server, but I
 can't actually get the server to start. There appears to be a fragment
 of a make file in that dir, but I don't know where the super make file
 is located. A general make on the project doesn't touch that
 directory.

 A side thought: there are scripts to start the server in
 CellML_DOM_API_1_4/scripts/, but they're hard-coded to
 CELLML_BIN_DIR=/people/amil082/code/CellML_DOM_API. The commented out
 section #CELLML_BIN_DIR=/usr/sbin points to an empty directory for me.

 2) Related to 1), I found the Physiome tracker item #254
 (https://tracker.physiomeproject.org/show_bug.cgi?id=254) and saw that
 the configure script is fairly new, so I did a 'make clean' and 'make
 distclean' on the project and tried running 'aclocal  autoconf 
 automake'. That didn't work, so I tried cleaning again, and re-running
 configure. Now make doesn't work! Output:

 CellML_DOM_API_1_4$ make

 make  all-recursive
 make[1]: Entering directory `/home/mtaschuk/Desktop/CellML_DOM_API_1_4'
 Making all in gsl
 make[2]: Entering directory
 `/home/mtaschuk/Desktop/CellML_DOM_API_1_4/gsl'
 Makefile:314: warning: overriding commands for target `distclean'
 Makefile:250: warning: ignoring old commands for target `distclean'
 rm -f gsl*.h
 HEADERLIST=../gsl*.h ../*/gsl*.h; \
 for h in $HEADERLIST; do \
   BASENAME=`basename $h`; \
   test -r $BASENAME || ln -s $h $BASENAME; \
 done
 make[2]: Leaving directory
 `/home/mtaschuk/Desktop/CellML_DOM_API_1_4/gsl'
 Making all in utils
 make[2]: Entering directory
 `/home/mtaschuk/Desktop/CellML_DOM_API_1_4/utils'
 /bin/bash ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I..
   -g -O2 -c -o placeholder.lo `test -f 'placeholder.c' || echo
 './'`placeholder.c
 ../libtool: line 1314: func_opt_split: command not found
 libtool: Version mismatch error.  This is libtool 2.2, but the
 libtool: definition of this LT_INIT comes from libtool 2.1a.
 libtool: You should recreate aclocal.m4 with macros from libtool 2.2
 libtool: and run autoconf again.
 make[2]: *** [placeholder.lo] Error 63
 make[2]: Leaving directory
 `/home/mtaschuk/Desktop/CellML_DOM_API_1_4/utils'
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory `/home/mtaschuk/Desktop/CellML_DOM_API_1_4'
 make: *** [all] Error 2

 3) I used idlj to generate the Java binding. That worked, but now I
 have about 400 interfaces in CellML_DOM_API_1_4/interfaces/cellml-api
 and NO idea where to start.

 Help?

 Regards,
 Morgan


 On Wed, Jun 18, 2008 at 6:03 AM, Justin Marsh [EMAIL PROTECTED]
 wrote:
 
 Hi all,

 The CellML DOM API 1.4 has now been released at
 http://www.cellml.org/downloads/cellml_api/releases/1.4

 Should you find any bugs in this release, or have feature
 requests, please report it to our bugtracker at
 https://tracker.physiomeproject.org, or alternatively email
 me at [EMAIL PROTECTED]

 Best Regards,
 Justin Marsh.
 ___
 cellml-discussion mailing list
 cellml-discussion@cellml.org
 http://www.cellml.org/mailman/listinfo/cellml-discussion

   
 ___
 cellml-discussion mailing list
 

Re: [cellml-discussion] unit conversion

2008-06-02 Thread Andrew Miller
Mike Cooling wrote:
 Could we perhaps consider built-in scaling factors for CellML 1.2?

 That way could still support the SI units but just that one of them (mole)
 is as a scaling factor which is what it is as far as I can see.
   
Units already allow words like micro, milli and so on to be specified on 
them to specified as the prefix, and other scaling factors can be 
attached to units using multiplier.

Although you can technically talk about a mole of anything, the way it 
is used by the SI system of units, it is always talking about a mole of 
some kind of particle, whether that particle is an electron or some 
large protein. As such, mole, when used in this sense, truly is a unit 
as the term is used in CellML, rather than just a scaling factor (and in 
fact, it would make sense to define a 'particle' derived unit in terms 
of mole using a multiplier of the inverse of Avogadro's number).

 We might also include built-in scaling factors for converting between
 prefixes. For example if I have
 a variable A in nanomolar and another B in micromolar I might want to say:

 A = 1e3 * B

 One way to do this is to define a scaling factor unit say (in CORspeak)

def unit nanospermicro from
unit liter {pref: nano};
unit liter {pref: micro, expo:-1};
enddef;

 and then have

 A = 1e3 {nanospermicro} * B.

 Which is slightly clunky.
   

This is a perfectly valid way of expressing the model, and if necessary, 
editing tools could help the user to create such units as required - we 
shouldn't complicate the specification substantially for processing 
tools based on what might make it easier to do something with current 
editing tools, because editing tools will have to change for CellML 1.2 
anyway.

 (I think the use of 'liter' above should also be replaced with
 'dimensionless', but that is a different issue).
   
It doesn't really make sense to say nanodimensionless per 
microdimensionless, I prefer nanolitres per microlitre even though you 
need to duplicate it if you have other conversion factors.
 We could also include dozen, which would aid the bakery-modelling community
 too ;).
   

If we are talking about dozens of particles, that can already be done in 
terms of moles easily using multiplier 12 / nA (i.e. 1.99264653979527 * 
10^-23)

Best regards,
Andrew



 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of Peter Hunter
 Sent: Tuesday, 3 June 2008 11:35 a.m.
 To: CellML Discussion List
 Subject: Re: [cellml-discussion] unit conversion

 Hi Mike,

 I agree - but there they are in the SI base unit list see
 http://physics.nist.gov/cuu/Units/units.html
 so probably 150 years too late to do much about it!

 Cheers,
 Peter

 Mike Cooling wrote:
   
 Does it strike anyone else as inconsistent that 'moles' are a unit 
 when moles are just a scaling factor? Like dozen. Maybe they should be 
 implemented using 'multiplier' or similar rather than a base unit.

 For example, I could have a mole of amps. I couldn't have a second of
 
 amps.
   

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of James 
 Lawson
 Sent: Tuesday, 3 June 2008 11:07 a.m.
 To: Erik B
 Cc: cellml-discussion@cellml.org
 Subject: Re: [cellml-discussion] unit conversion

 Thanks Erik,

 I managed to fix the issue before receiving your email, but this 
 clears things up for me very concisely. I would venture to say that 
 the reason that so many CellML models in the CellML repository do not 
 pass Jsim's units checking is not because of CellML, or any tools used 
 to create CellML models. Rather it is often because the models 
 themselves contain unit inconsistencies. It does not help that units 
 are irrelevant to most modelling tools, but I think the modelling 
 community is starting to raise the bar with regards to this issue. 
 Unfortunately it is often quite difficult to 'fix' inappropriate units 
 (both quantitatively and
 qualitatively,) in a model without breaking it.

 FYI I've uploaded the model in question, which now runs in Jsim, COR 
 and PCEnv, at:
 http://www.cellml.org/models/sachse_moreno_abildskov_2008_version02

 The 'auto' setting for the integrator in Jsim will not run the model - 
 the CVode integrator must be selected manually.

 Kind regards,
 James Lawson

 Erik Butterworth wrote:
 
 On Thu, 29 May 2008, Andrew Miller wrote:

   
 I think James had something more along the lines of:
 I_inter_fibro = 10^6 * (V_fibro - V) / R_mf (where 10^6 is marked as 
 a dimensionless number).

 In this case the intention of the modeller is that the expression 
 being equated to I_inter_fibro is already in nanoamps, and this will 
 give the correct results in PCEnv and COR, I believe.

 I agree that it would be better modelling practice to mark 10^6 as 
 being in units nanoamps per milliamps, and in this case PCEnv and 
 COR will give correct results of 1E6 nanoamperes (and I presume also
 
 JSim

Re: [cellml-discussion] [Fwd: Re: CellML model of Electrophysiological Modeling of Fibroblasts and their Interaction with Myocytes]

2008-05-28 Thread Andrew Miller
James Lawson wrote:
 Hi Andrew,

 I have to confess I really didn't understand Erik Butterworth's email. 
 However this is a forward of a reply I just got from Frank Sachse, the 
 original model author.

 I think he has a point - it seems that Jsim does do the dimensional 
 conversion but PCEnv appears not to. What do you think?
Hi James,

Changing the mathematical equation by inserting new units to be 
something other than what the user specified is not a good idea - it 
means that the software is overriding what the modeller specified 
automatically. At most the software should alert the user / modeller to 
a possible units problem.

CellML requires unit conversions at the connections - so for example, it 
is possible to connect something in milliamps to something in nanoamps, 
and then the conversion is performed - this is so components from 
different groups can be seamlessly connected up, while we expect that 
authors can (possibly with the help of tools) ensure that the 
mathematics inside components are consistent with the units variables on 
units in the component.

This is also the behaviour specified in CellML 1.0 and 1.1 (which is a 
bit unclear, unfortunately, but I have made it entirely clear in my 
CellML 1.2 drafts).

This has been discussed a few times in the past. See for example 
http://www.cellml.org/pipermail/cellml-discussion/2007-April/000570.html

Best regards,
Andrew


 Just to elucidate his last comment, he mentions that my simulation 
 problems might be because of the conversion factor, but I have 
 problems simulating his original version too.

 Cheers,
 James

 

 Subject:
 Re: CellML model of Electrophysiological Modeling of Fibroblasts and 
 their Interaction with Myocytes
 From:
 Frank B. Sachse [EMAIL PROTECTED]
 Date:
 Wed, 28 May 2008 18:38:25 -0600
 To:
 James Lawson [EMAIL PROTECTED]

 To:
 James Lawson [EMAIL PROTECTED]


 Dear James,

 Yes, your figure looks correct for high coupling and a small number of
 coupled fibroblasts.

 I agree that your conversion for I_inter_fibro is value wise correct, but
 assumed that CellML automatically handles the conversion because it has
 knowledge of the units. Why doesn't CellML convert the unit in this case?

 I never ran in the mentioned problems with the JSim simulation environment,
 which is probably caused by overflow using the 1e6 too large current
 (assuming that it handles the units correct). My JSim contact was Dr.
 Carlson ([EMAIL PROTECTED]). He created the webpage for our model.
 He might be able to explain the differences in the unit handling and point
 at potential causes for the errors. However, I would at first look into the
 unit handling in CellML. Another thing to test: Do the myocyte/fibroblast
 current traces look reasonable?

 Best regards,
 Frank

 On 5/28/08 5:46 PM, James Lawson [EMAIL PROTECTED] wrote:

   
 Dear Frank,

 Thanks for your help, I have the model working in PCEnv now. I've
 attached a screenshot of the behaviour of the model with 1 fibroblast.
 Adding extra fibroblasts produces the correct behaviour as well.

 The problem was that I had to multiply the I_inter current by a scaling
 factor of 1 million. This has something to do with the differences
 between the way PCEnv and Jsim handle units, but I am not sure of the
 details here.

 Basically the issue that I have addressed is that units for the
 variables in the equation for I_inter_fibro aren't dimensionally equivalent:

 The equation is: I_inter_fibro =(V_fibro - V) / R_mf

 Where I_inter_fibro is in nanoamperes, V_fibro and V are in millivolts
 and R_mf is in ohms. So the equation says that nanoamps = millivolts /
 ohms. Thus I have changed the equation to say I_inter_fibro = 1e+06 *
 (V_fibro - V) / R_mf

 So at the moment I do not know how to get the model to run in both PCEnv
 and Jsim. What I'll do for now is upload a variant of the model to the
 repository with different curation notes, but ideally I should be able
 to get one model that runs in both environments.

 I've been trying to run your original version of the model in Jsim but I
 keep getting solver errors saying 'aborted: NaNs detected during
 evaluation' or 'aborted: Expression time Attempt to set domain grid ct  2

 If you could give me any tips at all here I would really appreciate it.

 Thanks very much.

 Kind regards,
 James Lawson

 Frank B. Sachse wrote:
 
 Dear James,

 I agree, Fig 7 would be best to illustrate myocyte-fibroblast interactions.
 It shows that fibroblasts follow closely the myocyte transmembrane voltage
 and that fibroblast coupling modulates strongly this voltage.

 We tested the CellML cell pair model by importing it in JSim and
 reconstructing this figure:
 http://www.physiome.org/model/doku.php?id=Cell_Physiology:Action_potential:M
 yocyte_fibroblast_coupling:model_index
 This java applet might be a help to check your results.

 Regarding the stimulus protocol: Current 

[cellml-discussion] Representing stochastic models in CellML

2008-04-22 Thread Andrew Miller
Hi all,

I have spent some time looking into how we might be able to represent 
stochastic models in CellML. This is something that would be useful to 
ensure we have properly contemplated for CellML 1.2. I have pasted in 
the notes I wrote on this below.

Please let me know if you have any suggestions, comments, or criticisms 
of the below document. At some point, this will obviously need to be 
transformed into a more robust proposal, but for now, I just want to 
make sure we keep the option open to use the CellML 1.2 core to 
represent stochastic models.

Best regards,
Andrew

-

Overall goal:
  Describe a framework which can be used in CellML 1.2 to represent a 
range of
  different systems which require stochastic differential equations to
  describe.

Constraints:
  Do not want to describe the procedure for solving the model in core 
CellML,
only the underlying mathematical / statistical model.
  Want to express the model in such a way that the procedure is computable
from the model.
  Want there to be only one interpretation of the model.
  Want the representation to be abstract enough that it is meaningful for a
number of different fields, and not just chemical equations in a well
stirred vessel.
  Want the representation to work naturally when mixed with systems of 
ordinary
differential equations.

Use cases:
  Chemical reactions under the Chemical Master Equation model of Gillespie:
We need to split these into separate species. This is a Poisson process,
so there are simple ways to represent it.

It is more efficient to represent models using Weiner processes when 
this
there are large enough numbers of molecules to justify this but ODEs are
not being used.

However, Poisson and Weiner processes are both Levy Processes, that is,
they have stationary independent increments, are zero at time zero, and
are cadlag. This is not necessarily a good thing because some things we
want to model might have memory of past events or a time dependence.

How we can represent this in CellML:
  For the continuous case, integral equations for the increment in terms of
  built in processes like Weiner and Poisson processes (I don't believe 
there
  is a clean way to represent increments in MathML).

  Implementations will need to identify these and work out the 
distribution of
  the time until the next event (good implementations might be able to 
perform
  symbolic algebra to work this out, but most implementations would probably
  just recognise common cases like Poisson distributions with arbitrary
  parameters, and deal with expressions involving a Weiner process by 
sampling
  from the increment distribution in each time step), which could be put 
into a
  slightly generalised Gibson-Bruck type of framework where we store the 
time of
  the next event.

  None of this helps for non stationary independent processes, however.

How could this be related to the standards:
  It has been proposed that CellML 1.2 have a core specification which 
describes
  the basic way of representing the mathematical structure in very general
  terms, and secondary specifications be used to narrow CellML down to 
specific
  subsets which can be implemented in their entirety by a actual software
  packages.

  Core CellML 1.2 should be general enough to represent concepts like
  probability distributions (MathML allows new operators to be defined, 
so we
  could create ones for our base types of stochastic process). The ODE IV
  secondary specification would not allow stochastic models, while we would
  have another alternative secondary specification which extended the ODE IV
  one to allow certain limited types of stochastic model (limited to 
types we
  know how to solve).

  In terms of interaction with the typing system, in a stochastic system we
  have both reals and real-valued random variables. Once we have one random
  variable in our system, this will propagate to everything else which
  is affected by it, so most of the model will technically be a random 
variable.
  However, we want to be able to easily mix stochastic models with 
existing ODE
  IV models to create hybrid models, so we don't really want the required
  datatype to change just to connect up a random variable to a non-random
  variable. For this reason, I don't think it is worthwhile to consider a
  random variable of a certain type a different datatype, and instead we 
would
  require tools to deduce this information if they require it.

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Identifying smaller subsystems of simultaneous equations in differential-algebraic models

2008-04-21 Thread Andrew Miller
Randall Britten wrote:
 However, in general, I haven't been able to find an efficient
 (polynomial time) algorithm to compute this break-down (but I also
 haven't yet proved that the problem is NP-complete, so there may be a
 polynomial time solution even if P != NP).

 Hi Andrew
 
 If possible, please outline the algorithm that you have found, even though
 it is not efficient.

The most trivial algorithm is of course a simple depth first exhaustive
search. I believe this is what Justin already started implementing.

Firstly, I'll define the exact problem that I'm trying to solve in
formal language.


There are several ways to formulate the problem, but matrix notation
seems the cleanest.

Let A be an n*n matrix, where n is the number of equations in the model
(which haven't already been used), and is also the number of unknown
variables (which must be equal for the problem to be correctly constrained).

Let A_ij = 1 if the ith equation involves the jth unknown, and 0 otherwise.

The objective is to find the smallest possible non-empty set E such that
|E| = |V|, where V = {j where exists i in E such that A_ij = 1 }
===

Algorithm findSmallestSystem(A, n):
  for setSize from 1 through to n inclusive:
result - findSystemOfSize(A, n, setSize, {}, 1)
if result is not failure:
  return result
end
  end
  Not reached because there is always a system of size n.
end

Algorithm findSystemOfSize(A, n, addMembers, existingMembers,
lowestConsidered):
  if (addMembers != 0):
result - findSystemOfSize(A, n, addMembers - 1, existingMembers \
{i}, lowestConsidered + 1)
if result is not failure:
  return result
end
result - findSystemOfSize(A, n, addMembers, existingMembers,
lowestConsidered + 1)
if result is not failure:
  return result
end
return failure because this branch is impossible.
  end

  V - {}
  for j from 1 through to n inclusive:
for i from 1 through to n inclusive:
  if A_ij = 1:
V - V union {j}
next iteration of the outer loop
  end
end
  end

  if |V| = |existingMembers|:
return existingMembers
  else
return failure
  end
end

I am measuring the time complexity of this by the number of times we
check if A_ij = 1. In the worst case, which is that the only possible
system is the system of size n, we fail for systems of size 1 through to
n-1, and run to the end of the nth step before failing. This takes  n^2
* (choose(n, 1) + choose(n, 2) + ... + choose(n, n)) = n^2 * (2^n - 1)
steps.

We can optimise certain cases. For example, if we can isolate disjoint
sets of variables and equations using a disjoint sets algorithm, we can
do better on this case (this won't improve the worst case, because there
is no guarantee of this being possible).

We can also adapt the above algorithm to be branch-and-bound by noting
that even before we get to the end of a branch, if |V|  |E|, then it is
never going to shrink as a result of adding more equations so we can
close off that branch.

Another possibility might be to implement a beam search based on some
kind of graph connectivity heuristic. However, it is not clear if this
would actually improve real world problems.

Also, it is worth noting that the above algorithm builds up the equation
set. We can also attack the problem from the other end (i.e. a divisive
algorithm) by starting from the set of all equations, which means we
know that |V| = |E|, and removing single equations or pairs of equations
and so on from |E| to see if this causes |V| to shrink by the
corresponding amount.

What I suspect will be the best improvement for average world models
would combine the disjoint sets separator with alternating between
divisive (shrink until we fail) and build-up (grow until we succeed)
algorithm attempts. This might work for real world problems if we limit
the number of equations we try to add or remove before just returning
the best divisive algorithm result even though it may be suboptimal.
However, whether this is actually useful is something we would need to
try with a number of models to find out; we may find that we still need
the metadata as a fallback approach for models where the heuristic is
not useful.

Best regards,
Andrew

 
 Regards,
 Randall
 
 ___
 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


[cellml-discussion] Identifying smaller subsystems of simultaneous equations in differential-algebraic models

2008-04-15 Thread Andrew Miller
Hi all,

One issue which has recently been discussed amongst those of us working 
on CellML tools is the best way to handle models which require systems 
of equations to be solved efficiently. For example, if a model has 
equations like:

f1(a, b, c) = 0
f2(a, b, c) = 0
f3(a, c) = 0
f4(b, c, d, e) = 0
f5(b, d) = 0

We could simply solve the entire system in one go in a non-linear 
solver, over all five variables. However, this is not an efficient 
approach generally; we could have thousands of variables in a complex 
model, but only have one place in which we need to solve a system of two 
models. In this case, we could break the solution down to the following 
procedural steps:
Step 1) Solve the following system:
f1(a, b, c) = 0
f2(a, b, c) = 0
f3(a, c) = 0

to get a, b, and c.

Step 2) Solve the following equation:
f4(b, d) = 0
using the value of b obtained in the above step, to get d.

Step 3) Solve the following equation:
f4(b, c, d, e) = 0
using the known values of b, c, and d, to get e.

However, in general, I haven't been able to find an efficient 
(polynomial time) algorithm to compute this break-down (but I also 
haven't yet proved that the problem is NP-complete, so there may be a 
polynomial time solution even if P != NP).

We have several other approaches available to us, even if finding the 
exactly optimal break-down into systems is intractable:
  1) Use a heuristic algorithm which cannot always break down the 
system, but can for simple cases. For example, we could limit the size 
of systems allowed to control the complexity, or we could try some 
divisive algorithm which starts with the system which requires that all 
variables be solved, and tries to isolate individual equations or pairs 
or triples from it to see if this eliminates the need to solve for any 
variables, or perhaps tries both heuristics. We can also efficiently 
identify completely disconnected systems which don't share any common 
variables and solve them individually using a disjoint sets datatype.
  2) Require the model creator to provide us with this information. This 
is perhaps an unclean approach because certain kinds of changes to the 
model may change the types of systems that need to be solved. However, I 
understand it is essentially the status quo for most non-CellML 
modelling work which requires systems of equations to be expressed, so 
might still be a good last resort if we don't find a better solution (or 
even useful as a override for cases where the heuristic algorithm fails 
to find the optimal procedural steps).

I would be very grateful if anyone has feedback or suggestions on how to 
handle this issue.

Best regards,
Andrew
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Specifying the variable(s) of integration / independent variable(s) in MIASE

2008-03-11 Thread Andrew Miller
Dear all,

Based off the UML diagram at 
http://miase.cvs.sourceforge.net/*checkout*/miase/miaseOM/miaseOM/miaseOM.pdf?revision=1.5
 
, I notice that the UniformTimeCourse UML class makes the assumption 
that the model is being evaluated across a time variable (in other 
words, that time is special in some sense).

I understand that one of the goals of MIASE is for it to be format 
independent. However, I believe that the assumption that time is special 
harms the applicability to languages such as CellML (which aim to 
represent models in a domain-independent form, which means that concepts 
like time are not built into the standard, but rather, are defined as 
part of the model).

As has been pointed out on an earlier thread on the MIAME mailing list, 
https://sourceforge.net/mailarchive/forum.php?thread_name=18374.18884.225456.303727%40mellow.localforum_name=miase-discuss
 
, I have previously defined a short draft specification designed to 
represent similar information (although I agree entirely with the idea 
of replacing this with a better specification common to multiple 
modelling languages).

The CellML Simulation Metadata focuses on the equivalent of the 
UniformTimeCourse simulation. However, these simulations are composed of 
one or more objects, which each associate with a variable in the CellML 
model and the range of the variable over the simulation (in the common 
case where time is the independent variable, there is one such object, 
which references time, and the initialStartTime and initialEndTime 
attributes on UniformTimeCourse simulation correspond to similar slots 
on the object in CSM).

It looks like a structure similar to that used in CellML Simulation 
metadata would make sense in MIASE too. This structure would have the 
additional benefit of providing some of the simulation information 
necessary for PDE simulations.

Best regards,
Andrew
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Proposed CellML 1.2 change: removing group and replacing it with an encapsulation element

2008-03-04 Thread Andrew Miller
Hi all,

As has been previously discussed on this mailing list, grouping in the 
general sense can be used to represent information such as containment 
which would more appropriately be treated as metadata and represented in 
RDF/XML. The overall process of moving this information out into 
metadata is discussed in tracker item 316 
(https://tracker.physiomeproject.org/show_bug.cgi?id=316).

As a step towards this, I have created a derivative of the connection 
simplification branch in which the group and relationship_ref elements 
are removed from the specification, and replaced with an encapsulation 
element. The encapsulation element still contains a hierarchy of 
component_ref children, as before.

I have pushed this change into my public git repository at 
git://repo.or.cz/srv/git/cellml-draft-miller.git branch 
encapsulation-only. I have also put up a rendered version of this draft 
at 
http://www.cellml.org/Members/miller/draft-normative-spec-encapsulation-only/toplevel.xhtml
 
. I created https://tracker.physiomeproject.org/show_bug.cgi?id=356 for 
discussion on this issue - please add yourself to the CC list for the 
tracker item if you are interested.

Best regards,
Andrew
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Call for community input: final decisions on a number of specification related issues

2008-03-04 Thread Andrew Miller
Hi all,

There are a number of items in the CellML tracker regarding decisions 
about the next version of the CellML specification, which have been 
discussed in the past and around which consensus seems to have been 
reached, but on which we have yet to declare a final decision. By making 
a final decision as a community on a set of questions, further important 
questions about what will be in the specification can be more easily 
discussed (without having to consider the interaction with every 
possible other decision that is still open).

There has recently been some discussion over the best process to make 
decisions on specification related proposals. Although the exact details 
of the process still has to be worked out, there was agreement (at least 
amongst people in Auckland) that we should make decisions by unanimous 
agreement where possible, and only fall back onto some other process 
where this has been shown not to be possible. The process for 
determining such unanimous agreement seems to be to that the issue is 
proposed, discussion on the proposal takes place, and when this 
discussion dies down and there is an apparent consensus, community input 
is sought, and a deadline (sufficiently far in the future) for 
objections is provided. In the event that no objections are raised by 
the expiry of the deadline, the decision has been made. Objections could 
relate to the substance of the proposal, or simply be to request more 
time for the decision to be made.

So that the list of decisions I identified can be made, I have set a 
deadline of one week from now, that is, Wednesday March the 12th, at 
00:00:00 GMT (which is March 12th, 1:00 pm in NZDT). If you feel that 
this is not enough time, please make a note of this on the tracker item, 
including when you think the deadline should be, before the expiry of 
the March 12th deadline, so that the decision won't be made without your 
input.

The list of tracker items with my summary of them follows. If you are 
interested in discussion on these issues, please add yourself to the CC 
list for the individual tracker item concerned (you will need to create 
an account on the tracker if you don't have one already, but this is a 
process which anyone can do).

Tracker item 312 
(https://tracker.physiomeproject.org/show_bug.cgi?id=312) - proposal is 
that in the spec, we call individual CellML 'files' CellML Infosets, and 
we call all the files together 'CellML Models'.
Tracker item 319 
(https://tracker.physiomeproject.org/show_bug.cgi?id=319) - Proposal is 
that names like _1a be treated as valid CellML identifiers (fixes a 
conflict in CellML 1.1)
Tracker item 167 
(https://tracker.physiomeproject.org/show_bug.cgi?id=167) - Proposal is 
that imports create an instance of a model, and so it is invalid to 
import the same component twice in a single import element.
Tracker item 193 
(https://tracker.physiomeproject.org/show_bug.cgi?id=193) - Proposal 
about when we change namespaces on elements and when we keep the 
namespace from the previous version.
Tracker item 331 
(https://tracker.physiomeproject.org/show_bug.cgi?id=331) - Proposal is 
that RDF/XML inside extension elements should only contain extension 
specific metadata.
Tracker item 332 
(https://tracker.physiomeproject.org/show_bug.cgi?id=332) - Proposal is 
that we should allow references to secondary specifications which narrow 
down CellML to a specific type of problem (resolves issues relating to 
the CellML Subset in CellML 1.1 and the fact that the core CellML is too 
general to be fully implemented).
Tracker item 56 (https://tracker.physiomeproject.org/show_bug.cgi?id=56) 
- That we consider the issues arising from the CellML subset resolved 
(conditional on tracker item 332)
Tracker item 84 (https://tracker.physiomeproject.org/show_bug.cgi?id=84) 
- Proposal for a standardised real number format using a decimal point 
(as opposed to a decimal comma or decimal momayez).

I haven't included tracker item 337, about removing directionality from 
connections, because discussion on it seems to have stagnated without 
reaching agreement on the details of the best approach.

Best regards,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] CellML 1.1 to draft CellML 1.2 normative specification mapping

2008-02-20 Thread Andrew Miller
Alan Garny wrote:
 Hi Andrew,

   
 I have now defined a mapping between CellML 1.1 and one draft of CellML
 1.2. I have put this up at:
 http://www.cellml.org/Members/miller/mapping-1-1-to-draft-1.2/mapping

 It currently has all the mappings from 1.1 to a particular 1.2 draft,
 although it may be missing some of the reverse mappings.
 

 I haven't had time to go through everything in detail (i.e. check that
 everything that is in the original CellML 1.1 Specification is also in your
 draft), but as far as I can tell (i.e. as far as I can remember the original
 CellML specification) it all seems fine to me and it will no doubt be very
 useful to anyone interested in CellML (it would certainly have saved me a
 lot of time when working on COR's CellML API!). Anyway, here are some
 comments which I hope will prove useful to you in some way or another (sorry
 in advance for the number of them!):

 - Section 1: you may want to provide a link to RFC 2119
 (http://www.ietf.org/rfc/rfc2119.txt I believe).
   
Good point, I have now drafted a version which I will push to my public 
git shortly which adds RFC2119 as a normative reference.

 - Section 1: shouldn't we have a definition for a CellML 1.0 Namespace? I
 guess you may not have given one because your document is currently about
 CellML 1.1 and will then be targeting CellML 1.2?
   
No, the specification mixes namespaces in accordance with the rules that:
  1) Any element which hasn't changed semantics from CellML 1.1 keeps 
the CellML 1.1 namespace in CellML 1.2.
  2) Any element which changes semantics goes in the CellML 1.2 namespace.

CellML 1.1 already changed the namespace for everything from the 
namespace used in CellML 1.0, so it makes no sense to mix CellML 1.0 
namespaces with CellML 1.1 or 1.2 namespaces. Because we never refer to 
CellML 1.0 namespaces, there is no point in providing a definition for them.

 - Section 1: would it be worth to provide a link where the reader could look
 up the Unicode characters given in some definitions (e.g. the Basic Latin
 alphabet; possible link: http://www.unicode.org/ and in particular
 http://www.unicode.org/charts/)?
   
I don't think this is necessary in a normative specification - I don't 
think providing such a link would serve the goals of a normative 
specification, but this would of course be a good thing for an 
informative specification.

 - Section 2.2.1.d: did you really mean element information element or
 element information item?
   
I have drafted a revision to fix this - thanks for finding that.
 - Section 2.3: should its title be Element information items instead of
 Character information items?
   
The section says...

  An element information item in the CellML namespace MUST NOT 
contain any
  character information items, except for character information 
items which
  consist entirely of whitespace characters. 
,
which is the constraint on the occurrence of character information items 
in CellML documents, so the title in my draft seems to make sense to me 
at least.

 - Section 2.4.3: once again (see comment on Section 1 above), there is no
 reference to CellML 1.0.
   
This is because elements in the CellML 1.0 namespace do not comply with 
CellML 1.2. Software which is attempting to process a document in 
accordance with the CellML 1.2 specification should give an error if 
they encounter an element in the CellML 1.0 namespace (if those software 
packages want to implement CellML 1.0 as well, they of course can, but 
compliance with the CellML 1.0 specification is not related to 
compliance with CellML 1.2 because, for a given CellML Infoset, the two 
specifications are mutually incompatible).

 - Section 2.4.4.a: I don't know whether this is the rendered version of your
 document that is responsible for it or not, but it might be worth
 emphasizing keywords such as local names (here, RDF)?
   
DocBook has an element called literal, which I think can be used for 
this purpose. I have changed the RDF and math cases in 
general-matters.xml, but not the remainder yet, because many of them are 
changed in various other drafts, and it might be easier to wait for some 
of them to be integrated in as the set of literals will change as a 
result of that process.

 - Section 2.5.4: I don't see the point of having when the parent
 information item is not modified and would therefore suggest to delete that
 bit. Indeed, it's a SHOULD, so the CellML Processing Software may, for
 whatever reason, decide not to implement that 'rule'.
   
The intention is that extension information on an element be preserved, 
as a matter of best practice, when a particular element in a document is 
not modified. If, on the other hand, that element is modified, then it 
would no longer make sense to try to preserve unrecognised extension 
information, because it relates to what an element used to look like. It 
is a SHOULD rule, but these define best practice, and so it is important 
we are 

Re: [cellml-discussion] Time delays in CellML models

2008-02-12 Thread Andrew Miller

 Rui Zhu wrote:
 
 Dear Catherine,

 Thank you so much for your reply! It is very helpful! Learning CellML
 modeling from an expert is a really delightful experience.

 I am having another thought. I searched online, and it says SBML
 level2 can deal with the time delay term,
Hi Rui,

I have been looking into ways in which time delays could be represented 
in CellML, and supported by CellML tools. I have been unable to find any 
way of using delayed variables in SBML (although I am aware that SBML 
Level 2 does define support for events which happen with a time delay, a 
rather different concept). I suspect that you may have come across some 
extension to SBML, which I would be interested in taking a look at. 
Would it be possible for you to point me to the information you found 
which describes how to use delayed variables in SBML?

Best regards,
Andrew

  and there is a software
 (cellml2sbml) to convert CellML to SBML. Do you think it is a good
 idea to use SBML to solve the problem? And from SBML website, there
 are a lot of tools that can run SBML model, like virtual cell. I am
 wondering if you have any idea which tool can handle the time delay
 term.  Thanks!

 Your suggestion will  be appreaciated!

 Many thanks,

 Rui ZHU
  

 - Original Message -
 From: Catherine Lloyd [EMAIL PROTECTED]
 Date: Sunday, February 10, 2008 11:19 am
 Subject: Re: time delay term in CellML model
 To: Rui Zhu [EMAIL PROTECTED]
 Cc: Poul Nielsen [EMAIL PROTECTED], Peter Hunter
 [EMAIL PROTECTED]

  
   
 Dear Rui

 Thank you for your interest in CellML.  I am familiar with the model
 you
 are interested in, and I know the original model author (Michael
 Zagar)helped me to translate this model into CellML.  I'm sorry if our
 curation status confused you - it does indeed state that the CellML
 model recreates the results of the published model - but it should
 statethat the models almost match - with the exception of the time
 delay(I'll change the text now).
 Unfortunately this is a current limitation of CellML.  While it is
 possible to express a time delay in the CellML language, the tools
 whichrun CellML models (PCEnv and COR) are unable to handle time
 delays at
 present.  This is something which we expect to be a feature in future
 releases of the software.

 Please let me know if you have any further questions and I will try to
 answer them for you.

 Best wishes
 Catherine



 Rui Zhu wrote:

 
 Dear Catherine,

 This is Rui ZHU, a Biomedical Engineering Ph.D student in   
   
 University of Southern California. I am very interested in using
 CellML to do modeling. Recently, I saw the CellML model you made
 based on the paper A Delayed Nonlinear PBPK Model for Genistein
 Dosimetry in Rats on the CellML website.
 http://www.cellml.org/models/zager_schlosser_tran_2007_version03 
 
 And I tried to use that model to do simulation using PCEnv to re-
   
   
 generate the results in the original paper. However, I found the
 result was different from the one the in original paper, and the
 reason it that, in the original paper, there is a time delay term in
 the differential equation d( Acon_b )/d(time) =  kbile  *  H_Ccon_l 
 *  Ccon_l ( t - d(t, C_gen_l) ) *  Vl, but in the CellML model the
 differential equation is without the time delay term d( Acon_b
 )/d(time) =  kbile  *  H_Ccon_l  *  Ccon_l  *  Vl. I was trying to
 add a time delay term in the CellML model, but I don't know how. If
 you have any idea of how to do it, would you please let me know.
 Thank you!
 
 Your kind help is really appreciated! Look forward to your reply!
  
 Rui ZHU
  
 
   
 
 

 ___
 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


[cellml-discussion] CellML 1.1 to draft CellML 1.2 normative specification mapping

2008-02-12 Thread Andrew Miller
Hi all,

I have now defined a mapping between CellML 1.1 and one draft of CellML 
1.2. I have put this up at:
http://www.cellml.org/Members/miller/mapping-1-1-to-draft-1.2/mapping

It currently has all the mappings from 1.1 to a particular 1.2 draft, 
although it may be missing some of the reverse mappings.

Best regards,
Andrew
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Proposal: Simplification of connections - removal of directionality and map_components

2008-02-06 Thread Andrew Miller
Hi all,

I am proposing that in CellML 1.2, we make connections between variables 
undirected (that is, we don't have an in or out on public or private 
interfaces for variables).

I am also proposing that we remove the map_components element and move 
the component_1 and component_2 attributes directly onto the connection 
element (suggestion originally from Randall Britten).

I have created a draft containing these changes. It can be viewed at:
http://www.cellml.org/Members/miller/draft-normative-spec-simplify-connections/toplevel.xhtml
or retrieved via git from 
git://repo.or.cz/srv/git/cellml-draft-miller.git branch 
simplify-connections .

There is a tracker item in the tracker at 
https://tracker.physiomeproject.org/show_bug.cgi?id=337 about this - if 
you want to be kept updated on this, then you can visit the URL, create 
a tracker account if you don't have one yet, and add yourself to the CC 
list for the tracker item.

Best regards,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models

2008-01-30 Thread Andrew Miller
 information and provide both 
directions.

Best regards,
Andrew

 Cheers,


 Quoting Andrew Miller [EMAIL PROTECTED]:

   
 Hi all,

 To aid in working out what features we should include in CellML 1.2, I
 have been looking into one of the major difficulties with creating
 re-usable metabolic models at the moment: that to compute a derivative,
 you need to know all the fluxes, but when a model is extended, new
 fluxes can be added to the model. Ideally, we should be able to define
 CellML 1.2 so that structured types can be leveraged to avoid this issue.

 I have come up with an example of how this might look in CellML 1.2.
 This is based in part off a discussion that I had earlier with Poul, so
 most of the credit for this goes to him, while most of the blame for the
 inelegant parts goes to me.

 Note that the lambda constructs without any bound variables are there to
 defer interpretation of the fluxes until they are taken from the set.
 The rationale for needing this is that if we had two statements that a
 certain real-valued flux belongs in the set, and two of them happened to
 have the same value at a particular point in time, then summing over the
 set would only include the flux value once (e.g. saying x is an element
 of N, where N is in the natural numbers, means that the value of x is a
 natural number. Saying x=5, y=5, x in N, y in N does not mean that 5 is
 in the set of natural numbers twice). On the other hand, we can have two
 different zero argument lambda functions in a set, which just happen to
 evaluate to the same value. This is consistent with the declarative
 nature of CellML - we are not saying 'add this flux to the set of
 fluxes', but rather, we are making a series of statements about what is
 in the set of fluxes, and the processing software is then summing over
 all fluxes which have been explicitly mentioned. Because we can connect
 the set of fluxes up to an importing model, doing things this way gives
 a great deal of extra flexibility.

 Notes:
 1) In practice, the substance could become an import which is re-used
 many times, and likewise for components representing various general
 types of chemical reactions.
 2) I have invented a possible way in which we could remove
 directionality from connections. No one has come up with a formal
 proposal to do it this way yet.
 3) I have followed Randall's earlier suggestion about how to structure
 connections without using component_ref. This again needs a formal
 proposal and discussion.
 4) The model uses a potential way in which we could get rid of the
 generality of groups, by replacing group and relationship_ref with a
 simple encapsulation element. This again needs to be formally proposed
 and discussed at some point.

 ?xml version=1.0 encoding=UTF-8?
 model
   xmlns=http://www.cellml.org/cellml/1.1#;
   xmlns:c11=http://www.cellml.org/cellml/1.1#;
   xmlns:c12=http://www.cellml.org/cellml/1.2#;
   xmlns:m=http://www.w3.org/1998/Math/MathML;
   name=_1_2_example
  
   component name=substance_x
 c12:variable name=fluxes type=set_of_lambda_of_real
   units=mol_per_litre_per_second public_interface=yes /
 c12:variable name=concentration units=mol_per_litre
   public_interface=yes /
 c12:variable name=time units=second public_interface=yes /
 m:math
   m:applym:eq/
 m:applym:diff/
   m:bvarm:citime/m:ci/m:bvar
   m:ciconcentration/m:ci
 /m:apply
 m:applym:sum /
   m:bvarm:cif/m:ci/m:bvar
   m:condition
 m:apply
   m:in/
   m:cif/m:ci
   m:cifluxes/m:ci
 /m:apply
   /m:condition
   m:apply
 m:cif/m:ci
   /m:apply
 /m:apply
   /m:apply
 /m:math
   /component

   component name=substance_a
 !-- Identical to substance_x. This would normally be defined once
 and imported.
   --
   /component

   component name=substance_b
 !-- Identical to substance_x. This would normally be defined once
 and imported.
   --
   /component

   component name=substance_y
 !-- Identical to substance_x. This would normally be defined once
 and imported.
   --
   /component

   !-- Represents a reaction A + B - X --
   component name=reaction_a_b_x
 c12:variable name=concentration_a units=mol_per_litre
   public_interface=yes /
 c12:variable name=concentration_b units=mol_per_litre
   public_interface=yes /
 c12:variable name=concentration_x units=mol_per_litre
   public_interface=yes /
 c12:variable name=flux_a
   public_interface=yes
   type=set_of_lambda_of_real
   units=mol_per_litre_per_second /
 c12:variable name=flux_b
   public_interface=yes
   type=set_of_lambda_of_real
   units=mol_per_litre_per_second /
 c12:variable name=flux_x

Re: [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models

2008-01-30 Thread Andrew Miller
Michael Cooling wrote:
 because if connections don't have directionality, then it makes no  
 sense in the language to say
 that a connection is from A to B, as opposed to from B to A, and we
 wouldn't want to force users to duplicate information and provide both
 

 Oops I didn't mean to imply directionality. I shouldn't have used the  
 words 'from' and 'to', sorry. It's not the language that I want to  
 change.
   
   
 I'm not sure what you mean there. In CellML 1.1, there can be attributes
 like public_interface=in private_interface=out, I have used
 something more like public_interface=yes or public_interface=no
 here, thereby removing the directionality - in and out correspond to
 yes, none corresponds to no.
 

 Ah I see. I suspect just having an optional public_interface=yes  
 would be the way to go, private=yes being always
 implicit. I.e. private by default, and public includes private. As you  
 say this will no doubt be discussed later.
   

This particular aspect has already been discussed. See 
http://www.cellml.org/pipermail/cellml-discussion/2008-January/001144.html 
and the follow on discussion for why public and private interfaces are 
not analogous to public and private in most object orientated 
programming languages, and why public does not imply private.

By default, we have public_interface=no private_interface=no, which 
means that the variable cannot be used outside of the component. 
public_interface=yes means that encapsulating components can connect 
to the variable, while private_interface=yes means that encapsulated 
components can connect to the variable.

   
 The mathematical model you get from this would be sub-optimal without
 some intelligence on the part of software tools - there would be two
 state variables with identical rates and initial values for the
 concentration of b and the concentration of y
 

 This is why I am wary of such convenience componentsthey imply an  
 interface that doesn't really exist - I think they can be useful but  
 since one never
 knows what might get connected to what
   

Removing directionality, and using sets for the list of all fluxes mean 
that it doesn't matter what the flux set is connected to behind the 
interface. The duplication of state variables is unfortunate, but it 
doesn't actually have any theoretical implications for the correctness 
of the model, if both state variables have the same initial values and 
rates (which they would, since they are the sum over the same set of 
fluxes). This means that the model should just work in all cases.

 If one tries to use them as an interface to the system that MUST be  
 used (not that you were doing this)
 then you limit the usefulness of your model...essentially you are  
 assuming that your interface is sufficient for all future
 requirements.

Yes, and that is a good assumption if you provide everything on the 
interface.

  Even for ion channels, that might not be true in the future.
 I think duplications may also be resolved by chosing a particular substance_b
 (ie human decision) at model aggregation-time facilitated by tools  
 identifying this situation.
   

I don't think we want to do that manually. The duplication is only a 
problem because it artificially inflates the dimensionality of the 
model, creating a performance problem, and the algorithm to detect this 
artificial inflation of dimensionality and merge the state variables for 
computational purposes should be tractable if we limit it to the case 
where identical variables are being put through an identical equations, 
rather than going for a more general and costly isomorphic mathematical 
structure detection.

Best regards,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models

2008-01-30 Thread Andrew Miller
Michael Cooling wrote:
 if both state variables have the same initial values and
 rates (which they would...
 

 why should they have the same initial values? I agree if they did then  
 it makes
 no difference to the correctness of the model but it seems very possible to
 create a model of system 1 with substance_b and a model of system 2  
 with substance_b and give them
 both different initial conditions, then try to combine them. In  
 practice I think this would happen more often than not, at least for  
 the systems I've dealt with so far.

 Are you talking about AFTER you've realised the conflict and have  
 already decided which value(s) to go with? Or have I missed something?
   
If two models contradict each other (such as by each stating a initial 
value for concentrations of the same species, or a different mechanism 
for the exact same reaction), then this contradiction has to be fixed 
before the models can be composed.

I am therefore focusing on clean ways to compose non-contradictory 
models which involve some overlap of chemical species (and so the 
assumption is that the initial values are the same).

Best regards,
Andrew
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Using proposed CellML 1.2 features to createmore re-usable metabolic models

2008-01-30 Thread Andrew Miller
David Nickerson wrote:
 Hi Andrew,

 This looks quite intriguing. As you mention later in this thread I 
 currently take the approach of adding an extra real scalar term and 
 exposing that as a way to hook future (in my case) currents into ion 
 concentration rate equations. Such and approach works well when I only 
 have three ion concentrations to deal with, but gets overwhelming when 
 considering many different species, such as happens when adding 
 metabolic processes to an electrophysiology model.

 Just to try and better understand your proposal by use of an example 
 closer to my own work and perhaps to also check that this approach is 
 not limited to metabolic models...

 Using this method, I would be able to say that each calcium membrane 
 current is in the set of calcium fluxes and then formulate the time 
 derivative of intracellular calcium concentration to be a sum over all 
 fluxes in that set. Then as I extend the model I simply specify any new 
 calcium currents as being in the set of calcium fluxes and the 
 intracellular calcium concentration automatically has them included.

 Have I got that right?
   

That sounds right to me - metabolic modelling was indeed only a specific 
example.

 Assuming I have understood this, how hard do you expect it to be to 
 implement support for such set summation techniques in the current 
 Auckland API implementation? I would guess this falls into the code 
 generation services rather than the core API implementation?
   

I think that supporting CellML 1.2 will require additions to both the 
core API implementation and the code generation services. Internally, 
the code generation services don't have support for anything other than 
scalars, and so adding in data types such as sets (and implementing 
operators over them) will require some fairly significant internal 
changes. However, there is no reason to believe that adding such support 
is infeasible in the long term.

Best regards,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Proposal: Secondary specifications in CellML

2008-01-29 Thread Andrew Miller
Hi all,

I am proposing that we define CellML 1.2 such that 'secondary CellML 
specifications' can be created. The primary CellML 1.2 specification 
will then define the core structure of CellML and the semantics of how 
models are created, with the secondary specifications narrowing it down 
to specific types of problems.

In CellML 1.1, there are several mechanisms equivalent to this in operation:
  1) The core 1.1 specification defines a 'CellML Subset'. This is not 
mandatory, and because there are useful operators like rem not on the 
list, neither models nor software has limited support to items on the 
list (which argues for putting such restrictions outside of the core 
specification, where updated secondary specifications can be made 
without going through the process of making an update to the primary 
specification). Furthermore, the specification doesn't describe, in 
enough detail, about how the exact types of mathematical constructs 
which are allowed. With the secondary specifications, we don't need a 
CellML Subset in the primary specification.
  2) The examples in the CellML 1.1 Specification allow a kind of 
'learning by example' about how the mathematics should be written. This 
is not very good from a specification point of view - we should describe 
precisely what is and is not allowed rather than require tool developers 
to infer this information from examples.
  3) I have previously proposed a 'Best Current Practice' for CellML 1.1 
mathematics (http://www.cellml.org/Members/miller/bcp-toplevel-maths/). 
Creating specification-endorsed formal secondary specifications extends 
this approach and removes any doubt that implementors which cannot, for 
whatever reason, support the entire primary specification, instead need 
to pick (or define) a secondary specification to specify the problem 
type the software can solve.

I wrote up a very simplistic, but I think workable, example of the delegating
text. My version is in git://repo.or.cz/srv/git/cellml-draft-miller.git branch
allow-secondary (also viewable at
http://www.cellml.org/Members/miller/draft-normative-spec-allow-secondary/toplevel.xhtml
).

CellML Processing Software is required (i.e. the use of the specification word
MUST) either support one or more specific secondary specifications, or support
every single possible CellML model. In practice, editing software may want to
take the latter option because they can, while simulation software will have no
choice but to limit support to particular well-defined classes of problems.


There is a tracker item in the tracker at 
https://tracker.physiomeproject.org/show_bug.cgi?id=332 about this - if 
you want to be kept updated on this, then you can visit the URL, create 
a tracker account if you don't have one yet, and add yourself to the CC 
list for the tracker item.

Best regards,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Using proposed CellML 1.2 features to create more re-usable metabolic models

2008-01-29 Thread Andrew Miller
Hi all,

To aid in working out what features we should include in CellML 1.2, I 
have been looking into one of the major difficulties with creating 
re-usable metabolic models at the moment: that to compute a derivative, 
you need to know all the fluxes, but when a model is extended, new 
fluxes can be added to the model. Ideally, we should be able to define 
CellML 1.2 so that structured types can be leveraged to avoid this issue.

I have come up with an example of how this might look in CellML 1.2. 
This is based in part off a discussion that I had earlier with Poul, so 
most of the credit for this goes to him, while most of the blame for the 
inelegant parts goes to me.

Note that the lambda constructs without any bound variables are there to 
defer interpretation of the fluxes until they are taken from the set. 
The rationale for needing this is that if we had two statements that a 
certain real-valued flux belongs in the set, and two of them happened to 
have the same value at a particular point in time, then summing over the 
set would only include the flux value once (e.g. saying x is an element 
of N, where N is in the natural numbers, means that the value of x is a 
natural number. Saying x=5, y=5, x in N, y in N does not mean that 5 is 
in the set of natural numbers twice). On the other hand, we can have two 
different zero argument lambda functions in a set, which just happen to 
evaluate to the same value. This is consistent with the declarative 
nature of CellML - we are not saying 'add this flux to the set of 
fluxes', but rather, we are making a series of statements about what is 
in the set of fluxes, and the processing software is then summing over 
all fluxes which have been explicitly mentioned. Because we can connect 
the set of fluxes up to an importing model, doing things this way gives 
a great deal of extra flexibility.

Notes:
1) In practice, the substance could become an import which is re-used 
many times, and likewise for components representing various general 
types of chemical reactions.
2) I have invented a possible way in which we could remove 
directionality from connections. No one has come up with a formal 
proposal to do it this way yet.
3) I have followed Randall's earlier suggestion about how to structure 
connections without using component_ref. This again needs a formal 
proposal and discussion.
4) The model uses a potential way in which we could get rid of the 
generality of groups, by replacing group and relationship_ref with a 
simple encapsulation element. This again needs to be formally proposed 
and discussed at some point.

?xml version=1.0 encoding=UTF-8?
model
  xmlns=http://www.cellml.org/cellml/1.1#;
  xmlns:c11=http://www.cellml.org/cellml/1.1#;
  xmlns:c12=http://www.cellml.org/cellml/1.2#;
  xmlns:m=http://www.w3.org/1998/Math/MathML;
  name=_1_2_example
 
  component name=substance_x
c12:variable name=fluxes type=set_of_lambda_of_real
  units=mol_per_litre_per_second public_interface=yes /
c12:variable name=concentration units=mol_per_litre
  public_interface=yes /
c12:variable name=time units=second public_interface=yes /
m:math
  m:applym:eq/
m:applym:diff/
  m:bvarm:citime/m:ci/m:bvar
  m:ciconcentration/m:ci
/m:apply
m:applym:sum /
  m:bvarm:cif/m:ci/m:bvar
  m:condition
m:apply
  m:in/
  m:cif/m:ci
  m:cifluxes/m:ci
/m:apply
  /m:condition
  m:apply
m:cif/m:ci
  /m:apply
/m:apply
  /m:apply
/m:math
  /component

  component name=substance_a
!-- Identical to substance_x. This would normally be defined once 
and imported.
  --
  /component

  component name=substance_b
!-- Identical to substance_x. This would normally be defined once 
and imported.
  --
  /component

  component name=substance_y
!-- Identical to substance_x. This would normally be defined once 
and imported.
  --
  /component

  !-- Represents a reaction A + B - X --
  component name=reaction_a_b_x
c12:variable name=concentration_a units=mol_per_litre
  public_interface=yes /
c12:variable name=concentration_b units=mol_per_litre
  public_interface=yes /
c12:variable name=concentration_x units=mol_per_litre
  public_interface=yes /
c12:variable name=flux_a
  public_interface=yes
  type=set_of_lambda_of_real
  units=mol_per_litre_per_second /
c12:variable name=flux_b
  public_interface=yes
  type=set_of_lambda_of_real
  units=mol_per_litre_per_second /
c12:variable name=flux_x
  public_interface=yes
  type=set_of_lambda_of_real
  units=mol_per_litre_per_second /
variable name=kf units=litres_per_mol_per_second 

[cellml-discussion] New Tracker Item: Describe how we can create secondary specifications to narrow CellML

2008-01-22 Thread Andrew Miller
Hi all,

I filed a tracker item on the creating of a secondary specifications on 
how to narrow CellML to support particular types of models.

https://tracker.physiomeproject.org/show_bug.cgi?id=332

Please feel free to comment on the tracker item.

Best regards,
Andrew
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Should RDF be allowed / required to be processed from extension elements?

2008-01-22 Thread Andrew Miller
Hi all,

I filed a tracker item on where RDF/XML should be allowed in CellML 
Infosets.

https://tracker.physiomeproject.org/show_bug.cgi?id=331

Please feel free to comment on the tracker item.

Best regards,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Base normative CellML Specification for further work

2008-01-17 Thread Andrew Miller
Randall Britten wrote:
 18.3 point 9 defines the hidden set for a *component*.  18.4 point 6 refers
 to the hidden set of a *variable*.  

 Similar for encapsulated set and sibling set.

 Might be OK as is, but what do you think?
   
Thanks Randall, this is exactly the type of issue we need to identify 
and fix, and I really appreciate your help in finding these types of 
issues. I have pushed a fix for this to my public git repo, and also put 
it up on my 'latest rendered version of the spec' page.

One thing this raises is how we refer to parts of other people's drafts 
- once we have a stable specification, it will be very convenient to say 
things like 18.3.9, but the problem with drafts is that the numbers are 
changing all the time and adding or removing a section would renumber 
everything. We could refer to a particular git commit id together with a 
number, e.g.
18.3.9 at  commit ac9c214d5ff051229bda8f4668430cc09c3488ef 
(http://repo.or.cz/r/cellml-draft-miller.git). However, a simpler 
low-tech approach might be to just quote the surrounding text so people 
can search for it.

Best regards,
Andrew

   
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:cellml-discussion-
 [EMAIL PROTECTED] On Behalf Of Alan Garny
 Sent: Thursday, 17 January 2008 10:52 p.m.
 To: 'CellML Discussion List'
 Subject: Re: [cellml-discussion] Base normative CellML Specification
 for further work

 Dear Andrew,

 I quite like the structure of your document. Just one thing though: I
 would
 like, at this stage, to suggest references to the official CellML
 specification. Indeed, you are no doubt very familiar with the official
 CellML specification, but in my case it has been years since I have had
 a
 proper look at it. So, it would help me (and others, I am sure!) if you
 could put some references here and there. That would 1) encourage
 people to
 give you feedback and 2) would save those of us (who are willing to
 provide
 you with some feedback) a lot of time.

 Best wishes, Alan.

 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:cellml-discussion-
 [EMAIL PROTECTED] On Behalf Of Andrew Miller
 Sent: 16 January 2008 23:30
 To: For those interested in contributing to the development of CellML.
 Subject: [cellml-discussion] Base normative CellML Specification for
 further work

 Hi all,

 I have recently been working on developing an unofficial 'base'
 normative CellML specification to provide something off which
   
 proposed
 
 changes can be based and merged into.

 The aim of this unofficial draft specification is to provide a
 minimalistic, and normative, specification of all the core
 functionality
 of CellML. It aims to correct ambiguities and contradictions from
 within
 the CellML 1.1 specification (and without reactions, simply because
   
 it
 
 wasn't worth adding them to this spec unless the consensus seems to
 indicate we might keep them).

 The specification as it stands now (which can be obtained from my
 public
 git repository, using the instructions previously posted, or viewed
   
 at
 
 http://www.cellml.org/Members/miller/draft-normative-
 spec/toplevel.xhtml
 ) needs more careful review of the following aspects:
   1) Does the specification lose any important normative information
 that CellML 1.1 includes?
   2) Is there any part of the specification that can be interpreted
   
 in
 
 more than one way (i.e. ambiguities)? I have been aiming to be very
 strict about removing alternative interpretations so there is no
 reliance on common sense to guess what the text means - this is the
 only
 way to ensure that there are no disputes about what the specification
 means, and so it would be good to fix even trivially obvious
 ambiguities.

 Known deviations from 1.1
 ---

 1) Reactions are not described, deliberately.
 2) The name attribute on group has not been described. There are
 discussion underway about what to do with group - if only
   
 encapsulation
 
 is allowed, we can simplify it and get rid of name, otherwise we may
 need to re-add it.
 3) The meaning of attributes without explicit namespace prefixes was
 defined in 1.1 to override the XML Specification. This had to be
 removed
 to prevent a conflict between the namespaces in XML normative
   
 reference
 
 and the specification text.
 4) There is nothing in the specification corresponding to the
 restrictions on group in CellML 1.1 section 6.4.3.2 bullet point 2.
   
 The
 
 reason is that this is somewhat problematic when applied across
   
 imports,
 
 and the assertion in CellML 1.1 that having multiple group elements
 makes processing more complex has not been shown to be true in
 implementation experience (while testing the rule does make things
   
 more
 
 complex).
 5) The restriction that grouping hierarchies must form a tree is only
 specified for the encapsulation. This could be extended to all

[cellml-discussion] Base normative CellML Specification for further work

2008-01-16 Thread Andrew Miller
Hi all,

I have recently been working on developing an unofficial 'base' 
normative CellML specification to provide something off which proposed 
changes can be based and merged into.

The aim of this unofficial draft specification is to provide a 
minimalistic, and normative, specification of all the core functionality 
of CellML. It aims to correct ambiguities and contradictions from within 
the CellML 1.1 specification (and without reactions, simply because it 
wasn't worth adding them to this spec unless the consensus seems to 
indicate we might keep them).

The specification as it stands now (which can be obtained from my public 
git repository, using the instructions previously posted, or viewed at 
http://www.cellml.org/Members/miller/draft-normative-spec/toplevel.xhtml 
) needs more careful review of the following aspects:
  1) Does the specification lose any important normative information 
that CellML 1.1 includes?
  2) Is there any part of the specification that can be interpreted in 
more than one way (i.e. ambiguities)? I have been aiming to be very 
strict about removing alternative interpretations so there is no 
reliance on common sense to guess what the text means - this is the only 
way to ensure that there are no disputes about what the specification 
means, and so it would be good to fix even trivially obvious ambiguities.

Known deviations from 1.1
---

1) Reactions are not described, deliberately.
2) The name attribute on group has not been described. There are 
discussion underway about what to do with group - if only encapsulation 
is allowed, we can simplify it and get rid of name, otherwise we may 
need to re-add it.
3) The meaning of attributes without explicit namespace prefixes was 
defined in 1.1 to override the XML Specification. This had to be removed 
to prevent a conflict between the namespaces in XML normative reference 
and the specification text.
4) There is nothing in the specification corresponding to the 
restrictions on group in CellML 1.1 section 6.4.3.2 bullet point 2. The 
reason is that this is somewhat problematic when applied across imports, 
and the assertion in CellML 1.1 that having multiple group elements 
makes processing more complex has not been shown to be true in 
implementation experience (while testing the rule does make things more 
complex).
5) The restriction that grouping hierarchies must form a tree is only 
specified for the encapsulation. This could be extended to all groups if 
we decide to keep groups.
6) There are no restrictions on duplicate connection elements for the 
same pair of components (but there are for duplicate connections to the 
same variables).

Best regards,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Identifying features for CellML from the SBML level 3 proposals

2008-01-15 Thread Andrew Miller
Hi all,

I have had a look through the proposals at 
http://sbml.org/wiki/SBML_Level_3_Efforts . I don't know if there is a 
draft for the 'core' of SBML level three yet, although it seems the plan 
is that it will not change much from level 2.

I think that under the current approach of splitting metadata and data 
in CellML such that anything which alters the mathematical 
interpretation of the model is data, and anything else is metadata, 
some, but not all, of the extensions for SBML 3 would be data in CellML.

Going through each extension:
* Diagram Representation: This appears to be pure metadata information.
* Spatial Features: This also appears to be pure metadata information.
* Hierarchical Model Composition: This is similar in intent to the 
import functionality already present in CellML.
* Multicomponent species: This seems to address a number of related 
problems regarding the representations of reactions which act on more 
than one species, where the species differ only by changes in 
phosphorylation state or location, or some other property like this. 
This is probably too domain specific for CellML to deal with in this way.
* Dynamic structures: This aims to allow for the structure of models to 
change dynamically (e.g. to create multicellular models). The module 
documentation notes that arrays and sets are alternative proposals for 
roughly the same kind of capability, and it is likely that only one will 
ultimately be chosen as a supported SBML Level 3 language extension.
* Arrays / Sets: This extension aims to describe something fairly 
similar to the goals of the CellML proposals to add additional data 
types other than real numbers.
* Parameter Sets: This seems to be a way to split the model mathematics 
away from parameter definitions. This is commonly already done in CellML 
using imports.
* Alternative Reactions: This aims at being able to specify what type of 
model is being expressed. It has some similarities in intent to the 
simulation metadata, but it does actually alter the interpretation of 
the model. I think that this only makes sense in SBML because of the 
domain specific representation in SBML can be mapped to multiple 
different non-domain specific mappings. In CellML, this mapping has 
already been performed. However, the extension in SBML does imply the 
ability to represent other types of models, such as stochastic models.
* Distributions: The representation of statistical distributions is 
something which CellML does not currently provide any explicit provision 
for. However, it may be something that could be fitted into CellML 
without any major changes, so is something worth studying. This may be 
complicated by the operators present as predifined symbols content 
MathML - we may need to define some new semantics to allow for this type 
of model.

Best regards,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2

2008-01-09 Thread Andrew Miller
Randall Britten wrote:

 I don’t think we would need attribute values like “public_private” or 
 “both”, since I think “public” access should imply “private” access, 
 similar to say c++ or Java’s use of those terms.

The usage of the words public and private in CellML is conceptually 
different to how programming languages like C++ and Java use them. In 
these programming languages, private means that a member can be accessed 
only from within the current class, whereas public means that the member 
may be accessed from outside of that class.

In CellML, public and private interfaces are both ways in which 
reference can be made to a variable from outside of the class. So for 
example, public_interface=none private_interface=none in CellML 
corresponds to private in C++, while public_interface=none 
private_interface=out is really equivalent to a partially public 
member in C++.

Given this conceptual difference, I think that the claim that public 
should imply private by analogy to programming languages does not 
automatically hold. It is quite meaningful (and common) in CellML to 
open the public interface but close the private interface.

Randall Britten wrote:

 Hi all
 
 Another case that illustrates that perhaps the concept of uni-directional
 connections may be flawed in a declarative language:
 
 Component A has variables x and y that are both public, but only one
al gebraic equation, hence insufficient maths to find values for x and y
 (e.g. x+y=5).
 Component B, virtually the same structure.  Has public x,y.  Has only one
 algebraic equation, so also, taken on its own, insufficient to solve for x
 or y (e.g. x-y=k(t), where k(t) is knows at each value of t, e.g.
 k(t=1)=1.).
 
 The application that attempts to solve the model has to solve the linear
 system, and it does not make sense to see x or y as owned by either A or B.

I think this depends on what the implications of 'ownership' are. If ownership 
is a purely CellML concept which does not affect the final mathematical model, 
then I think that it wouldn't prevent us from defining things this way.

I think that ownership is information which is strictly speaking, superfluous 
to the mathematical interpretation of the model. The current implementation of 
CCGS, for example, does not rely on it to provide any interpretation of the 
mathematics, although it does provide clues to help provide a human intuitive 
presentation of results. For example, the variable with no out interfaces 
(referred to as 'the source variable' in the code, which others have referred 
to as the owning variable), is used as the master variable which sets the units 
into which all other variables connected to the same variable are connected. As 
an alternative, the 'master variable' could be chosen by some other approach, 
such as randomly, or based on the first variable to appear in the model, but 
this is somewhat less robust if we seek to get consistent results from the 
model (to some extent, the directionality of connections could be considered a 
form of metadata).

Best regards,
Andrew

 
 Regards,
 Randall


 *From:* [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] *On Behalf Of *Poul Nielsen
 *Sent:* Sunday, 23 December 2007 10:25 p.m.
 *To:* CellML Discussion List
 *Subject:* Re: [cellml-discussion] A list of proposed changes to 
 semantics to makein CellML 1.2

 Yes, the scheme that I proposed would not allow variables to 'pass 
 through' the public_interface and private_interface of a component. I 
 imagine that this could be inconvenient in some situations. We could 
 enable this by adding a fourth value, 'public_private', to the 
 attribute list.

 Best wishes

 Poul

 On 2007 Dec 22, at 20:21, Jonathan Cooper wrote:



 On Sat, Dec 22, 2007 at 11:19:52AM +1300, Poul Nielsen wrote:

 I think that Jonathan is correct - the concept of 'in' and 'out'

 does not make sense in a declarative description. One way to remedy

 this would be to remove the 'public_interface' and

 'private_interface' attributes from the variable element and

 replace them with an 'interface' attribute which could assume values

 public, private, or none. This is a pretty fundamental change

 to the specification but I think that it better reflects the

 declarative intent of CellML model descriptions.

 How would that work for a component like B below, which has both a public

 and private interface for the same variable?

 Jonathan.

 On 2007 Dec 22, at 03:20, Jonathan Cooper wrote:

 On Thu, Dec 20, 2007 at 12:30:32AM +0800, David Nickerson wrote:

 * The current specification says:

 A variable with either a private_interface or
 public_interface

 attribute

 value of in must be mapped to no more than one other

 variable in the

 model. [ Note that a similar restriction does not
 apply to

 

Re: [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2

2008-01-09 Thread Andrew Miller
Randall Britten wrote:
 That is a very good point.

 Perhaps what is needed is quite different altogether.  A component like the
 sodium current needs a component to play the role of membrane, and another
 component to play the role of m gate and another to play the role of h
 gate etc.

 I think what we are aiming to do is make sure that the component playing the
 role of membrane is connected to the appropriate variables, likewise, the
 component playing the role of m gate etc.

 This leads to the idea of specifying what roles a component can play, what
 roles it requires external components to play, and associating variables
 with the roles.

 Using Beeler-Reuter as an example:
 Component sodium-current needs components to play the following roles:
 membrane(variable: V) role; 
 environment(variable: time) role;
 m-gate(variable: m) role;
 h-gate(variable: h) role;
 j-gate(variable: j) role.

 Component m-gate needs components to play the following roles:
 environment(variable: time) role;
 membrane(variable: V) role.
 (interestingly the current BR model lets the sodium current play both these
 roles for the m-gate).

 We are already doing this in a sense, but the possible roles are hard-coded
 to the unfortunately named public and private: in means requires,
 out means provides.
   
I think that this discussion has now forked into two different aspects, 
although they are somewhat intermingled.
  1) Should we have a directionality to connections on interfaces?
  2) Should we limit the number of interfaces to two, or should we 
provide for more than two interfaces?

On the issue of directionality with respect to the Java analogy, I would 
like to note that unlike CellML, Java is a procedural language, and so 
while the concept of requires and provides makes sense for Java, it 
probably makes less sense for a declarative language (I am not 
suggesting that you are not aware of that, of course, but am merely 
restating this by way of summary). Therefore, if we are going to break 
compatibility in all cases, then a simple yes or no on each interface 
will be sufficient, as opposed to an in, out, or none (unless we want to 
assign an arbitrary direction for some other purpose).

On the issue of providing more than two interfaces, I agree that, in 
some sense, it is rather unfortunate to be limited to a single hierarchy 
with one interface going up, and one interface going down. However, this 
hierarchy also interacts with other features like imports in a fairly 
important way. We could redesign imports so that you get to choose which 
interface to leave exposed, and which one to pull in grouped imports 
from (currently, anything on the private facing side gets pulled in with 
a component, while the public facing side is left exposed in the 
importing model. If 'private' was to no longer have special meaning, 
this would no longer make sense). This also gets messier because 
encapsulated components can in turn have encapsulated components, and 
any new, more generic system would need to provide new semantics to 
replace this behaviour.

I think it also comes down to whether we would be prepared to make such 
a major structural change for CellML 1.2 - it would inevitably delay the 
production of a new specification quite substantially while all the 
implications of the change were studied. If we decide not to do it for 
CellML 1.2, it might still be worth thinking whether we could do 
anything in 1.2 to ease the transition in the future.

Best regards,
Andrew

 The idea of specifying what roles a component can play is analogous to
 specifying what interfaces a Java class implements.  The idea of specifying
 what roles a component requires other components to play is analogous to
 dependency injection, again from the Java world.

 Regards,
 Randall

   
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:cellml-discussion-
 [EMAIL PROTECTED] On Behalf Of Andrew Miller
 Sent: Thursday, 10 January 2008 1:39 p.m.
 
 ...
   
 For example, the total sodium current in the Beeler-Reuter model is
 meaningless to the parts which contribute to the sodium current, and
 isolating them properly from each other helps prevent coding errors in
 the encapsulated gate components. This makes the sodium current
 variable, in the sodium current component, an example of when publicly
 visible but privately hidden interfaces make sense.

 

 ___
 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


[cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs

2008-01-08 Thread Andrew Miller
Hi all,

There have recently been some discussions of changes which would 
drastically break forwards or backwards compatibility of CellML (for 
example, changing the way that connections work).

I think that it is important that we come to some consensus on what the 
policy for inter-version compatibility in CellML should be quite soon, 
because this drastically affects decisions that need to be made in 
CellML specification development.

It doesn't really make sense to be inconsistent with respect to version 
compatibility - it would be quite unfortunate if we worked hard to keep 
compatibility for one part of CellML, and then broke it in another major 
part such as by changing the way connections work, and so I think we 
need a policy on this.

I have come up with a number of different potential policy statements on 
when backwards compatibility should be broken and when it should be 
kept. It might help us to reach consensus if members of the CellML 
community could rank the policies in order of preference (1 is the most 
preferable policy, 2 the next most, and so on), and suggest any good 
policies that may be missing.

Option A)
Future versions of CellML should aim to solely express the intention of 
previous versions better and more clearly. They should aim to keep full 
compatibility with an implementation of the specification according to 
the rules of the specification as they were interpreted by implementors.

Option B)
Future versions of CellML should try to be mostly compatible with 
existing implementations of previous versions of CellML. They may remove 
functionality that does not have an established base of software which 
correctly implements that functionality. They may also add in new 
functionality, if that new functionality significantly increases the 
expressiveness of the language. However, in normal circumstances, 
compatibility should be maintained, so that when a model not using new 
features is saved in the new version's most preferred format, it can 
still be correctly loaded into software only supporting the old version. 
Likewise, a model not using any removed features should be able to be 
loaded in software supporting only the new version of the specification.

Option C)
Future versions of CellML should make any changes which make it 
conceptually cleaner, even if there is a less clean compromise available 
that would have lesser compatibility implications. Software will need to 
explicitly support more than one version as a completely separate format.

My preferred choice is Option B. Despite being apparently at opposite 
ends of the spectrum, Option A and Option C are, in my opinion, fairly 
similar, because if we adopted Option A, larger changes would appear in 
a new specification called something other than CellML. Although there 
could be advantages of coming up with a more meaningful name than 
CellML, I think that this would also set us back in terms of community 
awareness of the specification, and so I think that Option C is 
marginally better than Option A (i.e. my personal order of preference is 
currently B:1, C:2, A:3).

I look forward to any feedback on this you may have.

Best regards,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Survey on opinions for the backwards compatibility levels for future CellML Specs

2008-01-08 Thread Andrew Miller
 
with the ugliness of some historical decisions for longer because of it.

Best regards,
Andrew

 Best wishes
 Poul

 On 2008 Jan 09, at 11:58, Andrew Miller wrote:

   
 Hi all,

 There have recently been some discussions of changes which would
 drastically break forwards or backwards compatibility of CellML (for
 example, changing the way that connections work).

 I think that it is important that we come to some consensus on what  
 the
 policy for inter-version compatibility in CellML should be quite soon,
 because this drastically affects decisions that need to be made in
 CellML specification development.

 It doesn't really make sense to be inconsistent with respect to  
 version
 compatibility - it would be quite unfortunate if we worked hard to  
 keep
 compatibility for one part of CellML, and then broke it in another  
 major
 part such as by changing the way connections work, and so I think we
 need a policy on this.

 I have come up with a number of different potential policy  
 statements on
 when backwards compatibility should be broken and when it should be
 kept. It might help us to reach consensus if members of the CellML
 community could rank the policies in order of preference (1 is the  
 most
 preferable policy, 2 the next most, and so on), and suggest any good
 policies that may be missing.

 Option A)
 Future versions of CellML should aim to solely express the  
 intention of
 previous versions better and more clearly. They should aim to keep  
 full
 compatibility with an implementation of the specification according to
 the rules of the specification as they were interpreted by  
 implementors.

 Option B)
 Future versions of CellML should try to be mostly compatible with
 existing implementations of previous versions of CellML. They may  
 remove
 functionality that does not have an established base of software which
 correctly implements that functionality. They may also add in new
 functionality, if that new functionality significantly increases the
 expressiveness of the language. However, in normal circumstances,
 compatibility should be maintained, so that when a model not using new
 features is saved in the new version's most preferred format, it can
 still be correctly loaded into software only supporting the old  
 version.
 Likewise, a model not using any removed features should be able to be
 loaded in software supporting only the new version of the  
 specification.

 Option C)
 Future versions of CellML should make any changes which make it
 conceptually cleaner, even if there is a less clean compromise  
 available
 that would have lesser compatibility implications. Software will  
 need to
 explicitly support more than one version as a completely separate  
 format.

 My preferred choice is Option B. Despite being apparently at opposite
 ends of the spectrum, Option A and Option C are, in my opinion, fairly
 similar, because if we adopted Option A, larger changes would  
 appear in
 a new specification called something other than CellML. Although there
 could be advantages of coming up with a more meaningful name than
 CellML, I think that this would also set us back in terms of community
 awareness of the specification, and so I think that Option C is
 marginally better than Option A (i.e. my personal order of  
 preference is
 currently B:1, C:2, A:3).

 I look forward to any feedback on this you may have.

 Best regards,
 Andrew

 ___
 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
   

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Should groups be allowed to imply metadata information?

2007-12-11 Thread Andrew Miller
Hi all,

The CellML 1.1 specification says:


6.5.3  Groups must not imply metadata information

Modellers must not use CellML groups to associate properties or 
classification information with sets of components. The metadata 
functionality is the proper method for making such associations. This 
increases the chance of that information being used by a range of CellML 
processing software.


If extension groups cannot be used to imply metadata or mathematical 
information, then there is not really anything left for them to imply. I 
think that we should do one of the following:
1) Non-standard relationship types be disallowed, and only encapsulation 
and containment be kept (encapsulation does affect the mathematical 
formulation of the model, while containment is really metadata 
information), or perhaps only encapsulation should be kept, with 
containment data represented in metadata, or,
2) Allow groups to be used for metadata information, but in the 
informatively annotated specification encourage the CellML community to 
standardise on exactly how a certain type of metadata should be 
represented (this is required whether RDF/XML or groups is used to 
express the metadata anyway).

I would welcome any opinions that anyone might have on this.

Best wishes,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] CellML terminology: distinguishing CellMLmodels from the XML in which they are represented

2007-12-11 Thread Andrew Miller
David Nickerson wrote:
 I think option 1 would be much better than 2.

 An alternative might be the RDF and RDF/XML approach? Not too sure what 
 that implies, but personally I see it as an RDF graph and then the XML 
 serialisation of that graph. Could we use something like CellML Model 
 and CellML Model/XML or maybe CellML/XML ?
   
I think that this could be heading towards the right approach, although 
I'm not sure that the XML serialisation is automatically the right layer 
of abstraction to refer to (we are only defining XML parsing by 
reference, although RDF/XML does as well) - perhaps the XML Information 
Set could be the lowest level, and we describe how that relates to the 
conceptual componentised model after import processing, and ultimately 
the conceptual non-componentised mathematical model (when mathematical 
equations are present).

How about CellML Infoset, CellML Model, and Mathematical Model?

Best regards,
Andrew


 Andre.

 Andrew Miller wrote:
   
 Hi all,

 I have been working on resolving the current terminology issues in 
 CellML 1.1 where 'model' is used to mean both the XML file in which the 
 model element resides, and the abstract mathematical model represented 
 by that XML file when any imports have been processed. This overloading 
 has occurred as a result of the transition from CellML 1.0 to CellML 
 1.1. It is an issue which is worth trying to resolve, because issues 
 like this cause the CellML 1.1 text lacks the precision that a well 
 specified format should have.

 In my initial drafting work, I used the terms 'CellML File' and 'CellML 
 Model' to distinguish the two concepts. These terms were defined, but 
 the aim was that they could be understood without needing to refer to 
 the definitions.

 However, concerns about this have been raised, because what is being 
 referred to as a CellML File could be embedded into another XML 
 document. This could be addressed by ensuring the definition of CellML 
 File allows for that, but confusion could still occur from this.

 There were several alternatives proposed at today's CellML meeting:
 1) 'CellML Model with no imports or with uninstantiated imports' vs 
 'CellML Model with all imports instantiated'. The problems with this is 
 that it is cumbersome especially when it appears multiple times in the 
 same sentence (and would possibly be unambiguous in that case), it is 
 confusing to use these terms before imports have been explained, or in 
 the section explaining imports, and it doesn't create a very clear 
 conceptual separation between the representational layer and the model 
 represented in that representational layer.
 2) 'CellML model element information item and all descendant information 
 items' vs 'CellML Model'. The former is reasonably cumbersome and would 
 probably be confusing when used in a sentences.
 Examples from the beginning of the specification of how it could sound...
 Every CellML model element information item and all descendant 
 information items SHALL be represented in an XML document which conforms 
 with the well-formedness requirements of the XML 1.0 specification
 Two CellML model element information items and all descendant 
 information items shall be equivalent if one can be transformed to 
 another by making zero or more of the following changes
 3) Make up an acronym of some kind.

 I have looked into other specifications which may have similar 
 requirements. XInclude uses the phrases 'source infoset' and 'result 
 infoset', and writes the specification as a transformation between the 
 two. I don't think this could work for CellML because import processing 
 is not easily described as a simple transformation, and it is part of a 
 large specification which also cannot easily be written as a 
 transformation (unless we want to describe CellML with imports as a 
 transformation to a single CellML model file with no imports, and then 
 describe that in terms of a transformation into MathML, which might work 
 but would be radically different from the approach we have taken so far).

 I think we have a few remaining options:
 1) Retain the CellML File / CellML Model terminology, and then create 
 another mini-specification for how to embed CellML into other documents 
 which explains that a CellML File is not necessarily the document 
 element. This would probably be a good way to take the specification 
 from a standardisation point of view, because by and large we want 
 people to be exchanging files which have the CellML model element as the 
 document element if they are calling it a CellML File - otherwise it is 
 some other type of document which happens to have CellML embedded in it, 
 and it is not possible to use it from standard CellML tools.
 2) Invent an abbreviation. I suggest 'CellML Model Representation (CMR)' 
 vs 'CellML Model Instantiation (CMI)', as one option, although this 
 again could be confusing. However, upon seeing these for the first the 
 reader

Re: [cellml-discussion] CellML terminology: distinguishingCellMLmodels from the XML in which they are represented

2007-12-11 Thread Andrew Miller
David Nickerson wrote:
 Andrew Miller wrote:
   
 ...
 How about CellML Infoset, CellML Model, and Mathematical Model?
 

 That sounds good to me. While I guess this use of infoset is pretty 
 common in the XML world, it might be useful to refer to the CellML XML 
 Infoset? Or is it safe to assume that people reading the specification 
 have some familiarity with XML concepts?
   
I am not sure that having the words XML aid interpretation. Also, there 
has been some work to create alternative, non-XML serialisations of the 
infoset - see Fast Infoset for example, which is on an ITU-T 
standardisation track. We are not talking specifically about the XML 
serialisation in the places where XML Infoset is mentioned (although of 
course XML serialisation is the standard for CellML, anything else would 
be an extension). However, given that the definition of CellML Infoset 
would reference the XML Information Sets specification, I am not sure 
that we really need to repeat XML everywhere.

Best regards,
Andrew

 ___
 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] specification draft and docbook

2007-11-27 Thread Andrew Miller
David Nickerson wrote:
 Hi Andrew,

 I have just starting looking at using git and checking your current 
 draft of the specification. I have made a few changes and attach the 
 patch (generated with git diff -p  andre.patch). Not really sure the 
 best way to do things in order to share changes - I guess if there are 
 going to be many its worth signing up at the same place hosting your 
 draft? but then I'll probably not have to much time to devote to this...
It did prove very easy to set up the repository, however. If it is too 
hard I guess we need to try to arrange our own CellML-specific hosting.


 Anyway, about the only significant change I made was to turn all the 
 sect1 and sect2's into section's - while this is probably more a 
 personal preference, it seems to be a widely used one.
I have now pushed that change to my branch 
(643b9d1260e9a64f6a0a20f79d6c88665e1dcc7a in git).

 Hardcoding section levels just seems a bad thing to be doing to me, 
 especially when you're using XInclude to include multiple documents 
 into a single documentalthough maybe you are trying to force those 
 sections to a specific depth regardless of where they are imported into?

 And then a couple of other things I changed that we can maybe discuss 
 more on cellml-discussion. You are using 'CellML File' as the base 
 unit whereas I generally think of them as documents - especially in 
 the context of generated data which may never exist in an actual file. 
 Again, just my preference :)
I created a branch normative-andre to track what your current opinion of 
the specification should be (of course, things like 'Change File to 
Document' won't keep up with new instances where 'CellML File' is 
added). This was pushed to my public repository on the normative-andre 
branch as 92b7b3a7515c7aae22f42b417296ad263fee9433.

Best regards,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] specification draft and docbook

2007-11-23 Thread Andrew Miller
David Nickerson wrote:
 Hi Andrew,
 
 I have just starting looking at using git and checking your current
 draft of the specification. I have made a few changes and attach the
 patch (generated with git diff -p  andre.patch). Not really sure the
 best way to do things in order to share changes - I guess if there are
That way is probably okay for small changes. I believe git has ways to
e-mail patches while keeping the change identifier - that might make it
easier to merge back and forwards in the future, because if I commit
your change and you update, it would be good if there was no need to
re-merge that patch. I have never actually tried git's e-mail features,
although I believe that they are used extensively for Linux kernel
development.

 going to be many its worth signing up at the same place hosting your
 draft? but then I'll probably not have to much time to devote to this...
 
 Anyway, about the only significant change I made was to turn all the
 sect1 and sect2's into section's - while this is probably more a
 personal preference, it seems to be a widely used one. Hardcoding
 section levels just seems a bad thing to be doing to me, especially when
 you're using XInclude to include multiple documents into a single
 documentalthough maybe you are trying to force those sections to a
 specific depth regardless of where they are imported into?

Thanks, using section seems to make sense.

 
 And then a couple of other things I changed that we can maybe discuss
 more on cellml-discussion. You are using 'CellML File' as the base unit
 whereas I generally think of them as documents - especially in the
 context of generated data which may never exist in an actual file.
 Again, just my preference :)
I guess the only issue is that file implies it is always a single XML
file, while document could potentially be more than one file.


 
 And the second point, which I'm sure has been discussed in the past but
 I can't quite recall is the statement that CellML processing software
 should not attempt to process documents containing elements in the
 CellML 1.0 namespace. Perhaps you could just refresh my memory as to
 where that came up before?
The idea is that CellML 1.0 and CellML 1.1 namespaces shouldn't be
mixed. CellML 1.x (x  1) processing software can also process CellmL
1.0 files, but it must do so in accordance with the CellML 1.0
specification, and not in accordance with any of the future
specifications, because CellML 1.0 documents are not valid under those
later specifications. The annotated specification will probably need to
explain this, but that explanation is not necessary to define CellML 1.2
and so not really appropriate in a normative-only version of the document.

Best regards,
Andrew

 
 
 Thanks,
 Andre.
 

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] Question on community's preferred way to resolve CellML 1.1 identifier contradiction

2007-11-21 Thread Andrew Miller
Hi all,

I have been working on writing up a purely normative, unambiguous draft 
of the CellML specification to facilitate discussions of how to improve 
CellML in the future. As part of this, I have been rewriting most of the 
text of the specification to follow good practices for normative 
specifications.

One thing I have noticed during this process is that CellML's current 
text defining the format for CellML identifiers contradicts itself:



A valid CellML identifier must consist of only letters, digits and

underscores, must contain at least one letter, and must not begin with

a digit. This can be written using Extended Backus-Naur Form (EBNF)

notation as follows:

letter ::= 'a'...'z','A'...'Z'

digit  ::= '0'...'9'

identifier ::= ('_')* ( letter ) ( letter | '_' | digit )*




The EBNF specification does not permit an identifier like _1foo because 
it does not contain a letter before an underscore, while the text of the 
specification does, because it contains only letters, digits, and 
underscores, contains at least one letter, and does not begin with a digit.

One rule or the other will need to be decided for the next CellML 
specification.

I have, for now, taken the rule in the text as being normative and have 
written it up. Note that I have not included an EBNF representation - 
this will belong in explanatory notes which annotate the normative 
specification.



Basic Latin alphabetic character

A Unicode character in the range U+0041 to U+005A or in the range U+0061 to 
U+007A.

European numeric character

A Unicode character in the range U+0030 to U+0039.

Basic Latin alphanumeric character

A Unicode character which is either a Basic Latin alphabetic character or a 
European numeric character.

Basic Latin underscore

The Unicode character U+005F.


The following data representation formats are defined for use in this 
specification:
   1.

CellML identifier:

 1.

SHALL be a sequence of Unicode characters.

 2.

SHALL NOT contain any characters except basic Latin alphanumeric 
characters and basic Latin underscores.

 3.

SHALL contain one or more basic Latin alphabetic characters.

 4.

SHALL NOT begin with a European numeric character.




Please let me know if you have an opinion on whether we should instead 
base this off the validity rules specified in the EBNF form from CellML 1.1.

Best regards,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Proof of concept: using git for specification development

2007-11-11 Thread Andrew Miller
Alan Garny wrote:
 git is also a distributed version control system - the two tools have a
 fairly similar conceptual model in terms of how they work, with a lot of
 flow of ideas between the too tools. I have found git slightly faster
 and a bit more extensible (and with a larger set of commands out-of-the
 box), although one downside is that git front-ends are largely written
 in shell-script, which means you Cygwin to use it on Windows.
 

 That's a big downside in my opinion. We cannot seriously expect some Windows
 users interested in CellML to install Cygwin only to be able to change the
 specifications.

 Is there really no 'simple' web interface that could be used and that is
 still 'acceptable'? If you want to get the community involved, you want
 something as 'simple' as plug-n-play, not something that involves tweaking
 things around.
   
There are viewable web interfaces for git - see the gitweb at e.g.
http://repo.or.cz/w/cellml-draft-miller.git?a=tree;h=normative;hb=normative

Of course, whatever format we use we will also want a rendered version.

In terms of changes, users who don't do enough work on the specification 
to justify setting up a git environment can always propose changes to 
the mailing list. If they use git, it just makes it easier for us to 
share and merge their changes. I don't know how many major contributors 
to specification development we would have who wouldn't want to install 
Cygwin anyway - perhaps if there is anyone who this applies to on the 
list now is the time to speak up :).

There is an MingW / MSYS based git port as well - 
http://msysgit.googlecode.com/files/GitMe-0.4.2.exe - I haven't tried it 
myself.

We could use Mercurial - the only issue there is that the only free 
hosting I could find ( http://www.assembla.com ) looks like it is part 
of some company's business model and so I wouldn't want to rely on it 
remaining free - we don't really want to require people who want to set 
up their own repositories to rely on that.

Best regards,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Proof of concept: using git for specification development

2007-11-11 Thread Andrew Miller
Alan Garny wrote:
 Andrew Miller wrote:
   
 Alan Garny wrote:
 

 There are viewable web interfaces for git - see the gitweb at e.g.
 http://repo.or.cz/w/cellml-draft-
 miller.git?a=tree;h=normative;hb=normative
 

 How does it work?

 Using Opera, if I click on blob for abstract.xml, I get:

 ---
 This document is an unofficial working draft. The below describes the
 intended status of the specification, and not the current status right now.
 This document specifies CellML 1.2, an XML-based language for describing and
 exchanging mathematical models. This is the normative specification of
 CellML. It is intended to provide the minimum amount of information needed
 to accurately describe CellML. An alternative version is available which is
 annotated with much more explanatory material.
 ---

 While with Firefox, I get told that [the] XML file does not appear to have
 any style information associated with it and get show the document tree.
 Using Internet Explorer, I get told that the XML file cannot have multiple
 DOCTYPE declarations.
   

My demo setup uses DocBook together with XInclude to assmeble the 
document - if we use DocBook as our source format, we will also need to 
provide an easier way to view it - this could be as simple as 
referencing an XSL as the style information so people's browsers can 
view it - but I don't think this will help with the XInclude as I 
believe it is not generally supported in browsers (although we could 
create a trivial Javascript XInclude processor and include it in the 
repository which would allow people to visualise the latest version in 
their browsers, with the only requirement being a Firefox / recent IE / 
Opera browser with Javascript enabled).

 My point is that I would most likely need to learn about git before being
 able to use it. I might do that if that's what you guys end up using, but do
 you really expect others to do that? Can you really not opt for a 'simpler'
 solution?
   

git, Mercurial, and Bazaar are really the only automated distributed 
version control systems that I know of - if we don't use one of those 
then we will end up manually co-ordinating everything that git would do. 
I think it is better to have an automated system while still being open 
to changes suggested by e-mail, rather than to not have an automated 
system at all.

   
 Of course, whatever format we use we will also want a rendered version.

 In terms of changes, users who don't do enough work on the specification
 to justify setting up a git environment can always propose changes to
 the mailing list. If they use git, it just makes it easier for us to
 share and merge their changes. 
 

 Am I to understand that git has become the solution of choice?
   
No, this is a proof of concept set-up to facilitate discussion of the 
options.

   
 I don't know how many major contributors
 to specification development we would have who wouldn't want to install
 Cygwin anyway - perhaps if there is anyone who this applies to on the
 list now is the time to speak up :).
 

 I would certainly be interested to know indeed. I would be happy to
 contribute to the specifications, but I am not willing to install Cygwin for
 something that I am not going to use on a daily basis.
   
 Again, there must be an easier solution?! 
   

The MingW based system mentioned below might suit your requirements, or 
you perhaps you could use git from a Linux virtual machine that you have 
already got set up?

  
   
 There is an MingW / MSYS based git port as well -
 http://msysgit.googlecode.com/files/GitMe-0.4.2.exe - I haven't tried it
 myself.

 We could use Mercurial - the only issue there is that the only free
 hosting I could find ( http://www.assembla.com ) looks like it is part
 of some company's business model and so I wouldn't want to rely on it
 remaining free - we don't really want to require people who want to set
 up their own repositories to rely on that.
 

 I would be interested to hear from people interested in contributing to
 CellML, and the kind of solution they would like to see implemented.

 Right now, I feel like git is not a suitable solution. What about DocBook
 and the other solutions that have been suggested so far?
   
git, Mercurial, and Bazaar solve quite orthogonal problems to DocBook:
1) git and other similar technologies are used to track the 
specification - that is, they allow each person working on 
specifications to keep track of what they think should be the latest 
version of specification, and create changes relative to that, and share 
those changes with other people.
2) DocBook and similar technologies are for representing a particular 
version of a document in a computer-readable way that can be converted 
to various other formats.

We still need to decide on how we represent our specification regardless 
of how we track changes made to it (my example git

Re: [cellml-discussion] Proof of concept: using git for specification development

2007-11-10 Thread Andrew Miller
Bob Gustafson wrote:
 Besides git, there is Subversion and a new distributed SCM: Mercurial
 
  http://www.selenic.com/mercurial/wiki/
 
 Being distributed, it may have advantages for cellml, considering the
 worldwide spread of cellml participants.

git is also a distributed version control system - the two tools have a
fairly similar conceptual model in terms of how they work, with a lot of
flow of ideas between the too tools. I have found git slightly faster
and a bit more extensible (and with a larger set of commands out-of-the
box), although one downside is that git front-ends are largely written
in shell-script, which means you Cygwin to use it on Windows.

There are tools such as tailor which can probably perform two-way merges
between the two systems (I haven't tried).

As a centralised system, Subversion is probably not very usable for
specification development, because it means you have a single,
centralised version of the specification (although you could create
branches, but it still requires permissions be granted to people just to
create branches), while git / Mercurial / Bazaar can do that sort of
thing out of the box.

It is not really the physical location which gives distributed version
control systems the big win, but rather, the fact that creating an
official specification requires that numerous proposed changes,
sometimes mutually exclusive, from people who may not know each other,
be written up and maintained, and as consensus begins to be reached, get
merged together to form a final, official specification. There have been
lots of ideas proposed, but because we don't yet really have good
processes for going from proposals to the concrete text of the
specification, nothing has really come out of these proposals yet.

If we choose to use a distributed VCS system like git for this, I can
create my personal specification repository, and others can create their
repositories too (perhaps derived from my version for example), make
some changes, and then announce them on the mailing list. At this point,
if the consensus seems to be that these changes should be in the
specification, I could pull them into my repository. Eventually, when
there don't seem to be any more changes being discussed, someone who has
been curating changes accepted by consensus in their repository can
propose that this curated version becomes the official version, and if
the community agrees, we will have a specification, complete with the
merged revision histories from everyone who worked on it.

Best regards,
Andrew

 
 Bob G
 
 On Thu, 2007-11-08 at 13:44 +1300, Andrew Miller wrote:
 Hi all,

 As a proof of concept, I have set up an unofficial CellML specification 
 git at http://repo.or.cz/w/cellml-draft-miller.git . This repository is 
 intended to show the concept of using a distributed revision control 
 tool to work on specification development, and not to suggest that this 
 is necessarily the type of technology which will be used for the actual 
 specification development.

 I have used DocBook as the source format in this repository based on the 
 preliminary consensus on the CellML discussion mailing list - again, 
 this is not intended to suggest that DocBook will be the final format 
 used for specification development, but to show the concept, as one 
 format or another needs to be chosen even at he proof-of-concept stage.

 git clone git://repo.or.cz/cellml-draft-miller.git andrews-spec-version
 cd andrews-spec-version
 git checkout -b normative remotes/origin/normative

 You now have a local repository of my unofficial draft version of the 
 specification. You can make and commit your own changes locally, and 
 potentially push them to your own publicly visible repository (which 
 would allow me, or someone else to pull the changes into my version). 
 This makes it easy for everyone to keep their own draft versions, and 
 merge in changes that they agree with from others. We could eventually 
 set up an official git where changes which become widely accepted are 
 pushed, and to provide a starting point for people wanting to propose 
 additional changes.

 BTW on my system, I can generate the HTML output using:
xsltproc --xinclude --param section.autolabel 1 
 /usr/share/xml/docbook/stylesheet/nwalsh/xhtml/docbook.xsl toplevel.xml 
  toplevel.xhtml

 The exact command you should use will depend on where things are 
 installed on your system.

 Best regards,
 Andrew

 ___
 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

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Representing the next version of the CellML Specification

2007-11-07 Thread Andrew Miller
Matt wrote:
 On 8/11/2007, at 10:27 AM, Randall Britten wrote:

   
 Hi all

 Another option to add to the mix: using a Wiki.  In this case, I would
 specifically suggest MediaWiki (a la Wikipedia).
 Pros:
 -Widely used, lots of user familiarity.
 -Easy collaboration: edits done via web interface.
 -Built in diffs and revision history.
 -Linking when done via web interface works well.
 -Can be rendered as PDF on demand (haven't tested this myself, but  
 docs say
 it can be done).

 Cons:
 -Requires setup and maintenance of another content management system.

 Unsure:
 -Usually Mathml handled with LaTex substrings, not sure how to  
 handle MathML
 in MediaWiki.
 
Also, the difference between this and the previous suggestions is that 
MediaWiki is a software package as much as a format - it is difficult to 
separate the format from the software package so that you can work with 
files on your local system and then render them (although perhaps it 
could be done with a little bit of PHP coding), which means that the 
wiki software imposes a highly centralised revision and change control 
model on us in addition to providing a format for the representation of 
the data.

I am not sure that the wiki change-control system is very good for 
writing open specifications as part of a community effort - wikis are 
only efficient for collaboration if you have a policy of making changes 
and then discussing them afterwards, and changes need to be either 
'rolled back' fairly quickly after they were applied, or manually 
corrected later. This won't really work if there are lots of different 
ways to do the same thing. People can copy and paste wiki pages to 
somewhere else to make a private branch, but that will lose all change 
control history.

One thing we discussed at our Auckland meeting yesterday was the 
possibility of using a more distributed version control system. This 
approach looks promising, but before we can really ask the community to 
make a decision on this we need to set up some examples of how it could 
work, so I am planning on getting an informal example git repository up 
in the near future. The problem with MediaWiki-type format is that 
storing a format which cannot easily be converted directly to HTML with 
a command line tool doesn't really play well with this mode of 
specification development.

Best regards,
Andrew


 For the purpose of presentation math, LaTex substrings get my vote.  
 They are simple to express and their diffs in my opinion are easier  
 to interpret than diffs of MathML/XML.


 More generally, I think XML source formats should be avoided if  
 possible.

   
 Regards,
 Randall
 

 ___
 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] Representing the next version of the CellML Specification

2007-11-07 Thread Andrew Miller
Randall Britten wrote:
 Hi all

 Another option to add to the mix: using a Wiki.  In this case, I would
 specifically suggest MediaWiki (a la Wikipedia).
   
Hi Randall,
 Pros:
 -Widely used, lots of user familiarity.
   
Although MediaWiki mark-up is similar to MoinMoin and other wiki 
software have taken the idea, I am not sure that the exact same markup 
is widely used in terms of tool diversity. Wikipedia and other 
MediaWiki-powered sites are very popular, so that one particular 
software package may have been widely used compared to some of the other 
options (although HTML, DocBook, TeX, and ReST are also very ubiquitous).

 -Easy collaboration: edits done via web interface.
   
 -Built in diffs and revision history.
 -Linking when done via web interface works well.
 -Can be rendered as PDF on demand (haven't tested this myself, but docs say
 it can be done).

 Cons:
 -Requires setup and maintenance of another content management system.
   
Also note that MediaWiki-style markup has many of the same cons as 
reStructuredText
 * No section references by number based on reference by name in the 
source.
 * No automatic numbering aside from numbered lists (e.g. no counters).

 Unsure:
 -Usually Mathml handled with LaTex substrings, not sure how to handle MathML
 in MediaWiki.
   
As Matt said, this is an adequate representation of presentation 
mathematics (content mathematics would of course be represented in 
literal blocks, so any math representation is probably adequate).

Matt also said More generally, I think XML source formats should be 
avoided if  possible. I don't agree with that, because for many 
purposes XML does provide a very good compromise between tool simplicity 
and human readability, and often the unambiguous and simple rules aid 
both human and machine processing of the document. MathML is an example 
of where unaided human processing of an XML format becomes unwieldy and 
error prone, because the requirement for unambiguous mathematical 
mark-up ends making the language too verbose. However the same concerns 
don't apply when there are WYSIWYG editors (e.g. for HTML), or where the 
mark-up does not have to be so dense (for example, delimiting 
paragraphs, but having whole paragraphs as text nodes). In this case you 
can feasibly put the tags on their own lines and readability is not that 
bad (although following structural changes may be more difficult).

Best regards,
Andrew
 Regards,
 Randall

   
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:cellml-discussion-
 [EMAIL PROTECTED] On Behalf Of Alan Garny
 Sent: Wednesday, 7 November 2007 9:46 p.m.
 To: 'CellML Discussion List'
 Subject: Re: [cellml-discussion] Representing the next version of the
 CellML Specification

 I don't know much (if anything!) about the solutions offered here, but:

 - the current HTML version is nice for viewing from a web browser, but
 if
 you have ever tried to print things out you will no doubt have noticed
 that
 it doesn't look great anymore. I remember that there used to be a
 'proper'
 PDF version of the specifications. I really wish we still had something
 like
 that.

 - Besides the obvious (i.e. easy to use, easy to maintain, well-
 established
 technology, etc.), I am not too fussed about the solution we go for, as
 long
 as it is suitable for the end user (e.g. looks nice both on and off the
 web
 site).

 This being all said, and based on Andrew's pros/cons, I would
 personally
 vote for DocBook.

 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
   

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Representing the next version of the CellML Specification

2007-11-06 Thread Andrew Miller
Matt wrote:
 Without making a choice at the moment, I want to highlight that the  
 following are probably the most important aspects to consider in any  
 of these:

 1) can represent MathML in either content or presentation format and  
 can render MathML in the HTML output using image replacements instead  
 of expecting that the browser can render MathML (content or  
 presentation)
 2) automatic and nested section numbering and automatic generation of  
 a table of contents
   

I presume that you include references by number to automatically 
numbered sections (without having to manually enter the numbers) as part 
of this requirement? I don't think that automatically numbered sections 
give us much without this (unless we are going to refer to sections by 
name in the text and have an anchored link, which is a bit 
unconventional and isn't great if someone wants to read a printed copy 
of the specification).

 3) a reference mechanism so that citations (web or print) can be put  
 together in one place and referenced through a document language  
 citation mechanism
 4) that human readable diffs between different versions of the  
 document can be produced easily.

 One technology not on the list below is Latex. The pros and cons of  
 this should be added also.
   
  7) LaTeX
Pros:
  * Widely tested
  * Numerous output formats
  * Automated table of contents, section numbering, and section 
references
Cons:
  * Would probably need to develop styles specifically for the 
specifications unless we can find one.
  * Math support is non-MathML.
  * Geared more towards typesetting rather than generation of 
HTML-type document
  * Potentially hard to read diffs if they change lots of sections 
and therefore include parts of the markup (although perhaps easier than 
XML, depending on taste and familiarity with each markup language).

Best regards,
Andrew

 On 7/11/2007, at 2:16 PM, Andrew Miller wrote:

   
 Hi,

 One issue which came up at today's meeting for people at Auckland
 involved with CellML is how we will represent the next version of the
 CellML specification. Having a 'source' format of the specification  
 will
 make it easier for us to propose specific changes to the document  
 and so
 will hopefully allow us to make progress towards the next version  
 of CellML.

 There are a few different options out there which might be worth
 exploring. Any feedback from the wider CellML community on the  
 issue of
 how we represent the 'source' of the specification which gets  
 exchanged
 would be very helpful, and after the close of discussions we will be
 able to start preparing draft versions with proposed changes much more
 easily.

 I have identified a few possible choices, and have included my  
 views on
 what potential benefits or pitfalls of different approaches will be:

 1) Use HTML as is currently stored in the Plone Software Centre.
 Pros:
   * The source format can be directly visualised in the user's
 browser, which reduces the complexity of the required development
  environment.
   * WYSIWYG type editing possible (although the cleanness and
 consistency of such editors' output may be an issue).
   * We already have the document in this format which we could use
 as a starting point.
 Cons:
   * No automatic ability to generate section references by number
 based on a reference by name in the source.
   * Sophistication of automatic numbering limited to single
 uninterrupted numbered lists with possible manual restarts if there is
 intervening text.
   * Diffs between different HTML versions are hard to read.
   * Even if CSS is used, there will inevitably be some mixing of
 style and content, which makes it harder to make sweeping changes  
 to the
 layout, and makes it harder to create good quality PDF / RTF / plain
 text outputs.

 2) Use reStructured text.
 Pros:
   * The unrendered reStructured format is quite readable, which
 means that it is easy to learn by example, and also that diffs are  
 more
 readable.
   * Easy to set reasonable and consistent style guidelines for
 writing the specification in the reST source.
   * Reasonable tool support, including in Trac and in ZWiki.
   * Could convert to several types of output.
 Cons:
   * No section references by number based on reference by name in
 the source.
   * No automatic numbering aside from numbered lists (e.g. no  
 counters).
   * No easy way relate specific elements to specific style
 instructions if we need to do this.

 3) Use Warren's CWML language
 Pros:
   * We already have the document in this format which we could use
 as a starting point.
   * Reasonably clean markup in terms of header, section, and so  
 on.
   * Supports section references by name, which come out as
 references by number.
   * Can generate multiple output types.
   * Embedded MathML equations can

Re: [cellml-discussion] online subversion browser?

2007-10-01 Thread Andrew Miller
David Nickerson wrote:
 Thanks Matt. Would be nice to get a permanent solution soon...
   
Hi Andre,

This is one of a list of services that I also would like to have. I have 
discussed this with Randall recently and I believe he intends to follow 
them up one-by-one with IT:

1) Bug tracker (status: in progress with IT, interim solution available 
on my system)
2) Web interface to VC such as Trac Subversion viewer (status: Randall 
to bring up with IT, interim solution available on Matt's server)
3) Code cross-reference / browser such as LXR (status: Randall to bring 
up with IT, no interim solution yet)
4) Functional test management such as Litmus (status: Randall to bring 
up with IT, interim solution available on my system)
5) Crash reporting system to receive reports over HTTPS from clients, 
and provide developer access to them, such as Google Breakpad (status: 
Randall to bring up with IT, no interim solution yet. Not enabled in any 
PCEnv releases but support available in Mozilla)
6) Automated update system allowing updates to be deployed over HTTPS. 
This can be done with just a static-serving HTTPS webserver that we have 
access to push updates on to (status: Randall to bring up with IT, no 
interim solution yet. Not enabled in any PCEnv releases but support 
available in Mozilla).
7) Proposal management. This may just consist of a policy of how to use 
our existing resources better, and may involve an update to the existing 
Plone software centre.

Best regards,
Andrew

 Andre.

 Matt Halstead wrote:
   
 There is this which I have still set up to sync every 5 minutes.

 http://trac.bioeng5.bioeng.auckland.ac.nz/physiomesynctrac/browser

 You would be after:

 http://trac.bioeng5.bioeng.auckland.ac.nz/physiomesynctrac/browser/CellML_DOM_API/trunk

 While this was put up for demonstration purposes, I don't see any
 reason to remove it until we have a permanent solution.

 cheers
 Matt


 On 10/1/07, David Nickerson [EMAIL PROTECTED] wrote:
 
 Hi all,

 I was just wondering if there is any possibility at providing a ViewVC
 or similar interface to the subversion repository housing the API
 implementation
 (https://svn.physiomeproject.org/svn/physiome/CellML_DOM_API/trunk/)?
 This would make (my) life much easier for browsing around the source
 tree and comparing versions etc.


 Thanks,
 Andre.
 ___
 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
 

   

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] FW: r1756 - pce/trunk/chrome/content/ui

2007-09-19 Thread Andrew Miller
Randall Britten wrote:
 Don't you think we should put a test in somewhere for this?  (Perhaps a
 manual test for it is already in Litmus?).
   

It is already in Litmus, although we could probably do automated testing 
of PCEnv too (it requires running Javascript as part of the tests, but 
Mozilla do this so we could do this if we want to depend on having debug 
versions of Mozilla available as part of build process - probably a 
space problem for now on my VM, but once we get our testing platform I 
have asked for much more space for the Win32 image).

Best regards,
Andrew

 -Original Message-
 From: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] On Behalf Of CellML
 Automated Notifications
 Sent: Wednesday, 19 September 2007 4:11 p.m.
 To: [EMAIL PROTECTED]
 Subject: r1756 - pce/trunk/chrome/content/ui

 Author: amil082
 Date: 2007-09-19 16:10:36 +1200 (Wed, 19 Sep 2007)
 New Revision: 1756

 Modified:
pce/trunk/chrome/content/ui/Menu.js
 Log:
 Fix export CSV function, which was been broken as a consequence of the move
 to the new
 CCGS.

 Modified: pce/trunk/chrome/content/ui/Menu.js
 ===
 --- pce/trunk/chrome/content/ui/Menu.js   2007-09-18 17:47:09 UTC (rev 
 1755)
 +++ pce/trunk/chrome/content/ui/Menu.js   2007-09-19 04:10:36 UTC (rev 
 1756)
 @@ -153,34 +153,48 @@
  function WriteCSVData(datacollector, cmodel, stream)
  {
var header = '';
 -  var varit = cmodel.codeInformation.iterateVariables();
 +  var ctit = cmodel.codeInformation.iterateTargets();
var vars = [];
var i;
 -  var v, bv;
 -  while ((v = varit.nextVariable()) != null)
 -if (v.type == 0/* BOUND*/)
 -  bv = v.source.name + '(' + v.source.unitsName + ')';
 -else if (v.type == 1/* CONSTANT */)
 +  var ct, bv;
 +  var rateCount = cmodel.codeInformation.rateIndexCount;
 +
 +  while ((ct = ctit.nextComputationTarget()) != null)
 +if (ct.type == 0/* VARIABLE_OF_INTEGRATION */)
 +  bv = ct.variable.name + '(' + ct.variable.unitsName + ')';
 +else if (ct.type == 1/* CONSTANT */)
;
 -else
 -  vars[v.variableIndex] = v.source.name + '(' + v.source.unitsName +
 ')';
 -  var vc = cmodel.codeInformation.variableCount;
 -  for (i = 0; i  vc; i++)
 -  {
 -if (header != '')
 -  header = header + ',';
 -header = header + vars[i];
 -  }
 -  if (bv != null)
 -  {
 -if (header != '')
 -  header = header + ',';
 -header = header + bv;
 -  }
 +else if (ct.type == 4/* FLOATING */)
 +  ;
 +else // state variable or algebraic...
 +{
 +  var isSV = (ct.type == 2/* STATE_VARIABLE */);
 +  var isRate = (ct.degree  0);
 +  var idx = isSV ? 1 : (isRate ? rateCount + 1 : 2 * rateCount + 1);
 +  idx += ct.assignedIndex;
 +
 +  var primes = ;
 +  if (isRate)
 +  {
 +var x;
 +for (x = ct.degree; x  0; x--)
 +  primes = primes + ';
 +  }
 +  else
 +primes = '(' + ct.variable.unitsName + ')';
 +
 +  vars[idx] = ct.variable.name + primes;
 +}
 +
 +  header = bv;
 +  var vc = 2 * rateCount + 1 + cmodel.codeInformation.algebraicIndexCount;
 +
 +  for (i = 1; i  vc; i++)
 +header += ',' + vars[i];
 +
header = header + \n;
stream.write(header, header.length);
  
 -  vc = vc + 1;
try
{
  var t = 0;

 ___
 automated-notifications mailing list
 [EMAIL PROTECTED]
 http://www.cellml.org/mailman/listinfo/automated-notifications

   

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] Proposal: Standardised CellML real number format

2007-09-19 Thread Andrew Miller
Alan Garny wrote:
 Therefore, I think that we need to restrict it down to something like
 (in regular expression syntax):

 (\-|)[0-9]+(\.[0-9]+|)(E(-|)[0-9]+|e(-|)[0-9]+|)

 In other words:
   An optional - , followed by 1 or more digits from 0 to 9, followed by
 an optional decimal point (not a comma or momayyez) followed by an
 optional E or e character with a possible sign and one or more digits
 after it.
   
 probably best to allow for an optional '+' or '-' both at the start and
 following the exponent character.
 

 So something like (assuming my use of the syntax is correct):

 (\+|\-|)[0-9]+(\.[0-9]+|)((E|e)(\+|\-|)[0-9]+)

 Note that I have also 'simplified' the exponent part.
   
I don't think the exponent should be mandatory, however, as this would 
break the majority of models in use.

Best regards,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] CellML Versioning Strategy

2007-09-19 Thread Andrew Miller
Matt Halstead wrote:
 Otherwise, Matt wrote:

 
 ... You might want to scan a document to see what
 versions the model conforms up to, but one of the nice things about
 pushing these new elements/attributes into new namespaces is that you
 can still treat a model as say 1.1 even if it contains 1.2 elements
 and attributes...
   
 Treat that model in what way? Surely, if a model uses some 1.2 elements,
 then there must be a reason to it. Therefore, a 1.2 model cannot be treated
 as a 1.1 model, or did I miss something?
 

 It really depends on the intention of adding to the spec. If you are
 adding elements that change the interpretation of the CellML 1.1
 namespace elements, then yes, there is no point in trying to see only
 the cellml 1.1 model within a model that has 1.2 elements.

 Sometimes people use levels to denote changes to a spec (which often
 also a new namespace) that are additive and still render the previous
 level a valid model.
   

I think that the CellML specification should only describe 'core' 
aspects which affect the interpretation of the model. Anything which is 
additive should not be in the core CellML but should use extension 
elements or be in RDF. A simple rule to identify whether an unrecognised 
element is a fatal error is to see if it is in a namespace starting with 
http://www.cellml.org/cellml/ . If it is, then tools should assume that 
they are unable to interpret the model correctly and so should fail. If 
it isn't, it is an extension element, and so is not essential to the 
interpretation of the model, but rather is additive as Matt has 
described, and so may safely be ignored.

Best regards,
Andrew


   
 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
   

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


Re: [cellml-discussion] CellML Versioning Strategy

2007-09-19 Thread Andrew Miller
Alan Garny wrote:
 At the break-away session on the versioning strategy for CellML (which
 followed the Auckland CellML meeting today) we discussed the future of
 how we would version CellML, including whether we would put all elements
 for the next version of CellML in a completely different namespace, or
 only the elements that had changed.

 A summary of the discussion is up at
 http://www.cellml.org/meeting_minutes/MeetingMinutes19September2007/
 under Breakaway session on versioning strategy for CellML. Note that
 the participants at the session have not had a chance to correct errors
 in it yet, and it may not yet accurately reflect everyone's view.
 However, it does lay out the options, and so may provide a starting
 point for any suggestions or comments from the community.

 Please send and such suggestions or comments to the CellML discussion
 mailing list prior to the 3rd October 2007.
 

 That all seems reasonable to me, just one comment:

 - At the moment, CellML doesn't explicitly support the rem element
 (remainder function in MathML), even though CellML does allow its use (at
 the risk of ending in a situation where a model may work fine in a given
 CellML tool -- that supports the rem element --, but not in a nother -- that
 doesn't support the rem element --). Now, say that we officially want CellML
 to 'support' the rem element, how do we go about doing that?
   
A lot of things are valid CellML but are not supported by everyone 
(really, the only thing widely supported are systems of ODEs). CellML 
provides the overarching structure for describing these things, and we 
need to start to narrow down exactly what tools should be supporting as 
well, using compatibility documents or something like that which 
describe a feasible subset of CellML to implement. The could be more 
than one of these, but we don't want there to be too many similar 
documents. However, I think we should keep them away from the core of 
CellML, because CellML's generality is quite useful when it comes to 
expanding into new types of problems (for example, constitutive laws, 
PDE systems, and so on).

Best regards,
Andrew

 Otherwise, Matt wrote:

   
 ... You might want to scan a document to see what
 versions the model conforms up to, but one of the nice things about
 pushing these new elements/attributes into new namespaces is that you
 can still treat a model as say 1.1 even if it contains 1.2 elements
 and attributes...
 

 Treat that model in what way? Surely, if a model uses some 1.2 elements,
 then there must be a reason to it. Therefore, a 1.2 model cannot be treated
 as a 1.1 model, or did I miss something?

   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] r1755 - in pce/trunk/chrome/content: controls ui util

2007-09-18 Thread Andrew Miller
Hi,

A few review comments for this commit are inline.

CellML Automated Notifications wrote:
 Author: agarny
 Date: 2007-09-19 05:47:09 +1200 (Wed, 19 Sep 2007)
 New Revision: 1755

 Modified:
pce/trunk/chrome/content/controls/graph.xml
pce/trunk/chrome/content/controls/model.xml
pce/trunk/chrome/content/ui/MainWindow.js
pce/trunk/chrome/content/util/GraphSupport.js
pce/trunk/chrome/content/util/Metadata.js
pce/trunk/chrome/content/util/ModelURLLoader.js
pce/trunk/chrome/content/util/VariablePath.js
 Log:
 Made some 'alert' messages more meaningful.


 Modified: pce/trunk/chrome/content/controls/graph.xml
 ===
 --- pce/trunk/chrome/content/controls/graph.xml   2007-09-18 05:56:23 UTC 
 (rev 1754)
 +++ pce/trunk/chrome/content/controls/graph.xml   2007-09-18 17:47:09 UTC 
 (rev 1755)
 @@ -267,7 +267,7 @@
const 
 XUL=http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul;;
var tcs = e.element.getElementsByTagNameNS(XUL, treecell);
tcs.item(1).setAttribute(label, m.name);
 -  
 +
   

I agree that lines with only spaces are bad - I will make a note of this 
when we come to writing up our style guidelines.

try
{
  var typeT = ds.GetTarget(first, typeR, true);
 @@ -1531,7 +1531,7 @@
try
{
  this.gcontext.moveTo(xe, y);
 -  } catch (e) { alert(Got problem with xe= + xe +  and y= + y); }
 +  } catch (e) { alert(There is a problem with xe= + xe +  and y= 
 + y + .); }
this.gcontext.lineTo(x, y);
this.gcontext.stroke();
  }

 Modified: pce/trunk/chrome/content/controls/model.xml
 ===
 --- pce/trunk/chrome/content/controls/model.xml   2007-09-18 05:56:23 UTC 
 (rev 1754)
 +++ pce/trunk/chrome/content/controls/model.xml   2007-09-18 17:47:09 UTC 
 (rev 1755)
 @@ -305,12 +305,11 @@
  
  // Now go through the code information, and find initial values to set...
  var ciit = ci.iterateTargets();
 -var v;
  while ((ct = ciit.nextComputationTarget()) != null)
  {
if (ct.degree == 0  ct.type == 2 /* STATE_VARIABLE */)
{
 -var cv = FindElementByPath(MakeVariablePath(ct.variable), m);
 +var cv = FindElementByPath(MakeVariablePath(ct.variable), 
 ct.variable, m);
   

See my comments about the changes to FindElementByPath on VariablePath.js

  cv.initialValue = dc.getRawData(ct.assignedIndex, guess);
}
  }

 Modified: pce/trunk/chrome/content/ui/MainWindow.js
 ===
 --- pce/trunk/chrome/content/ui/MainWindow.js 2007-09-18 05:56:23 UTC (rev 
 1754)
 +++ pce/trunk/chrome/content/ui/MainWindow.js 2007-09-18 17:47:09 UTC (rev 
 1755)
 @@ -65,7 +65,7 @@
window.ccgs =
  cc[@cellml.org/ccgs-bootstrap;1].
  
 getService(ci.cellml_servicesICodeGeneratorBootstrap).createCodeGenerator();
 -  
 +
// Get the CellML Integration Service...
window.cis =
  cc[@cellml.org/cis-bootstrap;1].
 @@ -81,7 +81,7 @@
  }
  catch (e)
  {
 -  alert(Caught exception:  + e);
 +  alert(A problem occurred while registering the different services 
 required by PCEnv:  + e + .);
  }
  }
  
 @@ -142,8 +142,8 @@
  }
  catch (e)
  {
 -  alert(Invalid URL on command line:  + ns.getArgument(i) +  ( +
 -NormaliseInputURL(ns.getArgument(i)) + ):  + e);
 +  alert(An invalid URL was provided to PCEnv:  + ns.getArgument(i) +  
 ( +
 +NormaliseInputURL(ns.getArgument(i)) + ):  + e + .);
   
I have two concerns with the new message:
1) We don't say where the invalid URL came from. This error would 
presumably usually arise when deliberately invoking the program from 
with arguments on the command line, and so the user would be aware that 
they had done this, and it would be good to draw their attention to the 
fact that the URL they passed is invalid.
2) I am not sure about whether we should just write 'PCEnv' in alerts 
like this - we can obviously search for all instances and replace them 
if we ever change the name, although it will make life harder, e.g., for 
someone creating a differently branded fork for inclusion in a 
distribution or for some other purpose. Having a 'branding string' might 
be one way around it, or we could just avoid naming the product in such 
messages since it is probably not necessary here.
  }
}
  

 Modified: pce/trunk/chrome/content/util/GraphSupport.js
 ===
 --- pce/trunk/chrome/content/util/GraphSupport.js 2007-09-18 05:56:23 UTC 
 (rev 1754)
 +++ pce/trunk/chrome/content/util/GraphSupport.js 2007-09-18 17:47:09 UTC 
 (rev 1755)
 @@ -9,6 +9,7 @@
return function()
{
  var idcr = 

[cellml-discussion] Proposal: Standardised CellML real number format

2007-09-18 Thread Andrew Miller
Hi all,

The CellML Specification does not define the format in which real 
numbers will be represented at all (it just says, for initial_value: 
The value of the |initial_value| attribute may be a real number or a 
variable). The MathML specification defines
A real number is presented in decimal notation. Decimal notation 
consists of an optional sign (+ or -) followed by a string of digits 
possibly separated into an integer and a fractional part by a decimal 
point. Some examples are 0.3, 1, and -31.56. If a different |base| is 
specified, then the digits are interpreted as being digits computed to 
that base.

This means that there are no constraints at all on how initial values 
can be represented. It is common practice in current CellML processing 
to use representations in standard notation, using formats like 1E8. 
Therefore, I think that we need to restrict it down to something like 
(in regular expression syntax):

(\-|)[0-9]+(\.[0-9]+|)(E(-|)[0-9]+|e(-|)[0-9]+|)

In other words:
  An optional - , followed by 1 or more digits from 0 to 9, followed by 
an optional decimal point (not a comma or momayyez) followed by an 
optional E or e character with a possible sign and one or more digits 
after it.

Are there any opinions about this? I will re-raise this at the next 
CellML meeting next Wednesday so we can summarise any discussion which 
has occurred on the mailing lists, so please send your comments before then.

Best regards,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


[cellml-discussion] CellML Versioning Strategy

2007-09-18 Thread Andrew Miller
Hi all,

At the break-away session on the versioning strategy for CellML (which 
followed the Auckland CellML meeting today) we discussed the future of 
how we would version CellML, including whether we would put all elements 
for the next version of CellML in a completely different namespace, or 
only the elements that had changed.

A summary of the discussion is up at 
http://www.cellml.org/meeting_minutes/MeetingMinutes19September2007/ 
under Breakaway session on versioning strategy for CellML. Note that 
the participants at the session have not had a chance to correct errors 
in it yet, and it may not yet accurately reflect everyone's view. 
However, it does lay out the options, and so may provide a starting 
point for any suggestions or comments from the community.

Please send and such suggestions or comments to the CellML discussion 
mailing list prior to the 3rd October 2007.

Best regards,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://www.cellml.org/mailman/listinfo/cellml-discussion


  1   2   >