Can DTSA II Import WDS scans?

[D.]

I want to play with some JEOL 8230 WDS spectrometer scans....Can DTSA II Import these?

Thanks,
Deon.

[jrminter]

Can you export them in MSA format? DTSA can read those...

[D.]

Can you export them in MSA format? DTSA can read those...

Doesn't look like it. But I did manage CSV in the end.

Thanks.

[Ben Buse]

A long time ago I had a try here

http://probesoftware.com/smf/index.php?topic=847.0

basically you convert L-value into energy, and make it into an msa file - for which you need constant energy spacing so you fit a function

Ben

[jrminter]

I'm not sure the MSA format requires equally spaced data. The file sizes are smaller when one enters the offset and ev (or keV) per channel and then a list of intensities, but the standard permits export of X,Y pairs. Note that the description from the original specification (1991):

In the case of spectra with equally-spaced x-values (equal increments
per channel), up to #NCOLUMNS y-values may be given per line. For Y-axis
datatype 1 <  #NCOLUMNS < 5. Each y-value is either a real number
(containing a decimal point, even if there is no fractional component)
or is expressed in exponential form (e.g. 3.142E+3), and is followed
immediately by a comma. The corresponding x-values can be obtained from
the specified values of #XPERCHAN and #OFFSET or #CHOFFSET.

If the user prefers, data may be stored as (x,y) pairs of data points,
at #NCOLUMNS per line. For XY-axis datatype <  #NCOLUMNS <  3. The x-
and y-values are expressed as real numbers or in exponential format, and
are separated with a comma. The (x,y) pairs themselves are separated by
a comma followed by at least one blank space.

One can (and I have)  implement a two column export when needed.

I am in the middle of developing a package for R that will process data from PENEPMA simulations. It is under version control and I plan to implement unit tests. I am comparing to DTSA-II, so I have written functions that generate .msa files from the output of penepma. I am using a single column format for that because the data supports it. I would appreciate receiving one or two output files from PFE that I could try a two column output and see what problems arise from the irregularly spaced data. I downloaded Ben's examples (pre tidyverse) and could always try to interpolate if that is the best way to go. I have used LOESS algorithms to interpolate in the past with some success. I'll see what I can do if you send them...

Best regards,
John

[Probeman]

I'm not sure the MSA format requires equally spaced data. The file sizes are smaller when one enters the offset and ev (or keV) per channel and then a list of intensities, but the standard permits export of X,Y pairs. Note that the description from the original specification (1991):

In the case of spectra with equally-spaced x-values (equal increments
per channel), up to #NCOLUMNS y-values may be given per line. For Y-axis
datatype 1 <  #NCOLUMNS < 5. Each y-value is either a real number
(containing a decimal point, even if there is no fractional component)
or is expressed in exponential form (e.g. 3.142E+3), and is followed
immediately by a comma. The corresponding x-values can be obtained from
the specified values of #XPERCHAN and #OFFSET or #CHOFFSET.

If the user prefers, data may be stored as (x,y) pairs of data points,
at #NCOLUMNS per line. For XY-axis datatype <  #NCOLUMNS <  3. The x-
and y-values are expressed as real numbers or in exponential format, and
are separated with a comma. The (x,y) pairs themselves are separated by
a comma followed by at least one blank space.

One can (and I have)  implement a two column export when needed.

I am in the middle of developing a package for R that will process data from PENEPMA simulations. It is under version control and I plan to implement unit tests. I am comparing to DTSA-II, so I have written functions that generate .msa files from the output of penepma. I am using a single column format for that because the data supports it. I would appreciate receiving one or two output files from PFE that I could try a two column output and see what problems arise from the irregularly spaced data. I downloaded Ben's examples (pre tidyverse) and could always try to interpolate if that is the best way to go. I have used LOESS algorithms to interpolate in the past with some success. I'll see what I can do if you send them...

Best regards,
John

I thought so too, but last year when Emma Bullock at Carnegie tried to import some CL spectra acquired in Probe for EPMA (using an Ocean Optics spectrometer), into the xCLent software for further processing, it balked because Probe for EPMA had output both X (nm) and Y (intensity) data columns.  Aaron Torpy from CSIRO explained the problem to us thusly:

My concern with using the multi-column formatting to store multiple spectra in one EMSA file is that this is incompatible with the only usage of multi-column formatting declared in the ISO standard; namely to save paper when sending a single spectrum over a teletype by putting several channels worth of data on the same line. It is also worth noting that even this usage of multi-column formatting is now strongly discouraged. When describing the #NCOLUMNS keyword as in section 2.2, the standard states:

"It is strongly recommended that values > 1 are not used since multicolumn formats cause problems when importing data into spreadsheet packages. They were originally intended to make more efficient use of space on teletype printouts of data files."

There is no other documented use for multi-column formatting in the EMSA specification, so it is inconceivable that any other EMSA-reading software will be written to interpret multi-column formatting to imply multi-spectrum files. I'd be very wary of creating any new non-standard interpretation of this format that is incompatible with previous implementations, especially so for a very widely supported standard like EMSA.

So I then utilized a secondary function in the Ocean Optics spectrometer driver that refits the spectrum to equal energy spaced points and output the data as a single column and that worked fine for importing into xCLent.

[jrminter]

Thanks for passing that on, Probeman.