2012 Data Discussion - Revision history

Smk: /* Agree resultant changes to the "official" schema/stylesheet */

2012-08-06T14:52:32Z

Agree resultant changes to the "official" schema/stylesheet

← Older revision		Revision as of 14:52, 6 August 2012
Line 158:		Line 158:
	}}		}}
	{{Comment \| ARJN \| Just as a matter of interest, why is it necessary to include transmission measurements for TOF instruments? Does the analysis depend on these values? Not saying it's not necessary, just wondering about why it is useful.		{{Comment \| ARJN \| Just as a matter of interest, why is it necessary to include transmission measurements for TOF instruments? Does the analysis depend on these values? Not saying it's not necessary, just wondering about why it is useful.
			}}
			{{Comment \| SMK \| Why do we already make provision to include the transmission value from a fixed-wavelength measurement?! First, they are an extremely value diagnostic tool for users and instrument scientists alike. Second, if you are going to provide the values you might as well do it in a way that keeps them with the data they produced and reduce the number of files the users have to take away. And, third, if you are seriously going to address resolution and multiple scattering issues as part of your analysis you will need the transmission data.
	}}		}}

Ajj: /* Actions for after meeting */

2012-07-31T13:24:52Z

Actions for after meeting

← Older revision		Revision as of 13:24, 31 July 2012
Line 2:		Line 2:

	[[2012 Data Working Group Report\|Data Working Group Report]]		[[2012 Data Working Group Report\|Data Working Group Report]]

	~~== Actions for after meeting ==~~

	* Report
	** AJJ will write 1st draft for circulation
	* Real data examples
	** AJJ will enter some real data using TSR's python code
	* Documentation
	** PRJ and AJJ
	* Updated abstract for SAS 2012
	** TSR?
	* Contacting possible implementers.
	** ALL?

	= Minutes =		= Minutes =

Ajj: /* Report */

2012-07-31T13:13:13Z

Report

← Older revision		Revision as of 13:13, 31 July 2012
Line 2:		Line 2:

	[[2012 Data Working Group Report\|Data Working Group Report]]		[[2012 Data Working Group Report\|Data Working Group Report]]

			== Actions for after meeting ==

			* Report
			** AJJ will write 1st draft for circulation
			* Real data examples
			** AJJ will enter some real data using TSR's python code
			* Documentation
			** PRJ and AJJ
			* Updated abstract for SAS 2012
			** TSR?
			* Contacting possible implementers.
			** ALL?

	= Minutes =		= Minutes =

Ajj at 08:56, 31 July 2012

2012-07-31T08:56:03Z

← Older revision		Revision as of 08:56, 31 July 2012
Line 1:		Line 1:
			= Report =

			[[2012 Data Working Group Report\|Data Working Group Report]]

	= Minutes =		= Minutes =

Jemian: /* Monday Morning Plenary Session */

2012-07-31T08:35:22Z

Monday Morning Plenary Session

← Older revision		Revision as of 08:35, 31 July 2012
Line 58:		Line 58:
	** SANSview (NIST) - agreed to work with us		** SANSview (NIST) - agreed to work with us
	** Irena (APS) - agreed to work with us		** Irena (APS) - agreed to work with us
	** Mantid (ISIS) -		** Mantid (ISIS) - we will ask Mathieu Doucet
	** ImageJ plugins - ?		** ImageJ plugins - Andrew Jackson will investigate

	*show how one might describe voxel size or boundaries		*show how one might describe voxel size or boundaries
	**There various ways to do this.		**There various ways to do this.
	**Uncertainty, resolution and dimension are different.		**Uncertainty, resolution and dimension are different.


	== Monday Afternoon Working Group Session ==		== Monday Afternoon Working Group Session ==

Jemian: Tuesday is now

2012-07-31T08:09:20Z

Tuesday is now

@@ Line 117: / Line 117: @@
           @basis="esd"
 </pre>
 = Agenda with Discussion =

Jemian: Monday morning session comments

2012-07-31T07:45:40Z

Monday morning session comments

