canSAS - User contributions [en]

File:G9 APS.jpg

2008-12-26T22:41:51Z

Ilavsky: APS USAXS Glassy Carbon G9 data, 12 and 17 keV X-ray energy

APS USAXS Glassy Carbon G9 data, 12 and 17 keV X-ray energy

File:GlassyCarbon APS.zip

2008-12-26T22:41:09Z

Ilavsky: APS ASCII and pdf data for Glassy Carbon C4 and G9

APS ASCII and pdf data for Glassy Carbon C4 and G9

File:C4 APS.jpg

2008-12-26T22:34:13Z

Ilavsky: uploaded a new version of "Image:C4 APS.jpg": APS USAXS, Glassy Carbon C4, 12keV, Jan Ilavsky

APS USAXS measured Glassy Carbon C4, 12-10-2008, Jan Ilavsky, 12keV data only

File:C4 APS.jpg

2008-12-26T22:33:28Z

Ilavsky: uploaded a new version of "Image:C4 APS.jpg": APS USAXS Glassy Carbon C4, 12keV data only, Jan Ilavsky

APS USAXS measured Glassy Carbon C4, 12-10-2008, Jan Ilavsky, 12keV data only

File:C4 APS.jpg

2008-12-26T22:32:02Z

Ilavsky: APS USAXS measured Glassy Carbon C4, 12-10-2008, Jan Ilavsky, 12keV data only

APS USAXS measured Glassy Carbon C4, 12-10-2008, Jan Ilavsky, 12keV data only

Glassy Carbon Round Robin

2008-12-26T22:28:34Z

Ilavsky: Added APS USAXS results Jan Ilavsky

==Samples==
Two samples of glassy carbons (labeled C4 and G9) from Jan Ilavsky have made their way (as of Dec 1 2008) to NIST, ILL and ISIS and will head on to Diamond and APS. Additionally another sample, labeled G8, has been measured at ISIS.

The samples are cut from glassy carbon material, manufactured by Alpha Aesar under description: Glassy Carbon type 2. These samples are manufactured in 50 x 50 mm plates, nominally 1 mm thick. Measurements with a micrometer were all between 0.99 and 1.01 mm

==Experimental details and Data==

===NIST===

<Gallery caption="NIST data for C4 and G9" widths="300px" heights="200px">
Image:C4.jpg|C4
Image:G9.jpg|G9
</Gallery>

Zip file of all data (in NIST 6 column format) with plots in PDF and Igor Pro formats [[Media:GlassyCarbon_NIST.zip|GlassyCarbon_NIST.zip]]

Zip file of all data (in canSAS XML 1D format) [[Media:GlassyCarbon_NIST_XML.zip|GlassyCarbon_NIST_XML.zip]]

===ILL===

<Gallery caption="ILL data for C4 and G9" widths="300px" heights="200px">
Image:C4_zoom.jpg|C4
Image:G9_zoom.jpg|G9
</Gallery>

Zip file of all data (in NIST 6 column format) with plots in PDF and Igor Pro formats [[Media:GlassyCarbon_ILL.zip|GlassyCarbon_ILL.zip]]

Zip file of all data (in canSAS XML 1D format) [[Media:GlassyCarbon_ILL_XML.zip|GlassyCarbon_ILL_XML.zip]]

===ISIS===

The collected data in canSAS XML format : [[Media:GLASSYC_C4G8G9.XML‎|GLASSYC_C4G8G9.XML‎]] and in pseudo canSAS XML (includes T vs Lambda datasets): [[Media:GLASSYC_C4G8G9_withTL.XML‎|GLASSYC_C4G8G9_withTL.XML‎]]

Excel file of that data with plots : [[Media:Glassy_Carbons_C4_G8_G9.xls‎|Glassy_Carbons_C4_G8_G9.xls‎]]

===APS USAXS===

<Gallery caption="APS data for C4 and G9" widths="300px" heights="200px">
Image:C4_APS.jpg|C4
Image:G9_APS.jpg|G9
</Gallery>

Zip file of all data (in ASCII 3 column format) with plots in PDF and Igor Pro formats [[Media:GlassyCarbon_APS.zip|GlassyCarbon_APS.zip]]

Zip file of all data (in canSAS XML 1D format) [[Media:GlassyCarbon_APS_XML.zip|GlassyCarbon_APS_XML.zip]]

File:GlassyCarbon APS XML.zip

2008-12-26T22:26:30Z

Ilavsky: APS USAXS Glassy Carbon XML files

APS USAXS Glassy Carbon XML files

Glassy Carbon Round Robin

2008-12-01T23:47:34Z

Ilavsky:

==Samples==
Two samples of glassy carbons from Jan Ilavsky have made their way (as of Dec 1 2008) to NIST, ILL and ISIS and will head on to Diamond and APS.

The samples are cut from glassy carbon material, manufactured by Alpha Aesar under description: Glassy Carbon type 2. These samples are manufactured in 50 x 50 mm plates, 1 mm thick.

===C4===

===G9===

==Experimental details and Data==

===NIST===

===ILL===

===ISIS===

The collected data in canSAS XML format : [[Media:GLASSYC_C4G8G9.XML‎|GLASSYC_C4G8G9.XML‎]]

Excel file of that data with plots : [[Media:Glassy_Carbons_C4_G8_G9.xls‎|Glassy_Carbons_C4_G8_G9.xls‎]]

Glassy Carbon Round Robin

2008-12-01T23:46:58Z

Ilavsky:

==Samples==
Two samples of glassy carbons from Jan Ilavsky have made their way (as of Dec 1 2008) to NIST, ILL and ISIS and will head on to Diamond and APS.

The samples are:

