Alan Garny <[EMAIL PROTECTED]> writes: > > From: [EMAIL PROTECTED] [mailto:cellml-discussion- > > [EMAIL PROTECTED] On Behalf Of David Nickerson > > On Wed, Nov 12, 2008 at 9:38 PM, Jon Olav Vik <[EMAIL PROTECTED]> wrote: > > > David Nickerson <[EMAIL PROTECTED]> 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 _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