← Older revision		Revision as of 07:45, 31 July 2012
Line 42:		Line 42:

	See: [[2012_Data_Discussion_Examples]]		See: [[2012_Data_Discussion_Examples]]



			== Monday Morning Plenary Session ==

			These are rough notes collected from the morning plenary session.

			* work with multi-D data in Q space and other terms such as t, T, P, and ...

			* How might this standard be used?
			** Are there muti-technique analysis tools that can do simultaneous analysis?
			** Deposition format?

			*identify specific producers and consumers for standardization, especially high-volume:
			** SANSview (NIST) - agreed to work with us
			** Irena (APS) - agreed to work with us
			** Mantid (ISIS) -
			** ImageJ plugins - ?

			*show how one might describe voxel size or boundaries
			**There various ways to do this.
			**Uncertainty, resolution and dimension are different.


	== Monday Afternoon Working Group Session ==		== Monday Afternoon Working Group Session ==

Jemian: /* Monday Afternoon Working Group Session */

2012-07-30T15:54:53Z

Monday Afternoon Working Group Session

← Older revision		Revision as of 15:54, 30 July 2012
Line 86:		Line 86:
	dI : float[nI]		dI : float[nI]
	@components="I_uncertainties"		@components="I_uncertainties"
	I_uncertainties		I_uncertainties:
	electronic : float[nI]		electronic : float[nI]
	@basis="Johnson noise"		@basis="Johnson noise"

Jemian: uncertainties

2012-07-30T15:51:18Z

uncertainties

@@ Line 68: / Line 68: @@
 *** TOF-SANS may need its own parameters
 *** Can we define a numerical function to be applied?  (represent this function as numerical data)
-* Data objects for I and Q may also indicate the uncertainty.  The uncertainty is provided as another data object, the name of which is provided as an attribute to its parent, such as shown by Andy Nelson's reflectometry example.  The shape of the uncertainty and its parent will be the same.  Uncertainty will be represented as standard deviation unless specified otherwise.
+* Data objects for I and Q may also indicate the uncertainty.  The uncertainty is provided as another data object, the name of which is provided as an attribute to its parent, such as shown by Andy Nelson's reflectometry example.  The shape of the uncertainty and its parent will be the same.  Uncertainty will be represented as estimate of standard deviation unless specified otherwise.
 * Data objects for Q may indicate the volume of the element.  Like the uncertainty above, the volume is provided as other data object or objects, the name of which is provided as an attribute to its parent.  The shape of the volume is not necessarily the same as its parent.
 * For some representations of I, it may be necessary to represent the effect of a mask (to ignore this datum).  The method is yet to be determined.
@@ Line 77: / Line 80: @@
 ** If we allow for an array to define the ''mask'', then we must relax the rule just described. '''We'll choose this.'''  Value of 1 means keep this datum, value of 0 means remove this datum.
 ** What is the shape (rank and dimensions) of the ''mask''?  Describe through the use of '''mask_indices''' (as for Q and I).  This means that the mask does not require the same shape as either Q or I.
 = Agenda with Discussion =

Jemian: /* Monday Afternoon Working Group Session */

2012-07-30T14:21:33Z

Monday Afternoon Working Group Session

← Older revision		Revision as of 14:21, 30 July 2012
Line 71:		Line 71:
	* Data objects for Q may indicate the volume of the element. Like the uncertainty above, the volume is provided as other data object or objects, the name of which is provided as an attribute to its parent. The shape of the volume is not necessarily the same as its parent.		* Data objects for Q may indicate the volume of the element. Like the uncertainty above, the volume is provided as other data object or objects, the name of which is provided as an attribute to its parent. The shape of the volume is not necessarily the same as its parent.
	* For some representations of I, it may be necessary to represent the effect of a mask (to ignore this datum). The method is yet to be determined.		* For some representations of I, it may be necessary to represent the effect of a mask (to ignore this datum). The method is yet to be determined.
			** Here is an example mask: [[File:2012cansas-example-mask.png \| 200px]]
	** In the most generic representation, this is easy. The masked data will be removed from the data set.		** In the most generic representation, this is easy. The masked data will be removed from the data set.
	** For gridded (such as image) data, the masked pixels must be indicated in some way.		** For gridded (such as image) data, the masked pixels must be indicated in some way.