Samples were cut from glassy carbon manufactured by Alpha Aesar under description: Glassy Carbon type 2. These samples are manufactured in 50 x 50 mm plates, 1 mm thick.

===C4===

===G9===

==Experimental details and Data==

===NIST===

===ILL===

===ISIS===

The collected data in canSAS XML format : [[Media:GLASSYC_C4G8G9.XML‎|GLASSYC_C4G8G9.XML‎]]

Excel file of that data with plots : [[Media:Glassy_Carbons_C4_G8_G9.xls‎|Glassy_Carbons_C4_G8_G9.xls‎]]

IGOR Pro Developers Working Group

2007-12-23T20:56:15Z

Ilavsky: /* News/Status */

[http://smallangles.net/pipermail/cansas-iwg_smallangles.net/ Mailing List Archive]
===Members===
* Jan Ilavsky (APS)
* Andrew Jackson (NIST)
* Steve Kline (NIST)
* Ken Littrell (ORNL)
* Andy Nelson (ANSTO) (chair)
===News/Status===

'''USAXS (= "Indra2") data naming structure'''
APS USAXS instrument can operate with either slit smeared and 2-D collimated geometry. Practically for all samples with meaningful thickness the intensity data are absolutely calibrated ([1/cm]). Errors for intensity are always estimated. Q units are 1/A. The Q resolution (width of bin in Q) is same for all points - 1e^-4 [1/a] and therefore is not reported. Q-bin smearing is practically not necessary. Significant fraction of samples exhibit multiple scattering effects for which we attempt to make correction for absolute intensity calibration. Most of data processing parameters are stored in keyword list in the wave note.

'''List of wave names and description:'''
Folder name in Igor is the sample name - and sample name and description is included in the wave note of all waves.
''SMR_Int, SMR_Error, SMR_Qvec ''.... slit smeared Intensity, Error, and Q. Slit length is in the wave note.
''M_SMR_Int, M_SMR_Error, M_SMR_Qvec''.... slit smeared data, absolute intensity corrected for multiple scattering effects.
''DSM_Int, DSM_Error, DSM_Qvec'' .... de-smeared (using Lake method) or 2-D collimated data.
''M_DSM_Int, M_DSM_Error, M_DSM_Qvec'' .... de-smeared or 2-D collimated data, absolute intensity corrected for multiple scattering effects.

'''Nika data naming structure'''
Nika is universal package for reduction of 2D data into 1D "lineouts" for Igor Pro. It is used mostly for X-ray SAXS and WAXS instruments (synchrotron & desktop). It can output data either as function of Q, angle, or d-spacing. It can generate either maximum number of Q points (one Q per pixel on detector) or re bin the points to smaller number, or re bin the points to semi-logarithmic distribution in Q. It provides width of bin in Q as additional wave with each data for tools which enable accounting for Q-bin smearing.
To identify the sector geometry (or circular average), "_ending" is attached to the end of output wave names:
"_C" circular average
"_Angle_HalfWidth" sector average around direction of Angle with sector +/- HalfWidth
example: "_10_5" average around 10 degrees direction with sector 10 degrees (+/- 5 degrees) wide. Or to use another description - sector between lines in 5 degrees and 15 degrees azimuth on the detector.

'''List of data types'''
Sample name is used as folder name and each folder contains data from only one sample & sector.
"QRS" namings structure:
''q_sampleName_ending'' .... Q with units in [1/A]
''r_sampleName_ending'' .... Intensity with units 1/cm (if data are calibrated)
''s_sampleName_ending'' .... Error for intensity (statistical error from averaged pixels)
''w_sampleName_ending'' .... Q bin width
optionally instead of Q one can use:
''t_sampleName_ending'' .... Two theta value in degrees
''d_samplename_ending'' .... d-spacing value in A

[[Category:Working Groups]]

IGOR Pro Developers Working Group

2007-12-23T20:54:04Z

Ilavsky: /* News/Status */

[http://smallangles.net/pipermail/cansas-iwg_smallangles.net/ Mailing List Archive]
===Members===
* Jan Ilavsky (APS)
* Andrew Jackson (NIST)
* Steve Kline (NIST)
* Ken Littrell (ORNL)
* Andy Nelson (ANSTO) (chair)
===News/Status===

'''USAXS (= "Indra2") data naming structure'''
APS USAXS instrument can operate with either slit smeared and 2-D collimated geometry. Practically for all samples with meaningful thickness the intensity data are absolutely calibrated ([1/cm]). Errors for intensity are always estimated. Q units are 1/A. The Q resolution (width of bin in Q) is same for all points - 1e^-4 [1/a] and therefore is not reported. Q-bin smearing is practically not necessary. Significant fraction of samples exhibit multiple scattering effects for which we attempt to make correction for absolute intensity calibration. Most of data processing parameters are stored in keyword list in the wave note.

'''List of wave names and description:'''
''SMR_Int, SMR_Error, SMR_Qvec ''.... slit smeared Intensity, Error, and Q. Slit length is in the wave note.
''M_SMR_Int, M_SMR_Error, M_SMR_Qvec''.... slit smeared data, absolute intensity corrected for multiple scattering effects.
''DSM_Int, DSM_Error, DSM_Qvec'' .... de-smeared (using Lake method) or 2-D collimated data.
''M_DSM_Int, M_DSM_Error, M_DSM_Qvec'' .... de-smeared or 2-D collimated data, absolute intensity corrected for multiple scattering effects.

'''Nika data naming structure'''
Nika is universal package for reduction of 2D data into 1D "lineouts" for Igor Pro. It is used mostly for X-ray SAXS and WAXS instruments (synchrotron & desktop). It can output data either as function of Q, angle, or d-spacing. It can generate either maximum number of Q points (one Q per pixel on detector) or re bin the points to smaller number, or re bin the points to semi-logarithmic distribution in Q. It provides width of bin in Q as additional wave with each data for tools which enable accounting for Q-bin smearing.
To identify the sector geometry (or circular average), "_ending" is attached to the end of output wave names:
"_C" circular average
"_Angle_HalfWidth" sector average around direction of Angle with sector +/- HalfWidth
example: "_10_5" average around 10 degrees direction with sector 10 degrees (+/- 5 degrees) wide. Or to use another description - sector between lines in 5 degrees and 15 degrees azimuth on the detector.

'''List of data types'''
"QRS" namings structure:
''q_sampleName_ending'' .... Q with units in [1/A]
''r_sampleName_ending'' .... Intensity with units 1/cm (if data are calibrated)
''s_sampleName_ending'' .... Error for intensity (statistical error from averaged pixels)
''w_sampleName_ending'' .... Q bin width
optionally instead of Q one can use:
''t_sampleName_ending'' .... Two theta value in degrees
''d_samplename_ending'' .... d-spacing value in A

[[Category:Working Groups]]

IGOR Pro Developers Working Group

2007-12-23T20:51:05Z

Ilavsky: /* News/Status */

[http://smallangles.net/pipermail/cansas-iwg_smallangles.net/ Mailing List Archive]
===Members===
* Jan Ilavsky (APS)
* Andrew Jackson (NIST)
* Steve Kline (NIST)
* Ken Littrell (ORNL)
* Andy Nelson (ANSTO) (chair)
===News/Status===

'''USAXS (= "Indra2") data naming structure'''
APS USAXS instrument can operate with either slit smeared and 2-D collimated geometry. Practically for all samples with meaningful thickness the intensity data are absolutely calibrated ([1/cm]). Errors for intensity are always estimated. Q units are 1/A. The Q resolution (width of bin in Q) is same for all points - 1e^-4 [1/a] and therefore is not reported. Q-bin smearing is practically not necessary. Significant fraction of samples exhibit multiple scattering effects for which we attempt to make correction for absolute intensity calibration. Most of data processing parameters are stored in keyword list in the wave note.

'''List of wave names and description:'''
''SMR_Int, SMR_Error, SMR_Qvec '' slit smeared Intensity, Error, and Q. Slit length is in the wave note
''M_SMR_Int, M_SMR_Error, M_SMR_Qvec'' slit smeared data, absolute intensity corrected for multiple scattering effects
''DSM_Int, DSM_Error, DSM_Qvec'' de-smeared (using Lake method) or 2-D collimated data
''M_DSM_Int, M_DSM_Error, M_DSM_Qvec'' de-smeared or 2-D collimated data, absolute intensity corrected for multiple scattering effects

'''Nika data naming structure'''
Nika is universal package for reduction of 2D data into 1D "lineouts" for Igor Pro. It is used mostly for X-ray SAXS and WAXS instruments (synchrotron & desktop). It can output data either as function of Q, angle, or d-spacing. It can generate either maximum number of Q points (one Q per pixel on detector) or re bin the points to smaller number, or re bin the points to semi-logarithmic distribution in Q. It provides width of bin in Q as additional wave with each data for tools which enable accounting for Q-bin smearing.
To identify the sector parameters (or circular average), "_ending" is attached to the end of output wave names:
"_C" circular average
"_Angle_HalfWidth" sector average around direction of Angle with sector +/- HalfWidth
example: "_10_5" average around 10 degrees direction with sector 10 degrees (+/- 5 degrees) wide. Or to use another description - sector between lines in 5 degrees and 15 degrees azimuth on the detector.

'''List of data types'''
"QRS" namings structure:
''q_sampleName_ending'' Q with units in [1/A]
''r_sampleName_ending'' Intensity with units 1/cm (if data are calibrated)
''s_sampleName_ending'' Error for intensity (statistical error from averaged pixels)
''w_sampleName_ending'' Q bin width
optionally instead of Q one can use:
''t_sampleName_ending'' Two theta value in degrees
''d_samplename_ending'' d-spacing value in A

[[Category:Working Groups]]

IGOR Pro Developers Working Group

2007-12-23T20:50:20Z

Ilavsky: /* News/Status */

[http://smallangles.net/pipermail/cansas-iwg_smallangles.net/ Mailing List Archive]
===Members===
* Jan Ilavsky (APS)
* Andrew Jackson (NIST)
* Steve Kline (NIST)
* Ken Littrell (ORNL)
* Andy Nelson (ANSTO) (chair)
===News/Status===

'''USAXS (= "Indra2") data naming structure'''
APS USAXS instrument can operate with either slit smeared and 2-D collimated geometry. Practically for all samples with meaningful thickness the intensity data are absolutely calibrated ([1/cm]). Errors for intensity are always estimated. Q units are 1/A. The Q resolution (width of bin in Q) is same for all points - 1e^-4 [1/a] and therefore is not reported. Q-bin smearing is practically not necessary. Significant fraction of samples exhibit multiple scattering effects for which we attempt to make correction for absolute intensity calibration. Most of data processing parameters are stored in keyword list in the wave note.
'''List of wave names and description:'''
''SMR_Int, SMR_Error, SMR_Qvec '' slit smeared Intensity, Error, and Q. Slit length is in the wave note
''M_SMR_Int, M_SMR_Error, M_SMR_Qvec'' slit smeared data, absolute intensity corrected for multiple scattering effects
''DSM_Int, DSM_Error, DSM_Qvec'' de-smeared (using Lake method) or 2-D collimated data
''M_DSM_Int, M_DSM_Error, M_DSM_Qvec'' de-smeared or 2-D collimated data, absolute intensity corrected for multiple scattering effects

'''Nika data naming structure'''
Nika is universal package for reduction of 2D data into 1D "lineouts" for Igor Pro. It is used mostly for X-ray SAXS and WAXS instruments (synchrotron & desktop). It can output data either as function of Q, angle, or d-spacing. It can generate either maximum number of Q points (one Q per pixel on detector) or re bin the points to smaller number, or re bin the points to semi-logarithmic distribution in Q. It provides width of bin in Q as additional wave with each data for tools which enable accounting for Q-bin smearing.
To identify the sector parameters (or circular average), "_ending" is attached to the end of output wave names:
"_C" circular average
"_Angle_HalfWidth" sector average around direction of Angle with sector +/- HalfWidth
example: "_10_5" average around 10 degrees direction with sector 10 degrees (+/- 5 degrees) wide. Or to use another description - sector between lines in 5 degrees and 15 degrees azimuth on the detector.
'''List of data types'''
"QRS" namings structure:
''q_sampleName_ending'' Q with units in [1/A]
''r_sampleName_ending'' Intensity with units 1/cm (if data are calibrated)
''s_sampleName_ending'' Error for intensity (statistical error from averaged pixels)
''w_sampleName_ending'' Q bin width
optionally instead of Q one can use:
''t_sampleName_ending'' Two theta value in degrees
''d_samplename_ending'' d-spacing value in A

[[Category:Working Groups]]

IGOR Pro Developers Working Group

2007-12-23T20:42:23Z

Ilavsky:

[http://smallangles.net/pipermail/cansas-iwg_smallangles.net/ Mailing List Archive]
===Members===
* Jan Ilavsky (APS)
* Andrew Jackson (NIST)
* Steve Kline (NIST)
* Ken Littrell (ORNL)
* Andy Nelson (ANSTO) (chair)
===News/Status===

'''USAXS (= "Indra2") data naming structure'''
Introduction: APS USAXS instrument can operate with either slit smeared and 2-D collimated geometry. Generally all intensity data are absolutely calibrated ([1/cm]) and errors are estimated. Q units are 1/A. Significant fraction of samples exhibit multiple scattering effects for which we attempt to make correction for absolute intensity calibration. Most of data processing parameters are stored in keyword list in the wave note.
'''List of wave names and description:'''
SMR_Int, SMR_Error, SMR_Qvec slit smeared Intensity, Error, and Q. Slit length is in the wave note
M_SMR_Int, M_SMR_Error, M_SMR_Qvec slit smeared data, absolute intensity corrected for multiple scattering effects
DSM_Int, DSM_Error, DSM_Qvec de-smeared (using Lake method) or 2-D collimated data
M_DSM_Int, M_DSM_Error, M_DSM_Qvec de-smeared or 2-D collimated data, absolute intensity corrected for multiple scattering effects

'''Nika data naming structure'''
Introduction: Nika is generic package for reduction of 2D data into 1D "lineouts" for Igor Pro. It is used mostly for X-ray SAXS and WAXS instruments. It can output data either as function of Q, angle or d-spacing. It can generate either maximum number of Q points (one Q per pixle on detector) or re bin the points to smaller number, or re bin the points to semi-logarithmic distribution in Q.
To identify the sector parameters (or circular average), "_ending" is attached to the end of output wave names:
"_C" circular average
"_Angle_HalfWidth" sector average around direction of Angle with sector +/- HalfWidth
example: "_10_5" average around 10 degrees direction with sector 10 degrees (+/- 5 degrees) wide. Or to use another description - sector between lines in 5 degrees and 15 degrees azimuth on the detector.
'''List of data types'''
"QRS" namings structure:
q_sampleName_ending Q with units in [1/A]
r_sampleName_ending Intensity with units 1/cm (if data are calibrated)
s_sampleName_ending Error for intensity (statistical error from averaged pixels)
w_sampleName_ending Q bin width
optionally instead of Q one can use:
t_sampleName_ending Two theta value in degrees
d_samplename_ending d-spacing value in A

[[Category:Working Groups]]

Talk:IGOR Pro Developers Working Group

2007-12-11T22:24:33Z

Ilavsky: /* Irena Data selection tool (JIL, 12/11/07) */

Hello All,

Now with the canSAS report out, and the creation of the wikis, we can really get started. Right before the holidays, of course, when everyone will be on vacation and not excited to do a lot of coding...

Anyways, I thought it would be good to re-focus what we are trying to accomplish, and what steps we can take (easiest first). This is my first pass at the list. This e-mail has been crudely pasted on the wiki, since this should morph into our list.

--Steve

---------------------

'''What do we want? - things we really need to be able to do'''

(1) avoid code namespace clashes so we can all get along well together. This means internal structures, functions/macros, and XOPs.

(2) documentation of file formats, so we can read each others' data (reduced data, ready for analysis)

(3)...

'''What would we like? - things that would make our lives easier (maybe)'''

(1) code to share - common readers, analysis models/modules, so we can all save some work.

(2) common internal data handling***

(3)...

'''What do we do about these things?'''

''For "Want" #1:''

- the suggestion of putting intermediate "stuff" into facility specific data folders such as "root:Packages:NIST:" is a good one, and we'll implement that. If someone has "root:Packages:XXXXX:" lying around somewhere, it's probably not a big deal if "XXXXX" is obscure enough.

- Naming conventions for functions. "_KCL" or similar tags is an OK idea. Maybe just one letter as a suffix tag? I'd hate to give away 4 when I can only use 31 to start with.

- So we can each test for conflicts, there needs to be a simple way for us to include each others procedures - master #includes that bring up menus with more choices of what to include (and remove!) are good code snippets to put on the wiki. And a link to everyone's "current" version to test against.

- Use Igor to the fullest. There are ways of hiding functions from the global namespace. Static declarations, and #pragmas Module or IndependentModule increase the coding complexity slightly, but keep a tighter control on the namespace. I will look to use these wherever I can.

- XOPs - Currently only NCNR and ANSTO are writing XOPs, and since they are for very different purposes, I think we can stay out of each others' way. We currently add an "X" suffix to our XOP names.

''For "Want" #2:''

- this is an item for the wiki, where we can post samples of data files, and sample Igor code to read it. canSAS is to start a separate repository for this, but we can post it here first. We'll get the NCNR's 1D and 2D output formats posted.

''For "Like" #1:''

- If we can get Want #1 to work, we can include/remove each others "Packages" on demand. Following WM's "Packages" idea seems to be pretty good. For example, Jan's analysis package could be loaded (from a menu item) that #includes what is needed. Then his "Package" for size distributions could be loaded. It would play in a folder "root:Packages:XXXX" or "root:packages:APS:XXXXX". These folders can be created/killed as the package is loaded/unloaded. Any bits of analysis that can be packaged in this way should be easy to share. For how the data is internally handled, see Like#2.

- We'll soon? have a common 1D XML format, and an XOP of base functions to read them in with.

''For "Like" #2:''

- ugh. I don't know if this is a productive use of anyone's time. Jan maybe got some of this done in his code, but I don't know how. Everyone is tied into a particular naming scheme that is required to be able to present a nice interface to the users. To find a "common" naming scheme that everyone changes their code to adhere to is in my opinion, more work than its benefit. I propose that each facility's package keeps its internal folder structure (Ken!) so no functionality is broken. Then to play together well, to use NCNR packages, the data must be read in by a NCNR data loader which will enforce NCNR schemes. This would require each package to identify if there was "valid" data loaded, and instruct the user if data needs to be (re)loaded (but not overwritten). Yes, a bit messier of an experience for the user, but it seems like a solution that may actually be possible to implement. Since there's a lot of work potentially involved, this is certainly up for debate.

''Items #3 and beyond are to be determined...''

== Irena Data selection tool (JIL, 12/11/07)==

This is my attempt to document Irena data selection tools.

'''Purpose of these tools (what are they suppose to do):'''
Create easily group of controls so user can select Data and set the proper strings with names, so other procedure can easily pick them up and use them to manipulate the data. Select Folder name and two or three waves with data.

'''Features:'''
Work concurrently on multiple panels/graphs at the same time. Remember for each panel individual settings. Can be placed in subpanels and subgraphs if necessary (therefore can have more than one set in one panel/graph if necessary).
Know number of "default" data types: USAXS data, QRS data type, Irena results. But also enable programer to define user type (passed as lookup list by programmer). Can generate Q distribution for models (log or lin q distribution with all user controls). "All" data option available too - presents all waves and all folder (if all else fails, this works always).
Data type is user selectable through checkboxes - and user is presented with folder selection of only folders containing at least one data set of currently selected data type.
Created controls can be moved or even hidden by programmer as appropriate.

'''Files necessary:'''
IR2_PanelCntrlProcs.ipf and IN2_GeneralProcedures.ipf (support functions). These are distributed currently within Irena package.

Use (code snippet):
Window TestPanel2() : Panel
PauseUpdate; Silent 1 // building window...
NewPanel /K=1 /W=(2.25,43.25,390,690) as "Test"
//this example sets User data type to QRS system and enables use of Q and intensity only
string UserDataTypes="r_*;" //user data type (Intensity) is recognized as starting with "r_"
string UserNameString="Test me" //this is name for the user data type checkbox...
string XUserLookup="r_*:q_*;" //this is matching pattern for q vector name
string EUserLookup="r_*:s_*;" //this for error
variable RequireErrorWaves =0 //do not require error
variable AllowModelData = 0 //disable generating of model data
//and this creates the controls. More description is in the package about other parameters....
IR2C_AddDataControls("testpackage2","TestPanel2","DSM_Int;M_DSM_Int;","AllCurrentlyAllowedTypes;",UserDataTypes,UserNameString,XUserLookup,EUserLookup, RequireErrorWaves, AllowModelData)
end

This creates panel with 4 checkboxes to select data types and 4 popups with Folder name, X-wave name, Y wave name, and error wave name. Only folders where at least one appropriate data set exists are presented. There are some smarts to select appropriate Y and error waves if user selects the X wave (if possible)...
Anyway, resulting strings arfe found int his case in root:Packages:testpackage2 and you can use the folder name and wave names to copy or do with data what you wish.

Talk:IGOR Pro Developers Working Group

2007-12-11T22:21:06Z

Ilavsky: /* Irena Data selection tool (JIL)*/

Hello All,

Now with the canSAS report out, and the creation of the wikis, we can really get started. Right before the holidays, of course, when everyone will be on vacation and not excited to do a lot of coding...

Anyways, I thought it would be good to re-focus what we are trying to accomplish, and what steps we can take (easiest first). This is my first pass at the list. This e-mail has been crudely pasted on the wiki, since this should morph into our list.

--Steve

---------------------

'''What do we want? - things we really need to be able to do'''

(1) avoid code namespace clashes so we can all get along well together. This means internal structures, functions/macros, and XOPs.

(2) documentation of file formats, so we can read each others' data (reduced data, ready for analysis)

(3)...

'''What would we like? - things that would make our lives easier (maybe)'''

(1) code to share - common readers, analysis models/modules, so we can all save some work.

(2) common internal data handling***

(3)...

'''What do we do about these things?'''

''For "Want" #1:''

- the suggestion of putting intermediate "stuff" into facility specific data folders such as "root:Packages:NIST:" is a good one, and we'll implement that. If someone has "root:Packages:XXXXX:" lying around somewhere, it's probably not a big deal if "XXXXX" is obscure enough.

- Naming conventions for functions. "_KCL" or similar tags is an OK idea. Maybe just one letter as a suffix tag? I'd hate to give away 4 when I can only use 31 to start with.

- So we can each test for conflicts, there needs to be a simple way for us to include each others procedures - master #includes that bring up menus with more choices of what to include (and remove!) are good code snippets to put on the wiki. And a link to everyone's "current" version to test against.

- Use Igor to the fullest. There are ways of hiding functions from the global namespace. Static declarations, and #pragmas Module or IndependentModule increase the coding complexity slightly, but keep a tighter control on the namespace. I will look to use these wherever I can.

- XOPs - Currently only NCNR and ANSTO are writing XOPs, and since they are for very different purposes, I think we can stay out of each others' way. We currently add an "X" suffix to our XOP names.

''For "Want" #2:''

- this is an item for the wiki, where we can post samples of data files, and sample Igor code to read it. canSAS is to start a separate repository for this, but we can post it here first. We'll get the NCNR's 1D and 2D output formats posted.

''For "Like" #1:''

- If we can get Want #1 to work, we can include/remove each others "Packages" on demand. Following WM's "Packages" idea seems to be pretty good. For example, Jan's analysis package could be loaded (from a menu item) that #includes what is needed. Then his "Package" for size distributions could be loaded. It would play in a folder "root:Packages:XXXX" or "root:packages:APS:XXXXX". These folders can be created/killed as the package is loaded/unloaded. Any bits of analysis that can be packaged in this way should be easy to share. For how the data is internally handled, see Like#2.

- We'll soon? have a common 1D XML format, and an XOP of base functions to read them in with.

''For "Like" #2:''

- ugh. I don't know if this is a productive use of anyone's time. Jan maybe got some of this done in his code, but I don't know how. Everyone is tied into a particular naming scheme that is required to be able to present a nice interface to the users. To find a "common" naming scheme that everyone changes their code to adhere to is in my opinion, more work than its benefit. I propose that each facility's package keeps its internal folder structure (Ken!) so no functionality is broken. Then to play together well, to use NCNR packages, the data must be read in by a NCNR data loader which will enforce NCNR schemes. This would require each package to identify if there was "valid" data loaded, and instruct the user if data needs to be (re)loaded (but not overwritten). Yes, a bit messier of an experience for the user, but it seems like a solution that may actually be possible to implement. Since there's a lot of work potentially involved, this is certainly up for debate.

''Items #3 and beyond are to be determined...''

== Irena Data selection tool (JIL, 12/11/07)==

This is my attempt to document Irena data selection tools.

'''Purpose of these tools (what are they suppose to do):'''
Create easily group of controls so user can select Data and set the proper strings with names, so other procedure can easily pick them up and use them to manipulate the data. Select Folder name and two or three waves with data.

'''Features:'''
Work concurrently on multiple panels/graphs at the same time. Remember for each panel individual settings. Can be placed in subpanels and subgraphs if necessary (therefore can have more than one set in one panel/graph if necessary).
Know number of "default" data types: USAXS data, QRS data type, Irena results. But also enable programer to define user type (passed as lookup list by programmer). Can generate Q distribution for models (log or lin q distribution with all user controls). "All" data option available too - presents all waves and all folder (if all else fails, this works always).
Data type is user selectable through checkboxes - and user is presented with folder selection of only folders containing at least one data set of currently selected data type.
Created controls can be moved or even hidden by programmer as appropriate.

'''Files necessary:'''
IR2_PanelCntrlProcs.ipf and IN2_GeneralProcedures.ipf (support functions). These are distributed currently within Irena package.

Use (code snippet):
Window TestPanel2() : Panel
PauseUpdate; Silent 1 // building window...
NewPanel /K=1 /W=(2.25,43.25,390,690) as "Test"
//this example sets User data type to QRS system and enables use of Q and intensity only
string UserDataTypes="r_*;" //user data type (Intensity) is recognized as starting with "r_"
string UserNameString="Test me" //this is name for the user data type checkbox...
string XUserLookup="r_*:q_*;" //wthis is matching pattern for q vector name
string EUserLookup="r_*:s_*;" //this for error
variable RequireErrorWaves =0 //do nto require error
variable AllowModelData = 0 //disable generating of model data
//and this creates the controls.
IR2C_AddDataControls("testpackage2","TestPanel2","DSM_Int;M_DSM_Int;R_Int;SMR_Int;M_SMR_Int;","SizesFitIntensity;SizesVolumeDistribution;SizesNumberDistribution;",UserDataTypes,UserNameString,XUserLookup,EUserLookup, RequireErrorWaves, AllowModelData)
end

This creates panel with 4 checkboxes to select data types and 4 popups with Folder name, X-wave name, Y wave name, and error wave name. Only folders where at least one appropriate data set exists are presented. There are some smarts to select appropriate Y and error waves if user selects the X wave (if possible)...
Anyway, resulting strings arfe found int his case in root:Packages:testpackage2 and you can use the folder name and wave names to copy or do with data what you wish.

Talk:IGOR Pro Developers Working Group

2007-12-11T22:18:16Z

Ilavsky: /* Irena Data selection tool */

Hello All,

Now with the canSAS report out, and the creation of the wikis, we can really get started. Right before the holidays, of course, when everyone will be on vacation and not excited to do a lot of coding...

Anyways, I thought it would be good to re-focus what we are trying to accomplish, and what steps we can take (easiest first). This is my first pass at the list. This e-mail has been crudely pasted on the wiki, since this should morph into our list.

--Steve

---------------------

'''What do we want? - things we really need to be able to do'''

(1) avoid code namespace clashes so we can all get along well together. This means internal structures, functions/macros, and XOPs.

(2) documentation of file formats, so we can read each others' data (reduced data, ready for analysis)

(3)...

'''What would we like? - things that would make our lives easier (maybe)'''

(1) code to share - common readers, analysis models/modules, so we can all save some work.

(2) common internal data handling***

(3)...

'''What do we do about these things?'''

''For "Want" #1:''

- the suggestion of putting intermediate "stuff" into facility specific data folders such as "root:Packages:NIST:" is a good one, and we'll implement that. If someone has "root:Packages:XXXXX:" lying around somewhere, it's probably not a big deal if "XXXXX" is obscure enough.

- Naming conventions for functions. "_KCL" or similar tags is an OK idea. Maybe just one letter as a suffix tag? I'd hate to give away 4 when I can only use 31 to start with.

- So we can each test for conflicts, there needs to be a simple way for us to include each others procedures - master #includes that bring up menus with more choices of what to include (and remove!) are good code snippets to put on the wiki. And a link to everyone's "current" version to test against.

- Use Igor to the fullest. There are ways of hiding functions from the global namespace. Static declarations, and #pragmas Module or IndependentModule increase the coding complexity slightly, but keep a tighter control on the namespace. I will look to use these wherever I can.

- XOPs - Currently only NCNR and ANSTO are writing XOPs, and since they are for very different purposes, I think we can stay out of each others' way. We currently add an "X" suffix to our XOP names.

''For "Want" #2:''

- this is an item for the wiki, where we can post samples of data files, and sample Igor code to read it. canSAS is to start a separate repository for this, but we can post it here first. We'll get the NCNR's 1D and 2D output formats posted.

''For "Like" #1:''

- If we can get Want #1 to work, we can include/remove each others "Packages" on demand. Following WM's "Packages" idea seems to be pretty good. For example, Jan's analysis package could be loaded (from a menu item) that #includes what is needed. Then his "Package" for size distributions could be loaded. It would play in a folder "root:Packages:XXXX" or "root:packages:APS:XXXXX". These folders can be created/killed as the package is loaded/unloaded. Any bits of analysis that can be packaged in this way should be easy to share. For how the data is internally handled, see Like#2.

- We'll soon? have a common 1D XML format, and an XOP of base functions to read them in with.

''For "Like" #2:''

- ugh. I don't know if this is a productive use of anyone's time. Jan maybe got some of this done in his code, but I don't know how. Everyone is tied into a particular naming scheme that is required to be able to present a nice interface to the users. To find a "common" naming scheme that everyone changes their code to adhere to is in my opinion, more work than its benefit. I propose that each facility's package keeps its internal folder structure (Ken!) so no functionality is broken. Then to play together well, to use NCNR packages, the data must be read in by a NCNR data loader which will enforce NCNR schemes. This would require each package to identify if there was "valid" data loaded, and instruct the user if data needs to be (re)loaded (but not overwritten). Yes, a bit messier of an experience for the user, but it seems like a solution that may actually be possible to implement. Since there's a lot of work potentially involved, this is certainly up for debate.

''Items #3 and beyond are to be determined...''

== Irena Data selection tool ==

This is my attempt to document Irena data selection tools.

'''Purpose of these tools (what are they suppose to do):'''
Create easily group of controls so user can select Data and set the proper strings with names, so other procedure can easily pick them up and use them to manipulate the data. Select Folder name and two or three waves with data.

Features:
Work concurrently on multiple panels/graphs at the same time. Remember for each panel individual settings. Can be placed in subpanels and subgraphs if necessary (therefore can have more than one set in one panel/graph if necessary).
Know number of "default" data types: USAXS data, QRS data type, Irena results, user defined (passed as lookup list by programmer), can generate Q distribution for models (log or lin q distribution with all user controls). "All" data option available too - presents all waves and all folder (if all else fails, this works always).
Data type is user selectable through checkboxes - and user is presented with folder selection of only folders containing at least one data set of currently selected data type.
Created controls can be moved or even hidden by programmer as appropriate.

Files necessary:
IR2_PanelCntrlProcs.ipf and IN2_GeneralProcedures.ipf (support functions). These are distributed currently within Irena package.

Use (code snippet):
Window TestPanel2() : Panel
PauseUpdate; Silent 1 // building window...
NewPanel /K=1 /W=(2.25,43.25,390,690) as "Test"
//this example sets User data type to QRS system and enables use of Q and intensity only
string UserDataTypes="r_*;" //user data type (Intensity) is recognized as starting with "r_"
string UserNameString="Test me" //this is name for the user data type checkbox...
string XUserLookup="r_*:q_*;" //wthis is matching pattern for q vector name
string EUserLookup="r_*:s_*;" //this for error
variable RequireErrorWaves =0 //do nto require error
variable AllowModelData = 0 //disable generating of model data
//and this creates the controls.
IR2C_AddDataControls("testpackage2","TestPanel2","DSM_Int;M_DSM_Int;R_Int;SMR_Int;M_SMR_Int;","SizesFitIntensity;SizesVolumeDistribution;SizesNumberDistribution;",UserDataTypes,UserNameString,XUserLookup,EUserLookup, RequireErrorWaves, AllowModelData)
end

This creates panel with 4 checkboxes to select data types and 4 popups with Folder name, X-wave name, Y wave name, and error wave name. Only folders where at least one appropriate data set exists are presented. There are some smarts to select appropriate Y and error waves if user selects the X wave (if possible)...
Anyway, resulting strings arfe found int his case in root:Packages:testpackage2 and you can use the folder name and wave names to copy or do with data what you wish.

Talk:IGOR Pro Developers Working Group

2007-12-11T22:11:41Z

Ilavsky:

Hello All,

Now with the canSAS report out, and the creation of the wikis, we can really get started. Right before the holidays, of course, when everyone will be on vacation and not excited to do a lot of coding...

Anyways, I thought it would be good to re-focus what we are trying to accomplish, and what steps we can take (easiest first). This is my first pass at the list. This e-mail has been crudely pasted on the wiki, since this should morph into our list.

--Steve

---------------------

'''What do we want? - things we really need to be able to do'''

(1) avoid code namespace clashes so we can all get along well together. This means internal structures, functions/macros, and XOPs.

(2) documentation of file formats, so we can read each others' data (reduced data, ready for analysis)

(3)...

'''What would we like? - things that would make our lives easier (maybe)'''

(1) code to share - common readers, analysis models/modules, so we can all save some work.

(2) common internal data handling***

(3)...

'''What do we do about these things?'''

''For "Want" #1:''

- the suggestion of putting intermediate "stuff" into facility specific data folders such as "root:Packages:NIST:" is a good one, and we'll implement that. If someone has "root:Packages:XXXXX:" lying around somewhere, it's probably not a big deal if "XXXXX" is obscure enough.

- Naming conventions for functions. "_KCL" or similar tags is an OK idea. Maybe just one letter as a suffix tag? I'd hate to give away 4 when I can only use 31 to start with.

- So we can each test for conflicts, there needs to be a simple way for us to include each others procedures - master #includes that bring up menus with more choices of what to include (and remove!) are good code snippets to put on the wiki. And a link to everyone's "current" version to test against.

- Use Igor to the fullest. There are ways of hiding functions from the global namespace. Static declarations, and #pragmas Module or IndependentModule increase the coding complexity slightly, but keep a tighter control on the namespace. I will look to use these wherever I can.

- XOPs - Currently only NCNR and ANSTO are writing XOPs, and since they are for very different purposes, I think we can stay out of each others' way. We currently add an "X" suffix to our XOP names.

''For "Want" #2:''

- this is an item for the wiki, where we can post samples of data files, and sample Igor code to read it. canSAS is to start a separate repository for this, but we can post it here first. We'll get the NCNR's 1D and 2D output formats posted.

''For "Like" #1:''

- If we can get Want #1 to work, we can include/remove each others "Packages" on demand. Following WM's "Packages" idea seems to be pretty good. For example, Jan's analysis package could be loaded (from a menu item) that #includes what is needed. Then his "Package" for size distributions could be loaded. It would play in a folder "root:Packages:XXXX" or "root:packages:APS:XXXXX". These folders can be created/killed as the package is loaded/unloaded. Any bits of analysis that can be packaged in this way should be easy to share. For how the data is internally handled, see Like#2.

- We'll soon? have a common 1D XML format, and an XOP of base functions to read them in with.

''For "Like" #2:''

- ugh. I don't know if this is a productive use of anyone's time. Jan maybe got some of this done in his code, but I don't know how. Everyone is tied into a particular naming scheme that is required to be able to present a nice interface to the users. To find a "common" naming scheme that everyone changes their code to adhere to is in my opinion, more work than its benefit. I propose that each facility's package keeps its internal folder structure (Ken!) so no functionality is broken. Then to play together well, to use NCNR packages, the data must be read in by a NCNR data loader which will enforce NCNR schemes. This would require each package to identify if there was "valid" data loaded, and instruct the user if data needs to be (re)loaded (but not overwritten). Yes, a bit messier of an experience for the user, but it seems like a solution that may actually be possible to implement. Since there's a lot of work potentially involved, this is certainly up for debate.

''Items #3 and beyond are to be determined...''

== Irena Data selection tool ==

This is my attempt to document Irena data selection tools.

'''Purpose of these tools (what are they suppose to do):'''
Create easily group of controls so user can select Data and set the proper strings with names, so other procedure can easily pick them up and use them to manipulate the data. Select Folder name and two or three waves with data.

Features:
Work concurrently on multiple panels/graphs at the same time. Remember for each panel individual settings. Can be placed in subpanels and subgraphs if necessary (therefore can have more than one set in one panel/graph if necessary).
Know number of "default" data types: USAXS data, QRS data type, Irena results, user defined (passed as lookup list by programmer), can generate Q distribution for models (log or lin q distribution with all user controls). "All" data option available too - presents all waves and all folder (if all else fails, this works always).
Data type is user selectable through checkboxes - and user is presented with folder selection of only folders containing at least one data set of currently selected data type.
Created controls can be moved or even hidden by programmer as appropriate.

Files necessary:
IR2_PanelCntrlProcs.ipf and IN2_GeneralProcedures.ipf (support functions). These are distributed currently within Irena package.

Use (code snippet):
Window TestPanel2() : Panel
PauseUpdate; Silent 1 // building window...
NewPanel /K=1 /W=(2.25,43.25,390,690) as "Test"
//this example sets User data type to QRS system and enables use of Q and intensity only
string UserDataTypes="r_*;" //user data type (Intensity) is recognized as starting with "r_"
string UserNameString="Test me" //this is name for the user data type checkbox...
string XUserLookup="r_*:q_*;" //wthis is matching pattern for q vector name
string EUserLookup="r_*:s_*;" //this for error
variable RequireErrorWaves =0 //do nto require error
variable AllowModelData = 0 //disable generating of model data
//and this creates the controls.
IR2C_AddDataControls("testpackage2","TestPanel2","DSM_Int;M_DSM_Int;R_Int;SMR_Int;M_SMR_Int;","SizesFitIntensity;SizesVolumeDistribution;SizesNumberDistribution;",UserDataTypes,UserNameString,XUserLookup,EUserLookup, RequireErrorWaves, AllowModelData)
end

This creates following panel:
[[Image:Example.jpg]]