cansas multid: Difference between revisions

From canSAS
No edit summary
m (added some web links)
 
Line 13: Line 13:
= Considerations =
= Considerations =


XML?  HDF? Something else?
[http://en.wikipedia.org/wiki/XML XML]?   
[http://hdf.ncsa.uiuc.edu/ HDF]?
[http://www.nexusformat.org NeXus]?
Something else?


== Key Points so far ==
== Key Points so far ==


* with the 1D format agreed, we should look at 2D data
* with the 1D format agreed, we should look at 2D data
* we should also consider how different we are from NeXus and then why
* we should also consider how different we are from [http://www.nexusformat.org NeXus] and then why
* We must address data beyond simple 2D detector patterns (multi-dimensional data)
* We must address data beyond simple 2D detector patterns (multi-dimensional data)
** kinetic/time-resolved stuff (frames, periods, whatever you call them),  
** kinetic/time-resolved stuff (frames, periods, whatever you call them),  
** other experiments where data is being collected as a function of some variable (temperature, pH, or whatever)
** other experiments where data is being collected as a function of some variable (temperature, pH, or whatever)
* quite happy to abandon human-readability ... even prepared to consider binary storage!
* quite happy to abandon human-readability ... even prepared to consider binary storage!
* We have benefited a little from [the NeXus] instrument dictionary.
* We have benefited from the [http://www.nexusformat.org/Instruments NeXus instrument dictionary].
* The time is now ripe to show the use of HDF for storing multi-dimensional data, only using pure HDF5.
* The time is now ripe to show the use of [http://hdf.ncsa.uiuc.edu/ HDF] for storing multi-dimensional data, only using pure HDF5.
* Regarding the cansas1d/1.0 XML format:
* Regarding the [[cansas1d_documentation | cansas1d/1.0 XML format]]:
** table structure used in the 1D format is quite 'tag-heavy' and just will not extend easily.  
** table structure used in the 1D format is quite 'tag-heavy' and just will not extend easily.  
** takes a little bit more work to extract the I(Q) data into vectors for use in processing or analysis software.
** takes a little bit more work to extract the I(Q) data into vectors for use in processing or analysis software.
* For multi-dimensional data in XML, rather than create anew, I chose to model the data structures from a popular commercial application.
* For multi-dimensional data, rather than create anew, chose to model the data structures based on the structures in popular use (such as a popular commercial application).

Latest revision as of 16:43, 9 May 2008

Note: please keep discussion content on the discussion page. Your contributions may get moved there anyway.

standard for reduced multi-dimensional small-angle scattering data with multi-dimensional

At this time (May 2008), discussion of the standard is just starting. These pages are being used to gather the considerations for a proposed standard for saving and communicating reduced multi-dimensional small-angle scattering data. The standard will also describe how to save and communicate the results of processing or analysis steps, as does the recently established standard for saving and communicating one dimensional SAS data using XML.

Considerations

XML? HDF? NeXus? Something else?

Key Points so far

  • with the 1D format agreed, we should look at 2D data
  • we should also consider how different we are from NeXus and then why
  • We must address data beyond simple 2D detector patterns (multi-dimensional data)
    • kinetic/time-resolved stuff (frames, periods, whatever you call them),
    • other experiments where data is being collected as a function of some variable (temperature, pH, or whatever)
  • quite happy to abandon human-readability ... even prepared to consider binary storage!
  • We have benefited from the NeXus instrument dictionary.
  • The time is now ripe to show the use of HDF for storing multi-dimensional data, only using pure HDF5.
  • Regarding the cansas1d/1.0 XML format:
    • table structure used in the 1D format is quite 'tag-heavy' and just will not extend easily.
    • takes a little bit more work to extract the I(Q) data into vectors for use in processing or analysis software.
  • For multi-dimensional data, rather than create anew, chose to model the data structures based on the structures in popular use (such as a popular commercial application).