cansas multid - Revision history

Jemian: added some web links

2008-05-09T16:43:04Z

added some web links

← Older revision		Revision as of 16:43, 9 May 2008
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).

Jemian at 16:24, 9 May 2008

2008-05-09T16:24:09Z

← Older revision		Revision as of 16:24, 9 May 2008
Line 1:		Line 1:
	''Note: please keep discussion content on the [[Talk:cansas_multid \| discussion]] page. Your contributions may get moved there anyway.''		''Note: please keep discussion content on the [[Talk:cansas_multid \| discussion]] page. Your contributions may get moved there anyway.''

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

			At this time (May 2008), [[Talk:cansas_multid \| 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 [[cansas1d_documentation \| standard]]
			for saving and communicating one dimensional SAS data using XML.

			= Considerations =

	XML? HDF? Something else?		XML? HDF? Something else?

Jemian: not just XML anymore

2008-05-08T17:29:33Z

not just XML anymore

← Older revision		Revision as of 17:29, 8 May 2008
Line 1:		Line 1:
	''Note: please keep discussion content on the [[Talk:cansas_multid \| discussion]] page. Your contributions may get moved there anyway.''		''Note: please keep discussion content on the [[Talk:cansas_multid \| discussion]] page. Your contributions may get moved there anyway.''

	= ~~XML~~ standard for reduced small-angle scattering data with multi-dimensional data =		= standard for reduced small-angle scattering data with multi-dimensional data =

			XML? HDF? Something else?

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

Jemian: kick-off the multi-dimensional format

2008-05-08T17:20:23Z

kick-off the multi-dimensional format

New page

''Note: please keep discussion content on the [[Talk:cansas_multid | discussion]] page. Your contributions may get moved there anyway.''

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

== 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 a little 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 in XML, rather than create anew, I chose to model the data structures from a popular commercial application.