From p.hunter at auckland.ac.nz Sat Nov 1 02:15:18 2008 From: p.hunter at auckland.ac.nz (Peter Hunter) Date: Sat, 01 Nov 2008 02:15:18 +1300 Subject: [cellml-discussion] Opinion on multiple standards In-Reply-To: <18698.23278.226265.896647@frantic.local> References: <18698.23278.226265.896647@frantic.local> Message-ID: <490B04E6.2040706@auckland.ac.nz> Dear Michael, I agree completely with your views. Our combined challenge now is to try to agree on common metadata standards that suit both SBML and CellML. The meeting in April will be an opportunity to do this. Cheers, Peter Michael Hucka wrote: > AT> P.S. regarding different standards or notation > AT> systems, it will be never irrelevant to have multiple > AT> standards (domination may be mantra of Microsoft), it > AT> gives freedom to choose and that's beauty of open > AT> community based projects. > > What follows is personal opinion, not an official position > on behalf of any group I'm involved with. > > Agreement on single open standards for single domains or > application areas *is* beneficial and a goal to strive for. > An example of this is today's web. Would the web be what it > is today if people had not settled on one set of standards > (HTML for describing pages, HTTP for the protocol)? > Agreement on single standards in single application areas is > what enables practical interoperability in those areas. > (Sure, you can have interoperability even in the face of > multiple standards, but it's a lot more expensive to > implement, and thus not practical in the long run.) > > Note that my claim is specifically about *single* domains. > Multiple standards are definitely needed for non-overlapping > (or mostly non-overlapping) domains or application areas. > > Multiple proposed standards for the same single domain arise > (1) in the early stages when people are still grappling with > understanding their needs on the one hand, and implications > of specific format/notation/whatever choices on the other; > (2) when an established standard is found to be deficient > as a result of experience, evolution, and/or innovation. > For #2, if things have been going well, people will want to > update an existing standard (e.g., version 1->2) rather than > replace it entirely, but in other cases, wholesale > replacement may be called for. > > I hypothesize that when people say "multiple standards are > good in open community projects", it's because people > actually are thinking about multiple application areas, or > an area has not settle on common standards, or people are > dissatisfied with the existing standards. > > People sometimes bring up Microsoft as a counter-example to > single standards. The actual problem is not the adoption of > single standards, it's Microsoft's specific approach, which > involves (i) a single entity making top-down decisions for > its own needs without consultation with other groups, (ii) > not documenting the formats, (iii) changing the formats > roughly every time they update their applications without > prior announcement, and (iv) a belligerent business style. > In other words, people's problem with Microsoft is actually > rooted in Microsoft's lack of an open process. I wager > Microsoft would be viewed much more favorably if they > developed their document formats using a bottom-up community > process. > > In summary, I claim that there are reasons why an area might > end up with multiple proposed standards, but it is false > that having multiple standards is better than using one > standard when a single one can be agreed upon. > > Agreement on a single standard certainly takes a lot of > effort, exploration, and time, on both the technical aspects > of defining the standard and the social aspects of arranging > community buy-in. Sometimes it takes decades before > quiescence is reached on a given topic. But once a > sufficiently good single standard for a given area can be > found, it is far better to stick with it, and spend your > efforts on something else. > > MH > > _______________________________________________ > cellml-discussion mailing list > cellml-discussion at cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion -------------- next part -------------- A non-text attachment was scrubbed... Name: p_hunter.vcf Type: text/x-vcard Size: 376 bytes Desc: not available URL: From cskalesh at gmail.com Tue Nov 4 20:15:41 2008 From: cskalesh at gmail.com (Kalesh Sasidharan) Date: Tue, 4 Nov 2008 16:15:41 +0900 Subject: [cellml-discussion] Problem opening CellML Viewer Message-ID: Dear Sir/Madam, I have some problem opening cellml_viewer.jar file. When I am trying I get the following error: C:\Documents and Settings\Kalesh\Desktop>java -jar cellml_viewer.jar Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/batik/swin g/JSVGScrollPane at com.vme.MainApp.main(MainApp.java:19) Caused by: java.lang.ClassNotFoundException: org.apache.batik.swing.JSVGScrollPa ne at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClassInternal(Unknown Source) ... 1 more Can you please let me know the problem? Regards, Kalesh Sasidharan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dj.cowan at auckland.ac.nz Wed Nov 5 07:49:03 2008 From: dj.cowan at auckland.ac.nz (Dougal Cowan) Date: Wed, 05 Nov 2008 07:49:03 +1300 Subject: [cellml-discussion] Meeting minutes 2008-10-29 Message-ID: <4910991F.7080305@auckland.ac.nz> The minutes from last week's ABI CellML Team meeting are up at: http://www.cellml.org/meeting_minutes/abi-meeting-minutes-2008-10-29 Dougal From j.lawson at auckland.ac.nz Thu Nov 6 14:04:39 2008 From: j.lawson at auckland.ac.nz (James Lawson) Date: Thu, 06 Nov 2008 14:04:39 +1300 Subject: [cellml-discussion] SBML is about to release L2v4 Message-ID: <491242A7.4010608@auckland.ac.nz> Hi all, It looks like SBML is about to release SBML L2v4 From http://sbml.org/Community/Wiki "SBML Level 2 Version 4 will address pending issues logged in the SBML specifications issue tracker . Due to the editor's current work and travel schedules, and the desire to time the release of L2v4 with a release of libSBML that supports it, we are pushing back the release of L2v4 and libSBML to early-mid November 2008." Regards, James -------------- next part -------------- A non-text attachment was scrubbed... Name: j_lawson.vcf Type: text/x-vcard Size: 278 bytes Desc: not available URL: From j.lawson at auckland.ac.nz Thu Nov 6 16:41:37 2008 From: j.lawson at auckland.ac.nz (James Lawson) Date: Thu, 06 Nov 2008 16:41:37 +1300 Subject: [cellml-discussion] new CellML FAQ Message-ID: <49126771.9010004@auckland.ac.nz> Hi all, I'm writing up some questions for the new CellML FAQ. Are there any questions you can think of that you think ought to be answered in the FAQ? The current FAQ is at: http://www.cellml.org/faq It's a little outdated, to say the least. Thanks, James -------------- next part -------------- A non-text attachment was scrubbed... Name: j_lawson.vcf Type: text/x-vcard Size: 278 bytes Desc: not available URL: From alan.garny at dpag.ox.ac.uk Fri Nov 7 02:20:24 2008 From: alan.garny at dpag.ox.ac.uk (Alan Garny) Date: Thu, 6 Nov 2008 13:20:24 -0000 Subject: [cellml-discussion] new CellML FAQ In-Reply-To: <49126771.9010004@auckland.ac.nz> References: <49126771.9010004@auckland.ac.nz> Message-ID: <003301c94012$6d24ff60$476efe20$@garny@dpag.ox.ac.uk> A few from the top of my head: - What is CellML? (i.e. CellML for dummies) - Why should I use CellML? - What is the difference between CellML 1.0 and 1.1? - Are there any CellML tools? (simple link to the CellML tools page?) - How can I use CellML in my modelling environment? (i.e. CellML API; should include a link to some documentation and examples) - From which languages can I use the CellML API? (C++ at the moment, but hopefully Java will come sooner than later) - Where can I find existing CellML models? (link to the CellML repository?) - Cardiac cellular electrophysiology: How can I apply a periodic stimulus to an existing cellular model? Etc. (see http://cor.physiol.ox.ac.uk/Help/index.html?{6F1214C0-0F44-40EA-B998-F76A7A4 E041E}.htm) - Where can I find more about CellML? (link to the specifications?) Alan > -----Original Message----- > From: cellml-discussion-bounces at cellml.org [mailto:cellml-discussion- > bounces at cellml.org] On Behalf Of James Lawson > Sent: 06 November 2008 03:42 > To: CellML Discussion List > Subject: [cellml-discussion] new CellML FAQ > > Hi all, > > I'm writing up some questions for the new CellML FAQ. > > Are there any questions you can think of that you think ought to be > answered in the FAQ? > > The current FAQ is at: http://www.cellml.org/faq > > It's a little outdated, to say the least. > > Thanks, > James From c.lloyd at auckland.ac.nz Fri Nov 7 12:27:15 2008 From: c.lloyd at auckland.ac.nz (Catherine Lloyd) Date: Fri, 7 Nov 2008 12:27:15 +1300 Subject: [cellml-discussion] Community feedback on the new CellML.org wire frames Message-ID: Dear All We have recently been reviewing the content and the structure of the current CellML website, with a view to updating the site in the near future. As part of this process we have put together 3 wire frames: one for the main home page, one as a standard index page, and a third which represents a standard content page. These are attached to this email for your perusal, and we would welcome any comments, feedback, thoughts or ideas. Best wishes Catherine -------------- next part -------------- A non-text attachment was scrubbed... Name: cellml-web-wireframes-20081107.pdf Type: application/pdf Size: 379368 bytes Desc: not available URL: -------------- next part -------------- From jonovik at gmail.com Tue Nov 11 01:50:13 2008 From: jonovik at gmail.com (Jon Olav Vik) Date: Mon, 10 Nov 2008 12:50:13 +0000 (UTC) Subject: [cellml-discussion] Auto-generate HDF5 from CellML? Message-ID: Dear all, I'm considering HDF5 for my storage needs in simulating a CellML model under multiple parameter scenarios. HDF5 is designed for efficient storage, retrieval, navigation and subsetting of huge data sets [1], with annotation [2]. I plan on storing both raw and post-processed data, so that if I detect problems at a higher level, I can go back and look at details and possibly re- run those simulations. David Nickerson described a similar approach in an earlier post [3]. However, setting up the data structure with annotations for physical units and such is quite time-consuming. On the other hand, the CellML representation holds all the required information. It would be very helpful to auto-generate an HDF5 data structure to hold output from simulations of CellML models. Such a tool should be fairly easy to write for someone familiar with both HDF5 and CellML, and would apply to all possible CellML models. I guess it would be overly restrictive to make an output format part of the CellML metadata specification. However, offering a standard output format would save duplication of effort and make it easier to share simulation results for further visualization and analysis. I'd like the opinions of the CellML regulars, in particular whether anything similar has been discussed previously. Best regards, Jon Olav Vik [1] http://www.hdfgroup.org/about/hdf_technologies.html [2] http://www.hdfgroup.org/training/HDFtraining/UsersGuide/MF_Annot.fm1.html [3] http://article.gmane.org/gmane.text.xml.cellml.general/234/match=hdf5 From j.lawson at auckland.ac.nz Tue Nov 11 11:42:28 2008 From: j.lawson at auckland.ac.nz (James Lawson) Date: Tue, 11 Nov 2008 11:42:28 +1300 Subject: [cellml-discussion] Auto-generate HDF5 from CellML? In-Reply-To: References: Message-ID: <4918B8D4.5060403@auckland.ac.nz> Hi Jon Olav, Sounds really interesting - the one reservation I'd have, however, is that HDF5 doesn't appear to be open-source. Cheers, James Jon Olav Vik wrote: > Dear all, > > I'm considering HDF5 for my storage needs in simulating a CellML model under > multiple parameter scenarios. HDF5 is designed for efficient storage, > retrieval, navigation and subsetting of huge data sets [1], with annotation > [2]. I plan on storing both raw and post-processed data, so that if I detect > problems at a higher level, I can go back and look at details and possibly re- > run those simulations. David Nickerson described a similar approach in an > earlier post [3]. > > However, setting up the data structure with annotations for physical units and > such is quite time-consuming. On the other hand, the CellML representation > holds all the required information. It would be very helpful to auto-generate > an HDF5 data structure to hold output from simulations of CellML models. > > Such a tool should be fairly easy to write for someone familiar with both HDF5 > and CellML, and would apply to all possible CellML models. I guess it would be > overly restrictive to make an output format part of the CellML metadata > specification. However, offering a standard output format would save > duplication of effort and make it easier to share simulation results for > further visualization and analysis. > > I'd like the opinions of the CellML regulars, in particular whether anything > similar has been discussed previously. > > Best regards, > Jon Olav Vik > > [1] http://www.hdfgroup.org/about/hdf_technologies.html > [2] http://www.hdfgroup.org/training/HDFtraining/UsersGuide/MF_Annot.fm1.html > [3] http://article.gmane.org/gmane.text.xml.cellml.general/234/match=hdf5 > > > _______________________________________________ > cellml-discussion mailing list > cellml-discussion at cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion > -------------- next part -------------- A non-text attachment was scrubbed... Name: j_lawson.vcf Type: text/x-vcard Size: 278 bytes Desc: not available URL: From heiland at indiana.edu Tue Nov 11 12:10:22 2008 From: heiland at indiana.edu (Randy Heiland) Date: Mon, 10 Nov 2008 18:10:22 -0500 Subject: [cellml-discussion] HDF5 licensing In-Reply-To: References: Message-ID: The claim below surprised me (since I used to know and work with many of the HDF group), so I had a look at the license for HDF5: All rights reserved. Contributors: National Center for Supercomputing Applications (NCSA) at the University of Illinois, Fortner Software, Unidata Program Center (netCDF), The Independent JPEG Group (JPEG), Jean-loup Gailly and Mark Adler (gzip), and Digital Equipment Corporation (DEC). Redistribution and use in source and binary forms, with or without modification, are permitted for any purpose (including commercial purposes) provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions, and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions, and the following disclaimer in the documentation and/or materials provided with the distribution. 3. In addition, redistributions of modified forms of the source or binary code must carry prominent notices stating that the original code was changed and the date of the change. 4. All publications or advertising materials mentioning features or use of this software are asked, but not required, to acknowledge that it was developed by The HDF Group and by the National Center for Supercomputing Applications at the University of Illinois at Urbana- Champaign and credit the contributors. 5. Neither the name of The HDF Group, the name of the University, nor the name of any Contributor may be used to endorse or promote products derived from this software without specific prior written permission from THG, the University, or the Contributor, respectively. ------------------------------- I consider this about as close to open source as it gets and isn't much different that the CellML terms of use: http://www.cellml.org/ terms -Randy On Nov 10, 2008, at 6:00 PM, cellml-discussion-request at cellml.org wrote: > > ------------------------------ > > Message: 2 > Date: Tue, 11 Nov 2008 11:42:28 +1300 > From: James Lawson > Subject: Re: [cellml-discussion] Auto-generate HDF5 from CellML? > To: CellML Discussion List > Message-ID: <4918B8D4.5060403 at auckland.ac.nz> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > Hi Jon Olav, > > Sounds really interesting - the one reservation I'd have, however, is > that HDF5 doesn't appear to be open-source. > > Cheers, > James > > Jon Olav Vik wrote: >> Dear all, >> >> I'm considering HDF5 for my storage needs in simulating a CellML >> model under >> multiple parameter scenarios. HDF5 is designed for efficient storage, >> retrieval, navigation and subsetting of huge data sets [1], with >> annotation >> [2]. I plan on storing both raw and post-processed data, so that >> if I detect >> problems at a higher level, I can go back and look at details and >> possibly re- >> run those simulations. David Nickerson described a similar >> approach in an >> earlier post [3]. >> >> However, setting up the data structure with annotations for >> physical units and >> such is quite time-consuming. On the other hand, the CellML >> representation >> holds all the required information. It would be very helpful to >> auto-generate >> an HDF5 data structure to hold output from simulations of CellML >> models. >> >> Such a tool should be fairly easy to write for someone familiar >> with both HDF5 >> and CellML, and would apply to all possible CellML models. I guess >> it would be >> overly restrictive to make an output format part of the CellML >> metadata >> specification. However, offering a standard output format would save >> duplication of effort and make it easier to share simulation >> results for >> further visualization and analysis. >> >> I'd like the opinions of the CellML regulars, in particular >> whether anything >> similar has been discussed previously. >> >> Best regards, >> Jon Olav Vik >> >> [1] http://www.hdfgroup.org/about/hdf_technologies.html >> [2] http://www.hdfgroup.org/training/HDFtraining/UsersGuide/ >> MF_Annot.fm1.html >> [3] http://article.gmane.org/gmane.text.xml.cellml.general/234/ >> match=hdf5 >> >> >> _______________________________________________ >> cellml-discussion mailing list >> cellml-discussion at cellml.org >> http://www.cellml.org/mailman/listinfo/cellml-discussion >> > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: j_lawson.vcf > Type: text/x-vcard > Size: 278 bytes > Desc: not available > URL: 20081111/ed3ce968/attachment-0001.vcf> > > ------------------------------ > > _______________________________________________ > cellml-discussion mailing list > cellml-discussion at cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion > > > End of cellml-discussion Digest, Vol 52, Issue 5 > ************************************************ From j.lawson at auckland.ac.nz Tue Nov 11 12:57:26 2008 From: j.lawson at auckland.ac.nz (James Lawson) Date: Tue, 11 Nov 2008 12:57:26 +1300 Subject: [cellml-discussion] HDF5 licensing In-Reply-To: References: Message-ID: <4918CA66.8050308@auckland.ac.nz> My apologies - I should have looked a bit harder! Randy Heiland wrote: > The claim below surprised me (since I used to know and work with many > of the HDF group), so I had a look at the license for HDF5: > > All rights reserved. > > Contributors: National Center for Supercomputing Applications (NCSA) > at the University of Illinois, Fortner Software, Unidata Program > Center (netCDF), The Independent JPEG Group (JPEG), Jean-loup Gailly > and Mark Adler (gzip), and Digital Equipment Corporation (DEC). > > Redistribution and use in source and binary forms, with or without > modification, are permitted for any purpose (including commercial > purposes) provided that the following conditions are met: > > 1. Redistributions of source code must retain the above copyright > notice, this list of conditions, and the following disclaimer. > 2. Redistributions in binary form must reproduce the above > copyright notice, this list of conditions, and the following > disclaimer in the documentation and/or materials provided with the > distribution. > 3. In addition, redistributions of modified forms of the source or > binary code must carry prominent notices stating that the original > code was changed and the date of the change. > 4. All publications or advertising materials mentioning features or > use of this software are asked, but not required, to acknowledge that > it was developed by The HDF Group and by the National Center for > Supercomputing Applications at the University of Illinois at > Urbana-Champaign and credit the contributors. > 5. Neither the name of The HDF Group, the name of the University, > nor the name of any Contributor may be used to endorse or promote > products derived from this software without specific prior written > permission from THG, the University, or the Contributor, respectively. > ------------------------------- > > I consider this about as close to open source as it gets and isn't > much different that the CellML terms of use: http://www.cellml.org/terms > > -Randy > > > On Nov 10, 2008, at 6:00 PM, cellml-discussion-request at cellml.org wrote: > >> >> ------------------------------ >> >> Message: 2 >> Date: Tue, 11 Nov 2008 11:42:28 +1300 >> From: James Lawson >> Subject: Re: [cellml-discussion] Auto-generate HDF5 from CellML? >> To: CellML Discussion List >> Message-ID: <4918B8D4.5060403 at auckland.ac.nz> >> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" >> >> Hi Jon Olav, >> >> Sounds really interesting - the one reservation I'd have, however, is >> that HDF5 doesn't appear to be open-source. >> >> Cheers, >> James >> >> Jon Olav Vik wrote: >>> Dear all, >>> >>> I'm considering HDF5 for my storage needs in simulating a CellML >>> model under >>> multiple parameter scenarios. HDF5 is designed for efficient storage, >>> retrieval, navigation and subsetting of huge data sets [1], with >>> annotation >>> [2]. I plan on storing both raw and post-processed data, so that if >>> I detect >>> problems at a higher level, I can go back and look at details and >>> possibly re- >>> run those simulations. David Nickerson described a similar approach >>> in an >>> earlier post [3]. >>> >>> However, setting up the data structure with annotations for physical >>> units and >>> such is quite time-consuming. On the other hand, the CellML >>> representation >>> holds all the required information. It would be very helpful to >>> auto-generate >>> an HDF5 data structure to hold output from simulations of CellML >>> models. >>> >>> Such a tool should be fairly easy to write for someone familiar with >>> both HDF5 >>> and CellML, and would apply to all possible CellML models. I guess >>> it would be >>> overly restrictive to make an output format part of the CellML metadata >>> specification. However, offering a standard output format would save >>> duplication of effort and make it easier to share simulation results >>> for >>> further visualization and analysis. >>> >>> I'd like the opinions of the CellML regulars, in particular whether >>> anything >>> similar has been discussed previously. >>> >>> Best regards, >>> Jon Olav Vik >>> >>> [1] http://www.hdfgroup.org/about/hdf_technologies.html >>> [2] >>> http://www.hdfgroup.org/training/HDFtraining/UsersGuide/MF_Annot.fm1.html >>> >>> [3] >>> http://article.gmane.org/gmane.text.xml.cellml.general/234/match=hdf5 >>> >>> >>> _______________________________________________ >>> cellml-discussion mailing list >>> cellml-discussion at cellml.org >>> http://www.cellml.org/mailman/listinfo/cellml-discussion >>> >> >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: j_lawson.vcf >> Type: text/x-vcard >> Size: 278 bytes >> Desc: not available >> URL: >> >> >> >> ------------------------------ >> >> _______________________________________________ >> cellml-discussion mailing list >> cellml-discussion at cellml.org >> http://www.cellml.org/mailman/listinfo/cellml-discussion >> >> >> End of cellml-discussion Digest, Vol 52, Issue 5 >> ************************************************ > > _______________________________________________ > cellml-discussion mailing list > cellml-discussion at cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion -------------- next part -------------- A non-text attachment was scrubbed... Name: j_lawson.vcf Type: text/x-vcard Size: 278 bytes Desc: not available URL: From dj.cowan at auckland.ac.nz Tue Nov 11 13:56:08 2008 From: dj.cowan at auckland.ac.nz (Dougal Cowan) Date: Tue, 11 Nov 2008 13:56:08 +1300 Subject: [cellml-discussion] Meeting minutes 2008-11-05 Message-ID: <4918D828.80701@auckland.ac.nz> The minutes from last week's ABI CellML Team meeting are up at: http://www.cellml.org/meeting_minutes/abi-meeting-minutes-2008-10-05 Dougal From dj.cowan at auckland.ac.nz Tue Nov 11 13:57:18 2008 From: dj.cowan at auckland.ac.nz (Dougal Cowan) Date: Tue, 11 Nov 2008 13:57:18 +1300 Subject: [cellml-discussion] Meeting minutes 2008-11-05 Message-ID: <4918D86E.9090403@auckland.ac.nz> My apologies; there was an unfortunate mistake in the URL of the last email. The minutes from last week's ABI CellML Team meeting are up at: http://www.cellml.org/meeting_minutes/abi-meeting-minutes-2008-11-05 Dougal _______________________________________________ cellml-discussion mailing list cellml-discussion at cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion From david.nickerson at gmail.com Tue Nov 11 14:06:19 2008 From: david.nickerson at gmail.com (David Nickerson) Date: Tue, 11 Nov 2008 09:06:19 +0800 Subject: [cellml-discussion] Auto-generate HDF5 from CellML? In-Reply-To: <4918B8D4.5060403@auckland.ac.nz> References: <4918B8D4.5060403@auckland.ac.nz> Message-ID: > Sounds really interesting - the one reservation I'd have, however, is that > HDF5 doesn't appear to be open-source. just to note that HDF5 is open source. License available here: ftp://ftp.hdfgroup.org/HDF5/current/src/unpacked/COPYING Andre. > > Cheers, > James > > Jon Olav Vik wrote: >> >> Dear all, >> >> I'm considering HDF5 for my storage needs in simulating a CellML model >> under multiple parameter scenarios. HDF5 is designed for efficient storage, >> retrieval, navigation and subsetting of huge data sets [1], with annotation >> [2]. I plan on storing both raw and post-processed data, so that if I detect >> problems at a higher level, I can go back and look at details and possibly >> re- >> run those simulations. David Nickerson described a similar approach in an >> earlier post [3]. >> >> However, setting up the data structure with annotations for physical units >> and such is quite time-consuming. On the other hand, the CellML >> representation holds all the required information. It would be very helpful >> to auto-generate an HDF5 data structure to hold output from simulations of >> CellML models. >> >> Such a tool should be fairly easy to write for someone familiar with both >> HDF5 and CellML, and would apply to all possible CellML models. I guess it >> would be overly restrictive to make an output format part of the CellML >> metadata specification. However, offering a standard output format would >> save duplication of effort and make it easier to share simulation results >> for further visualization and analysis. >> >> I'd like the opinions of the CellML regulars, in particular whether >> anything similar has been discussed previously. >> >> Best regards, >> Jon Olav Vik >> >> [1] http://www.hdfgroup.org/about/hdf_technologies.html >> [2] >> http://www.hdfgroup.org/training/HDFtraining/UsersGuide/MF_Annot.fm1.html >> [3] http://article.gmane.org/gmane.text.xml.cellml.general/234/match=hdf5 >> >> >> _______________________________________________ >> cellml-discussion mailing list >> cellml-discussion at cellml.org >> http://www.cellml.org/mailman/listinfo/cellml-discussion >> > > > _______________________________________________ > cellml-discussion mailing list > cellml-discussion at cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion > > From david.nickerson at gmail.com Wed Nov 12 23:16:54 2008 From: david.nickerson at gmail.com (David Nickerson) Date: Wed, 12 Nov 2008 18:16:54 +0800 Subject: [cellml-discussion] Auto-generate HDF5 from CellML? In-Reply-To: References: Message-ID: > I'm considering HDF5 for my storage needs in simulating a CellML model under > multiple parameter scenarios. HDF5 is designed for efficient storage, > retrieval, navigation and subsetting of huge data sets [1], with annotation > [2]. I plan on storing both raw and post-processed data, so that if I detect > problems at a higher level, I can go back and look at details and possibly re- > run those simulations. David Nickerson described a similar approach in an > earlier post [3]. > > However, setting up the data structure with annotations for physical units and > such is quite time-consuming. On the other hand, the CellML representation > holds all the required information. It would be very helpful to auto-generate > an HDF5 data structure to hold output from simulations of CellML models. > > Such a tool should be fairly easy to write for someone familiar with both HDF5 > and CellML, and would apply to all possible CellML models. I guess it would be > overly restrictive to make an output format part of the CellML metadata > specification. However, offering a standard output format would save > duplication of effort and make it easier to share simulation results for > further visualization and analysis. > > I'd like the opinions of the CellML regulars, in particular whether anything > similar has been discussed previously. I'm not aware of this coming up for discussion in the past. I certainly agree that there is little point duplicating data from the CellML model, although when using unversioned model documents the link between simulation outputs and input CellML models can become quite tenuous. If you are building up a large collection of simulation data for which you need to maintain a strong link to the input models (which I think you do) you'll probably want to look into such issues quite a bit. This is something PMR2 will address (I hope), although, for use now, revision numbers in a subversion repository would probably be sufficient. As a side note, I am envisioning that in the long term such simulation data would ideally be stored using FieldML (http://www.fieldml.org) which underneath is likely to provide several options for the high performance persistent storage (with HDF5 being one of the options that crops up quite frequently). Unfortunately, I'm unsure what sort of time frame a fieldML based solution might become available... As for generic generation of HDF5 data structures from CellML models, I think this would need some thinking :) Is there a generic way to define a useful HDF5 data structure for any given CellML model? I'm not sure... Do you imagine a tool which for a given CellML model (or perhaps more realistically for a given chunk of CellML simulation metadata) will produce essentially a template HDF5 data group with standardized structure. Then your simulation tool would grab that data group and populate the simulation results. Or would some kind of simulation data storage and retrieval service sitting on top of the CellML API be more what you are after? Then I guess that would allow for different underlying persistent data stores to be utilised... David. From jonovik at gmail.com Thu Nov 13 02:38:46 2008 From: jonovik at gmail.com (Jon Olav Vik) Date: Wed, 12 Nov 2008 13:38:46 +0000 (UTC) Subject: [cellml-discussion] Auto-generate HDF5 from CellML? References: Message-ID: David Nickerson writes: > > I'm considering HDF5 for my storage needs in simulating a CellML model under > > multiple parameter scenarios. HDF5 is designed for efficient storage, > > retrieval, navigation and subsetting of huge data sets [1], with annotation > > [2]. I plan on storing both raw and post-processed data, so that if I detect > > problems at a higher level, I can go back and look at details and possibly re- > > run those simulations. David Nickerson described a similar approach in an > > earlier post [3]. > > > > However, setting up the data structure with annotations for physical units and > > such is quite time-consuming. On the other hand, the CellML representation > > holds all the required information. It would be very helpful to auto- generate > > an HDF5 data structure to hold output from simulations of CellML models. > > > > Such a tool should be fairly easy to write for someone familiar with both HDF5 > > and CellML, and would apply to all possible CellML models. I guess it would be > > overly restrictive to make an output format part of the CellML metadata > > specification. However, offering a standard output format would save > > duplication of effort and make it easier to share simulation results for > > further visualization and analysis. > > > > I'd like the opinions of the CellML regulars, in particular whether anything > > similar has been discussed previously. > > I'm not aware of this coming up for discussion in the past. > > I certainly agree that there is little point duplicating data from the > CellML model, although when using unversioned model documents the link > between simulation outputs and input CellML models can become quite > tenuous. If you are building up a large collection of simulation data > for which you need to maintain a strong link to the input models > (which I think you do) you'll probably want to look into such issues > quite a bit. This is something PMR2 will address (I hope), although, > for use now, revision numbers in a subversion repository would > probably be sufficient. Yes. > As a side note, I am envisioning that in the long term such simulation > data would ideally be stored using FieldML (http://www.fieldml.org) > which underneath is likely to provide several options for the high > performance persistent storage (with HDF5 being one of the options > that crops up quite frequently). Unfortunately, I'm unsure what sort > of time frame a fieldML based solution might become available... To me, HDF5 looks like a fairly round wheel, which I'd be happy to use while FieldML decides whether to invent its own. One feature that would often be useful is parallel writing, for instance for trivially parallel simulation of multiple parameter scenarios, writing results for one scenario without blocking output from the others. HDF5 has this (http:// www.hdfgroup.org/HDF5/PHDF5/) but e.g. the Python interface (www.pytables.org) does not yet support it. > As for generic generation of HDF5 data structures from CellML models, > I think this would need some thinking :) Is there a generic way to > define a useful HDF5 data structure for any given CellML model? I'm > not sure... To my layman's eyes it seems most CellML models are sets of coupled ordinary differential equations, for which it should suffice to save state variables for each time point, a model identifier and parameter values. (Parameter values must be easily searchable, allowing retrieval of results for a given parameter set.) Adding results from post-processing should be left to the end user. Actually, I think writing a HDF5 structure generator could be almost like just adding another output format to the code generator. > Do you imagine a tool which for a given CellML model (or perhaps more > realistically for a given chunk of CellML simulation metadata) will > produce essentially a template HDF5 data group with standardized > structure. Then your simulation tool would grab that data group and > populate the simulation results. Yes! > Or would some kind of simulation data storage and retrieval service > sitting on top of the CellML API be more what you are after? Then I > guess that would allow for different underlying persistent data stores > to be utilised... Yes, though I personally don't feel the need for this at the moment. Best regards, Jon Olav From d.brooks at auckland.ac.nz Thu Nov 13 09:58:51 2008 From: d.brooks at auckland.ac.nz (David Brooks) Date: Thu, 13 Nov 2008 09:58:51 +1300 Subject: [cellml-discussion] Auto-generate HDF5 from CellML? In-Reply-To: References: Message-ID: <491B438B.5050107@auckland.ac.nz> On 13/11/08 2:38 AM, Jon Olav Vik wrote: > David Nickerson writes: > >> As a side note, I am envisioning that in the long term such simulation >> data would ideally be stored using FieldML (http://www.fieldml.org) >> which underneath is likely to provide several options for the high >> performance persistent storage (with HDF5 being one of the options >> that crops up quite frequently). Unfortunately, I'm unsure what sort >> of time frame a fieldML based solution might become available... >> > > To me, HDF5 looks like a fairly round wheel, which I'd be happy to use while > FieldML decides whether to invent its own. > > One feature that would often be useful is parallel writing, for instance for > trivially parallel simulation of multiple parameter scenarios, writing results > for one scenario without blocking output from the others. HDF5 has this (http:// > www.hdfgroup.org/HDF5/PHDF5/) but e.g. the Python interface (www.pytables.org) > does not yet support it. > > Although PyTables provides an easy to use and efficient interface between Python and HDF5 files, it also imposes it's own metadata model on HDF5 files. If a general HDF5 solution, able to be used with PyTables, were to be designed to hold CellML simulation results then the HDF5 structure would have to allow for PyTable specific groups. Another approach would be to specify a generic HDF5 framework for CellML simulations and to implement this layer in C/C++, and then, if using Python, access it via a possible PyCellML wrapper (which could also provide access to the CellML API). Regards, Dave Brooks -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.nickerson at gmail.com Fri Nov 14 19:12:53 2008 From: david.nickerson at gmail.com (David Nickerson) Date: Fri, 14 Nov 2008 14:12:53 +0800 Subject: [cellml-discussion] Auto-generate HDF5 from CellML? In-Reply-To: References: Message-ID: On Wed, Nov 12, 2008 at 9:38 PM, Jon Olav Vik wrote: > David Nickerson writes: >> As for generic generation of HDF5 data structures from CellML models, >> I think this would need some thinking :) Is there a generic way to >> define a useful HDF5 data structure for any given CellML model? I'm >> not sure... > > To my layman's eyes it seems most CellML models are sets of coupled ordinary > differential equations, for which it should suffice to save state variables for > each time point, a model identifier and parameter values. (Parameter values must > be easily searchable, allowing retrieval of results for a given parameter set.) > Adding results from post-processing should be left to the end user. I think the searching should be performed with the CellML models rather than the HDF5 data files. The CellML models containing the various parametrizations of full models will contain a lot more useful data to query. You can then search your model archive for simulation descriptions (model instantiations) that meet certain criteria and can then retrieve the corresponding simulation data from the HDF5 data file. I'm currently not in favour of duplicating parameter values in the HDF5 data groups...but not sure about this yet :) > Actually, I think writing a HDF5 structure generator could be almost like just > adding another output format to the code generator. pretty similar, I think. Certainly something that would be based on the current code generation service... >> Do you imagine a tool which for a given CellML model (or perhaps more >> realistically for a given chunk of CellML simulation metadata) will >> produce essentially a template HDF5 data group with standardized >> structure. Then your simulation tool would grab that data group and >> populate the simulation results. > > Yes! I have added this feature request/suggestion to the tracker (https://tracker.physiomeproject.org/show_bug.cgi?id=1492) to better enable tracking further developments along these lines. Anyone interested in implementing or using such a feature, or simply observing the developments, should add themselves to the CC list for the tracker item. >> Or would some kind of simulation data storage and retrieval service >> sitting on top of the CellML API be more what you are after? Then I >> guess that would allow for different underlying persistent data stores >> to be utilised... > > Yes, though I personally don't feel the need for this at the moment. agreed, although possibly the above could be used as a template to help with a development like this... Andre. From alan.garny at dpag.ox.ac.uk Fri Nov 14 23:29:06 2008 From: alan.garny at dpag.ox.ac.uk (Alan Garny) Date: Fri, 14 Nov 2008 10:29:06 -0000 Subject: [cellml-discussion] Auto-generate HDF5 from CellML? In-Reply-To: References: Message-ID: <001101c94643$d25c3060$77149120$@garny@dpag.ox.ac.uk> > From: cellml-discussion-bounces at cellml.org [mailto:cellml-discussion- > bounces at cellml.org] On Behalf Of David Nickerson > On Wed, Nov 12, 2008 at 9:38 PM, Jon Olav Vik wrote: > > David Nickerson writes: > >> As for generic generation of HDF5 data structures from CellML models, > >> I think this would need some thinking :) Is there a generic way to > >> define a useful HDF5 data structure for any given CellML model? I'm > >> not sure... > > > > To my layman's eyes it seems most CellML models are sets of coupled > ordinary > > differential equations, for which it should suffice to save state > variables for > > each time point, a model identifier and parameter values. (Parameter > values must > > be easily searchable, allowing retrieval of results for a given > parameter set.) > > Adding results from post-processing should be left to the end user. > > I think the searching should be performed with the CellML models > rather than the HDF5 data files. The CellML models containing the > various parametrizations of full models will contain a lot more useful > data to query. You can then search your model archive for simulation > descriptions (model instantiations) that meet certain criteria and can > then retrieve the corresponding simulation data from the HDF5 data > file. I'm currently not in favour of duplicating parameter values in > the HDF5 data groups...but not sure about this yet :) Duplication of information in any form or shape should be prohibited in my view. That's a recipe for disaster at some point down the line. Alan From jonovik at gmail.com Sat Nov 15 20:55:35 2008 From: jonovik at gmail.com (Jon Olav Vik) Date: Sat, 15 Nov 2008 07:55:35 +0000 (UTC) Subject: [cellml-discussion] Auto-generate HDF5 from CellML? References: <23721.7624825009$1226658676@news.gmane.org> Message-ID: Alan Garny writes: > > From: cellml-discussion-bounces at ... [mailto:cellml-discussion- > > bounces at ...] On Behalf Of David Nickerson > > On Wed, Nov 12, 2008 at 9:38 PM, Jon Olav Vik wrote: > > > David Nickerson writes: > > >> As for generic generation of HDF5 data structures from CellML models, > > >> I think this would need some thinking :) Is there a generic way to > > >> define a useful HDF5 data structure for any given CellML model? I'm > > >> not sure... > > > > > > To my layman's eyes it seems most CellML models are sets of coupled > > ordinary > > > differential equations, for which it should suffice to save state > > variables for > > > each time point, a model identifier and parameter values. (Parameter > > values must > > > be easily searchable, allowing retrieval of results for a given > > parameter set.) > > > Adding results from post-processing should be left to the end user. > > > > I think the searching should be performed with the CellML models > > rather than the HDF5 data files. The CellML models containing the > > various parametrizations of full models will contain a lot more useful > > data to query. You can then search your model archive for simulation > > descriptions (model instantiations) that meet certain criteria and can > > then retrieve the corresponding simulation data from the HDF5 data > > file. I'm currently not in favour of duplicating parameter values in > > the HDF5 data groups...but not sure about this yet :) > > Duplication of information in any form or shape should be prohibited in my > view. That's a recipe for disaster at some point down the line. Yes, but there needs to be *some* way of identifying the information in the HDF5 file, like "using parameter values as indexes". A purist solution might be to have each simulation result annotated with the URI for that particular parameter set and model. However, any analysis would then require running back and forth between the CellML model (DOM API, metadata, ...) and the huge output files (e.g. HDF5). Until the CellML tools (DOM, code generation, ...) fit seamlessly into more mainstream tools, I'd prefer not to lug around the CellML DOM API everywhere I take my data. (No offense. 8-) I was thinking of this extra annotation as "write once, read many", just labelling the boxes. There exist external tools for exploring HDF5 files, http://www.hdfgroup.org/hdf-java-html/hdfview/ and these will be a lot less useful if the data structure doesn't indicate which parameters a result is for. (That said, it might be useful to verify the integrity of the link between model, parameters and output e.g. by some kind of hashing.) Best regards, Jon Olav From david.nickerson at gmail.com Sat Nov 15 21:49:07 2008 From: david.nickerson at gmail.com (David Nickerson) Date: Sat, 15 Nov 2008 16:49:07 +0800 Subject: [cellml-discussion] Auto-generate HDF5 from CellML? In-Reply-To: References: <23721.7624825009$1226658676@news.gmane.org> Message-ID: On Sat, Nov 15, 2008 at 3:55 PM, Jon Olav Vik wrote: > Alan Garny writes: >> > I think the searching should be performed with the CellML models >> > rather than the HDF5 data files. The CellML models containing the >> > various parametrizations of full models will contain a lot more useful >> > data to query. You can then search your model archive for simulation >> > descriptions (model instantiations) that meet certain criteria and can >> > then retrieve the corresponding simulation data from the HDF5 data >> > file. I'm currently not in favour of duplicating parameter values in >> > the HDF5 data groups...but not sure about this yet :) >> >> Duplication of information in any form or shape should be prohibited in my >> view. That's a recipe for disaster at some point down the line. > > Yes, but there needs to be *some* way of identifying the information in the > HDF5 file, like "using parameter values as indexes". A purist solution might be > to have each simulation result annotated with the URI for that particular > parameter set and model. However, any analysis would then require running back > and forth between the CellML model (DOM API, metadata, ...) and the huge output > files (e.g. HDF5). Until the CellML tools (DOM, code generation, ...) fit > seamlessly into more mainstream tools, I'd prefer not to lug around the CellML > DOM API everywhere I take my data. (No offense. 8-) but doesn't this get back to the issue of needing all the information like units in the HDF5 data file also? If you'd prefer to have an HDF5 data file that can be unambiguously interpreted without reference to the source CellML models and/or simulations, then that is a whole lot more data that would need to be in the data file.... if you want to interpret the data in the file without needing to go back and forth with the CellML models then I'd guess you probably want to add some tool-specific data to the HDF5 group that gets generated by the proposed tool/service...or not. Maybe the below has convinced me that this could be done in a nice way... > I was thinking of this extra annotation as "write once, read many", just > labelling the boxes. There exist external tools for exploring HDF5 files, > http://www.hdfgroup.org/hdf-java-html/hdfview/ > and these will be a lot less useful if the data structure doesn't indicate > which parameters a result is for. (That said, it might be useful to verify the > integrity of the link between model, parameters and output e.g. by some kind of > hashing.) This sounds more like you are after a complete translation of the source models and simulations into HDF5. For a given model you'd have a list of all the "unique" variables in the model annotated with a string containing the full expansion of the variable's units into the set of base units, and the variable's value field - which would be a scalar for constant parameters and an array for dynamic variables. I guess you'd also want some kind of reference to the index field (i.e., time). Not sure if you'd also want to keep track of all the actual variables in the model that are used for each of the unique variables in the simulation instantiation, but that could be done. In such a tool you'd still lose a lot of the annotation in the source CellML models. But I guess if you simply want an optimised data store the above should give you everything you need and if required in special cases you can also link back to the CellML models as there should still be some URI's stored somewhere in the HDF5 data file. Of course, if you want to do all this nice and quickly you'd likely ignore the units anyway if you know that all your simulations are in compatible or identical units so they can be left back in the CellML model and can be looked up if needed. One consideration with such a solution is that I have found the HDF5 packet table interface to be about the most efficient way to stream simulation data to a persistent store. I have one packet table per simulation and use the model variable URI's to set up a mapping into that packet table for each dynamic variable. So rather than using the variable field of dynamic variables for an array, it is probably more efficient to set it up as an index or something into the packet table....sounds like it should be workable :) Andre. From jonovik at gmail.com Sun Nov 16 10:25:44 2008 From: jonovik at gmail.com (Jon Olav Vik) Date: Sat, 15 Nov 2008 21:25:44 +0000 (UTC) Subject: [cellml-discussion] Auto-generate HDF5 from CellML? References: <23721.7624825009$1226658676@news.gmane.org> Message-ID: David Nickerson writes: > On Sat, Nov 15, 2008 at 3:55 PM, Jon Olav Vik wrote: [snip] > > Yes, but there needs to be *some* way of identifying the information in the > > HDF5 file, like "using parameter values as indexes". A purist solution might be > > to have each simulation result annotated with the URI for that particular > > parameter set and model. However, any analysis would then require running back > > and forth between the CellML model (DOM API, metadata, ...) and the huge output > > files (e.g. HDF5). Until the CellML tools (DOM, code generation, ...) fit > > seamlessly into more mainstream tools, I'd prefer not to lug around the CellML > > DOM API everywhere I take my data. (No offense. > > but doesn't this get back to the issue of needing all the information > like units in the HDF5 data file also? First of all, thanks for a very constructive answer. > If you'd prefer to have an HDF5 > data file that can be unambiguously interpreted without reference to > the source CellML models and/or simulations, No, that's not what I meant. The *required* information in the HDF5 file would be something like: a) unambiguous identification of model b) unambiguous specification of parameter values c) unambiguous identification of output variables For a), the URI to the model should be an ideal "canonical" reference (but I'd still appreciate a human-readable, (autogenerated) text-formatted reference as annotation). For b), the URI to a CellML simulation spec might be an ideal canonical reference. For c), I guess the HDF5 array names should simply be the variable names from the CellML model. > then that is a whole lot > more data that would need to be in the data file.... I do intend for the HDF5 file to be interpreted in conjunction with the CellML model. However, things like a human-readable citation in addition to the URI would be *convenient*, as would a copy of the parameter values used in the simulation. Regarding redundancy, it would be understood that the *official* parameter values were those in the CellML simulation specification. Consistency could be verified automatically (e.g. by a CRC checksum) whenever desired. It would be an error to change those parameter values after that part of the HDF5 structure was begun. Regarding storage space, the 180 kB required for e.g. the Bondarenko model are negligible compared to the megabytes of output for even a modest exploration of parameter combinations. > if you want to interpret the data in the file without needing to go > back and forth with the CellML models then I'd guess you probably want > to add some tool-specific data to the HDF5 group that gets generated > by the proposed tool/service...or not. Yes, that's about what I had in mind. Similar in some ways to the various tabs on the repository webpages of cellml.org, or the autogenerated code in different programming languages: Certainly redundant, but convenient. > Maybe the below has convinced > me that this could be done in a nice way... > > > I was thinking of this extra annotation as "write once, read many", just > > labelling the boxes. There exist external tools for exploring HDF5 files, > > http://www.hdfgroup.org/hdf-java-html/hdfview/ > > and these will be a lot less useful if the data structure doesn't indicate > > which parameters a result is for. (That said, it might be useful to verify the > > integrity of the link between model, parameters and output e.g. by some kind of > > hashing.) > > This sounds more like you are after a complete translation of the > source models and simulations into HDF5. I don't know about "into" HDF5; that's just a vehicle for storing numbers, has no concept of mathematical functions, etc. (...and I know that you know this better than I do 8-) I'm just after human-readable annotation to aid in navigation and exploration of the data. (Well, maybe some machine-readable annotation too; units would be nice to give meaning to the numbers.) > For a given model you'd have > a list of all the "unique" variables in the model annotated with a > string containing the full expansion of the variable's units into the > set of base units, and the variable's value field - which would be a > scalar for constant parameters and an array for dynamic variables. I > guess you'd also want some kind of reference to the index field (i.e., > time). Not sure if you'd also want to keep track of all the actual > variables in the model that are used for each of the unique variables > in the simulation instantiation, but that could be done. > > In such a tool you'd still lose a lot of the annotation in the source > CellML models. But I guess if you simply want an optimised data store > the above should give you everything you need and if required in > special cases you can also link back to the CellML models as there > should still be some URI's stored somewhere in the HDF5 data file. Of > course, if you want to do all this nice and quickly you'd likely > ignore the units anyway if you know that all your simulations are in > compatible or identical units so they can be left back in the CellML > model and can be looked up if needed. To me this sounds very promising. I'd be interested to hear what others think. > One consideration with such a solution is that I have found the HDF5 > packet table interface to be about the most efficient way to stream > simulation data to a persistent store. I have one packet table per > simulation and use the model variable URI's to set up a mapping into > that packet table for each dynamic variable. So rather than using the > variable field of dynamic variables for an array, it is probably more > efficient to set it up as an index or something into the packet > table....sounds like it should be workable :) I must admit I do not yet know what a "packet table" is. I think it might be very helpful if you could write up a toy example of how you currently use HDF5 with CellML models. [As for myself and my short-term hacks, I'm currently leaning towards Numpy ndarrays or recarrays (allowing reference to array "columns" by name) stored in HDF5 via pytables. http://thread.gmane.org/gmane.comp.python.numeric.general/22250/ ] Best regards, Jon Olav From r.britten at auckland.ac.nz Tue Nov 18 10:12:41 2008 From: r.britten at auckland.ac.nz (Randall Britten) Date: Tue, 18 Nov 2008 10:12:41 +1300 Subject: [cellml-discussion] 15 minute outage at 11:45pm NZDT Tue 18 Nov Message-ID: <003901c948f9$3a15bed0$ae413c70$@britten@auckland.ac.nz> Hi Some sites used by the CellML project will be unavailable for a short period due to maintenance, these include: www.cellml.org tracker.physiomeproject.org svnviewer.physiomeproject.org Regards, Randall -------------- next part -------------- An HTML attachment was scrubbed... URL: From dj.cowan at auckland.ac.nz Tue Nov 18 10:37:40 2008 From: dj.cowan at auckland.ac.nz (Dougal Cowan) Date: Tue, 18 Nov 2008 10:37:40 +1300 Subject: [cellml-discussion] Meeting minutes 2008-11-12 Message-ID: <4921E424.2050503@auckland.ac.nz> The minutes from last week's ABI CellML Team meeting are up at: http://www.cellml.org/meeting_minutes/abi-meeting-minutes-2008-11-12 Dougal From david.nickerson at gmail.com Wed Nov 19 23:12:51 2008 From: david.nickerson at gmail.com (David Nickerson) Date: Wed, 19 Nov 2008 18:12:51 +0800 Subject: [cellml-discussion] Auto-generate HDF5 from CellML? In-Reply-To: References: Message-ID: > I'm considering HDF5 for my storage needs in simulating a CellML model under > multiple parameter scenarios. HDF5 is designed for efficient storage, > retrieval, navigation and subsetting of huge data sets [1], with annotation > [2]. > [2] http://www.hdfgroup.org/training/HDFtraining/UsersGuide/MF_Annot.fm1.html this has been confusing me for a while, until I just realised that the link [2] actually refers to a HDF4 user guide. So without looking too far into it, I'm guessing that maybe object attributes in HDF5 (http://www.hdfgroup.org/HDF5/doc/H5.intro.html#Intro-OAttributes) have replaced the types of annotations discussed in [2]. Can anyone confirm this? or suggest an alternative method to annotate specific data objects in HDF5? Thanks, Andre. From jonovik at gmail.com Thu Nov 20 02:26:30 2008 From: jonovik at gmail.com (Jon Olav Vik) Date: Wed, 19 Nov 2008 13:26:30 +0000 (UTC) Subject: [cellml-discussion] Auto-generate HDF5 from CellML? References: Message-ID: David Nickerson writes: > > > I'm considering HDF5 for my storage needs in simulating a CellML model under > > multiple parameter scenarios. HDF5 is designed for efficient storage, > > retrieval, navigation and subsetting of huge data sets [1], with annotation > > [2]. > > > [2] http://www.hdfgroup.org/training/HDFtraining/UsersGuide/ MF_Annot.fm1.html > > this has been confusing me for a while, until I just realised that the > link [2] actually refers to a HDF4 user guide. > > So without looking too far into it, I'm guessing that maybe object > attributes in HDF5 > (http://www.hdfgroup.org/HDF5/doc/H5.intro.html#Intro-OAttributes) > have replaced the types of annotations discussed in [2]. Can anyone > confirm this? or suggest an alternative method to annotate specific > data objects in HDF5? Ah, thanks for the information. It seems your guess is correct: "In HDF5 attributes are used instead of annotations." http://www.hdfgroup.org/h5h4-diff.html Jon Olav From dj.cowan at auckland.ac.nz Tue Nov 25 09:56:46 2008 From: dj.cowan at auckland.ac.nz (Dougal Cowan) Date: Tue, 25 Nov 2008 09:56:46 +1300 Subject: [cellml-discussion] Meeting minutes 2008-11-19 Message-ID: <492B150E.3050403@auckland.ac.nz> The minutes from last week's ABI CellML Team meeting are up at: http://www.cellml.org/meeting_minutes/abi-meeting-minutes-2008-11-19 Dougal From alan.garny at dpag.ox.ac.uk Thu Nov 27 02:25:30 2008 From: alan.garny at dpag.ox.ac.uk (Alan Garny) Date: Wed, 26 Nov 2008 13:25:30 -0000 Subject: [cellml-discussion] Meeting minutes 2008-11-19 In-Reply-To: <492B150E.3050403@auckland.ac.nz> References: <492B150E.3050403@auckland.ac.nz> Message-ID: <003401c94fca$74062e40$5c128ac0$@garny@dpag.ox.ac.uk> Hi, I was wondering whether the minutes could be announced sooner? I understand that they need to be approved, but still I would expect them to be announced within 24 hours. If we look at last week's meeting, I received notice of the minutes on Monday evening (i.e. Tuesday morning NZ time), i.e. one day before you guys have your weekly CellML meeting (!!). Most importantly (maybe) is that, while reading the minutes, I could relate to issues (reported in the minutes) that had been acted upon since last week's meeting. This is obviously good, but those issues kind of came out of the blue at the time. It would have been nice if I didn't have to put 2 and 2 together, try to read people's mind behind their actions, etc. Also, to know about the outcome of the meeting within 24 hours would potentially allow people to react more efficiently (i.e. in 'real-time'). Cheers, Alan. PS: it's not a recent occurrence, since it has been going on for months. In a couple of cases, it even happened that the minutes were not announced. So, no, nothing to do with the person who currently produces the minutes... :) > -----Original Message----- > From: cellml-discussion-bounces at cellml.org [mailto:cellml-discussion- > bounces at cellml.org] On Behalf Of Dougal Cowan > Sent: 24 November 2008 20:57 > To: cellml-discussion at cellml.org > Subject: [cellml-discussion] Meeting minutes 2008-11-19 > > The minutes from last week's ABI CellML Team meeting are up at: > > http://www.cellml.org/meeting_minutes/abi-meeting-minutes-2008-11-19 > > Dougal > _______________________________________________ > cellml-discussion mailing list > cellml-discussion at cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion From j.lawson at auckland.ac.nz Thu Nov 27 10:17:44 2008 From: j.lawson at auckland.ac.nz (James Lawson) Date: Thu, 27 Nov 2008 10:17:44 +1300 Subject: [cellml-discussion] Meeting minutes 2008-11-19 In-Reply-To: <003401c94fca$74062e40$5c128ac0$@garny@dpag.ox.ac.uk> References: <492B150E.3050403@auckland.ac.nz> <003401c94fca$74062e40$5c128ac0$@garny@dpag.ox.ac.uk> Message-ID: <492DBCF8.7050302@auckland.ac.nz> Hi Alan, The way we currently do it is the minuter writes up the minutes and releases them to the people who were present at the meeting for corrections. The full, revised minutes are then made public, usually several days later. Unfortunately we had a powercut yesterday and Dougal lost all his minutes, since plone doesn't make regular saves :( I definitely understand where you're coming from. We've talked quite a bit about how the minutes from the Auckland meeting should be done, and we've come to the conclusion that we're a bit limited by technology at the moment, since our plone site doesn't record change logs for documents properly. Would everyone prefer a more rapid, but subject to change, release of the minutes? Thanks, James Alan Garny wrote: > Hi, > > I was wondering whether the minutes could be announced sooner? I understand > that they need to be approved, but still I would expect them to be announced > within 24 hours. If we look at last week's meeting, I received notice of the > minutes on Monday evening (i.e. Tuesday morning NZ time), i.e. one day > before you guys have your weekly CellML meeting (!!). > > Most importantly (maybe) is that, while reading the minutes, I could relate > to issues (reported in the minutes) that had been acted upon since last > week's meeting. This is obviously good, but those issues kind of came out of > the blue at the time. It would have been nice if I didn't have to put 2 and > 2 together, try to read people's mind behind their actions, etc. > > Also, to know about the outcome of the meeting within 24 hours would > potentially allow people to react more efficiently (i.e. in 'real-time'). > > Cheers, Alan. > > PS: it's not a recent occurrence, since it has been going on for months. In > a couple of cases, it even happened that the minutes were not announced. So, > no, nothing to do with the person who currently produces the minutes... :) > > >> -----Original Message----- >> From: cellml-discussion-bounces at cellml.org [mailto:cellml-discussion- >> bounces at cellml.org] On Behalf Of Dougal Cowan >> Sent: 24 November 2008 20:57 >> To: cellml-discussion at cellml.org >> Subject: [cellml-discussion] Meeting minutes 2008-11-19 >> >> The minutes from last week's ABI CellML Team meeting are up at: >> >> http://www.cellml.org/meeting_minutes/abi-meeting-minutes-2008-11-19 >> >> Dougal >> _______________________________________________ >> cellml-discussion mailing list >> cellml-discussion at cellml.org >> http://www.cellml.org/mailman/listinfo/cellml-discussion >> > > _______________________________________________ > cellml-discussion mailing list > cellml-discussion at cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion > -------------- next part -------------- A non-text attachment was scrubbed... Name: j_lawson.vcf Type: text/x-vcard Size: 278 bytes Desc: not available URL: From dj.cowan at auckland.ac.nz Fri Nov 28 15:38:58 2008 From: dj.cowan at auckland.ac.nz (Dougal Cowan) Date: Fri, 28 Nov 2008 15:38:58 +1300 Subject: [cellml-discussion] Meeting minutes 2008-11-26 Message-ID: <20081128153858.8quzht4j4oocg0ok@webmail.bioeng.auckland.ac.nz> The minutes from last week's ABI CellML Team meeting are up at: http://www.cellml.org/meeting_minutes/abi-meeting-minutes-2008-11-26 Dougal ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.