Difference between revisions of "2012 Data Discussion"

From canSAS
Line 1: Line 1:
*The following is the agenda of work posted under business for [[canSAS-2012]].  Please add comments here:
+
*The following is the agenda of work posted under business for [[canSAS-2012]].  Please add comments in the appropriate section below:
** '''1D Format'''
+
 
** agree a proposed foreign namespace extension of the current 1D standard (required to enable, for example, t-o-f instruments to store auxillary wavelength-dependent non-I(Q) data in the same output files)
+
= Agenda with Discussion =
*** see Section 1.6.5 in [http://svn.smallangles.net/trac/canSAS/browser/1dwg/tags/v1.0/doc/cansas-1d-1_0-manual.pdf?format=raw here]
+
 
*** and look at this [http://svn.smallangles.net/trac/canSAS/browser/1dwg/data/Glassy%20Carbon/ISIS/GLASSYC_C4G8G9_withTL.xml example]
+
== 1D Format ==
*** or [http://www.smallangles.net/wgwiki/images/f/f5/ISIS_SASXML_v1_1_Monitor_Spectrum_Example.XML this] one
+
=== Agree a proposed extension of the current 1D standard ===
** agree resultant changes to the schema/stylesheet
+
* This is an extension proposed by Steve King (ISIS) that is required to enable, for example, t-o-f instruments to store auxillary wavelength-dependent non-I(Q) data in the same output files
 +
** see Section 1.6.5 in [http://svn.smallangles.net/trac/canSAS/browser/1dwg/tags/v1.0/doc/cansas-1d-1_0-manual.pdf?format=raw here]
 +
** and look at this [http://svn.smallangles.net/trac/canSAS/browser/1dwg/data/Glassy%20Carbon/ISIS/GLASSYC_C4G8G9_withTL.xml example]
 +
** or [http://www.smallangles.net/wgwiki/images/f/f5/ISIS_SASXML_v1_1_Monitor_Spectrum_Example.XML this] one
 +
=== Agree resultant changes to the "official" schema/stylesheet ===
 +
<code>
 
     SMK  - For clarity, this extension was proposed ''after'' adoption of the existing version of the standard. Ratification of
 
     SMK  - For clarity, this extension was proposed ''after'' adoption of the existing version of the standard. Ratification of
 
           this extension at CanSAS-2012 would give facilities/software developers the necessary confidence to implement it.
 
           this extension at CanSAS-2012 would give facilities/software developers the necessary confidence to implement it.
Line 24: Line 29:
 
           does not imply that there have to be active plans for further changes at present.  
 
           does not imply that there have to be active plans for further changes at present.  
 
     AJJ - As to this particular case, I suggest that since SMK and I have it done, that we accept the additional tags, call it v1.1 and move on. If other extensions arise later and become "widely" used, then we can incorporate them as they arise. This is the key benefit of using an extensible format.
 
     AJJ - As to this particular case, I suggest that since SMK and I have it done, that we accept the additional tags, call it v1.1 and move on. If other extensions arise later and become "widely" used, then we can incorporate them as they arise. This is the key benefit of using an extensible format.
----
+
</code>
  
** '''2D Format'''
+
== 2D Format ==
** define minimum necessary for reduced data
+
=== Define minimum information necessary for reduced data ===
*** review previous discussions on 2D
+
* review previous discussions on 2D
*** considerations specific to 2D reduced data
+
* considerations specific to 2D reduced data
*** consider forward looking issues such as  
+
* consider forward looking issues such as  
**** grazing incidence
+
** grazing incidence
**** event mode analysis
+
** event mode analysis
** suggest format framework (NeXus extension, canSAS 1D extension, other) with brief discussion of the reason for the choice (including options considered, pros and cons of each, and final weighing)
+
=== Suggest format framework ===
*** compare with NeXus definitions for:
+
* NeXus extension, canSAS 1D extension, other, with brief discussion of the reason for the choice (including options considered, pros and cons of each, and final weighing)
**** [http://download.nexusformat.org/doc/html/ClassDefinitions-Application.html#NXsas '''NXsas''']
+
** compare with NeXus definitions for:
**** [http://download.nexusformat.org/doc/html/ClassDefinitions-Application.html#NXiqproc '''NXiqproc''']
+
*** [http://download.nexusformat.org/doc/html/ClassDefinitions-Application.html#NXsas '''NXsas''']
** Guide to how to make implementation easy.
+
*** [http://download.nexusformat.org/doc/html/ClassDefinitions-Application.html#NXiqproc '''NXiqproc''']
** Create straw format suitable for test/demonstration use and convert some test data for such a demonstration.
 
** Provide a plan for presentation at SAS 2012
 
  
 
----
 
----
Line 56: Line 59:
 
----
 
----
  
== Discussion ==
+
 
 +
=== Guide to how to make implementation easy. ===
 +
=== Create straw format suitable for test/demonstration use and convert some test data for such a demonstration.===
 +
=== Provide a plan for presentation at SAS 2012 ===
 +
 
  
  
 
[[Category: canSAS 2012]]
 
[[Category: canSAS 2012]]

Revision as of 05:48, 25 July 2012

  • The following is the agenda of work posted under business for canSAS-2012. Please add comments in the appropriate section below:

Agenda with Discussion

1D Format

Agree a proposed extension of the current 1D standard

  • This is an extension proposed by Steve King (ISIS) that is required to enable, for example, t-o-f instruments to store auxillary wavelength-dependent non-I(Q) data in the same output files

Agree resultant changes to the "official" schema/stylesheet


   SMK  - For clarity, this extension was proposed after adoption of the existing version of the standard. Ratification of
          this extension at CanSAS-2012 would give facilities/software developers the necessary confidence to implement it.
   SMK  - This proposed extension would allow more-or-less any non-I(Q) data to be included in a CanSAS-1D data file under a
          suitable foreign namespace. That is remarkable flexibility, and it does not require any significant revision
          of the existing standard. However, it could be argued that certain types of non-I(Q) data are so integral to a SAS
          experiment that they should instead be given explicit SASXML tags within the standard? Transmission data is a good
          example of this: the existing standard explicitly includes a tag for the transmission value from a monochromatic
          measurement (SASsample\transmission) but makes no provision for transmission values from white beam
          measurements. The proposed foreign namespace extension will make such provision possible but only as an
          extension, not as a formal part of the standard. Is that acceptable? The downside of explicitly adding new SASXML
          tags to the existing standard is that it would require issuing a new version of the standard. 
   ARJN - I would recommend that during this meeting that the current format then be 'parked', the new 2D format
          should be flexible enough to handle 1D and 2D data.
   SMK  - Agreed.
   ARR  - Perhaps we should be cautious about suggesting no further development for the existing 1-D format. Unless
          there is scope for adapting to future needs, it will be seen as not suitable for new uses.  This, of course,
          does not imply that there have to be active plans for further changes at present. 
   AJJ - As to this particular case, I suggest that since SMK and I have it done, that we accept the additional tags, call it v1.1 and move on. If other extensions arise later and become "widely" used, then we can incorporate them as they arise. This is the key benefit of using an extensible format.

2D Format

Define minimum information necessary for reduced data

  • review previous discussions on 2D
  • considerations specific to 2D reduced data
  • consider forward looking issues such as
    • grazing incidence
    • event mode analysis

Suggest format framework

  • NeXus extension, canSAS 1D extension, other, with brief discussion of the reason for the choice (including options considered, pros and cons of each, and final weighing)


  • Ron Ghosh has laid out details of a proposal to use HDF5/Nexus : HDF5 Notes Ghosh

  • Peter Boesecke misses definitions of parameters that are needed to describe small-angle and wide-angle scattering experiments. Parameters like "Distance", "Center", "Rotation" have only a meaning when they are part of a geometrical model, otherwise they are useless. He has collected parameters that are required for SAS/WAS experiments with position sensitive detectors (1D and 2D). When saving experimental data it should be checked that these parameters are either implicitly or explicitly described by the supplied metadata: SX_parametrization.


Guide to how to make implementation easy.

Create straw format suitable for test/demonstration use and convert some test data for such a demonstration.

Provide a plan for presentation at SAS 2012