NeXL

[Ben Buse]

Note that PFE allows one to correct for spectral interferences between WDS and EDS elements.

Nice, I'll have to give it a go.

[Ben Buse]

Do I understand you correctly, that PFE exports EMSA files with the values in "Counts/s" rather than "Counts"?  Reading through the standard, I didn't see anything that forbids this but it would be a novel interpretation of the standard.  (In which case, I should add support for it to NeXL and DTSA-II.)  Would you post an example PFE EMSA file to the forum for me to reverse engineer?

Yes I've attached a file, and you see it has

Code Select Expand

#YUNITS      : cps

Or maybe John would consider changing it if counts is standard?

[John Donovan]

Do I understand you correctly, that PFE exports EMSA files with the values in "Counts/s" rather than "Counts"?  Reading through the standard, I didn't see anything that forbids this but it would be a novel interpretation of the standard.  (In which case, I should add support for it to NeXL and DTSA-II.)  Would you post an example PFE EMSA file to the forum for me to reverse engineer?

Yes I've attached a file, and you see it has

Code Select Expand

#YUNITS      : cps

Or maybe John would consider changing it if counts is standard?

We would be happy to change it but then it would mess up everyone else that's already used this format. I guess we could pop up a question as to whether cps or count units should be used.  One merely has to multiply by the live time.

[Ben Buse]

Agreed easy to convert. And it's great PFE has take off angle included unlike JEOL emsa

[Nicholas Ritchie]

Do I understand you correctly, that PFE exports EMSA files with the values in "Counts/s" rather than "Counts"?  Reading through the standard, I didn't see anything that forbids this but it would be a novel interpretation of the standard.  (In which case, I should add support for it to NeXL and DTSA-II.)  Would you post an example PFE EMSA file to the forum for me to reverse engineer?

Yes I've attached a file, and you see it has

Code Select Expand

#YUNITS      : cps

Or maybe John would consider changing it if counts is standard?

We would be happy to change it but then it would mess up everyone else that's already used this format. I guess we could pop up a question as to whether cps or count units should be used.  One merely has to multiply by the live time.

Actually I misspoke in a previous post, assuming a live time of 1 s will mess with the count statistical contributions to the uncertainty.

PfE is the only application I know to use "cps" rather than "counts."  Now that I know, I can add a special case for you.  [Link to XKCD comic](https://xkcd.com/927/)

[John Donovan]

PfE is the only application I know to use "cps" rather than "counts."  Now that I know, I can add a special case for you.  [Link to XKCD comic](https://xkcd.com/927/)

Welcome to my world! 

JEOL uses L-units for spectrometer positions and Cameca uses sin theta * 10^5, JEOL used mm for stage positions and Cameca uses microns., JEOL scans the stage from top to bottom and Cameca scans from left to right, etc., etc.

[Nicholas Ritchie]

Based on Ben's feedback, I've updated NeXLCore and NeXLSpectrum to:

• Read PfE-style EMSA files. (NeXLCore v0.3.17)
• Output `Materials` (the data structure to efficiently hold multi-dimensional (0D, 1D, 2D, 3D etc) compositional data) as a table or as a elemental map.(NeXLSpectrum v0.3.13)

[Nicholas Ritchie]

Welcome to my world! 

JEOL uses L-units for spectrometer positions and Cameca uses sin theta * 10^5, JEOL used mm for stage positions and Cameca uses microns., JEOL scans the stage from top to bottom and Cameca scans from left to right, etc., etc.

The problem really is that it is really hard to write an unambiguous standard.  The EMSA standard, as generally observed, is pretty good but there are a handful of ambiguous places - like the #YUNITS tag. In theory, I could write a standard-observing EMSA file that contained "counts/coulomb" or "nanocounts/electron" or ... However, it would be practically impossible to write an EMSA reader that could predict all units a future vendor might decide to use.  Over flexible standards become "write only" standards - easy enought to write but almost impossible to write a functionally complete reader.  There is an ISO/EMSA 2.0.  It almost became a "write-only" standard when the committee almost decided to permit the file use any of the hundreds of different character encodings.  Instead they chose to permit only UTF8 which most modern programming languages can handle.

[Probeman]

Welcome to my world! 

JEOL uses L-units for spectrometer positions and Cameca uses sin theta * 10^5, JEOL used mm for stage positions and Cameca uses microns., JEOL scans the stage from top to bottom and Cameca scans from left to right, etc., etc.

The problem really is that it is really hard to write an unambiguous standard.  The EMSA standard, as generally observed, is pretty good but there are a handful of ambiguous places - like the #YUNITS tag. In theory, I could write a standard-observing EMSA file that contained "counts/coulomb" or "nanocounts/electron" or ... However, it would be practically impossible to write an EMSA reader that could predict all units a future vendor might decide to use.  Over flexible standards become "write only" standards - easy enought to write but almost impossible to write a functionally complete reader.  There is an ISO/EMSA 2.0.  It almost became a "write-only" standard when the committee almost decided to permit the file use any of the hundreds of different character encodings.  Instead they chose to permit only UTF8 which most modern programming languages can handle.

I totally get what you are saying, but I figured that "cps" was even more *standard* (that is, more commonly utilized in microanalysis) than "counts"!   

[Ben Buse]

Code Select Expand

refs = references(
  [
    # Specify a reference for iron (arg 1), in "Fe std.msa" (arg2) that is pure iron (arg3).
    reference(n"Fe", joinpath(path, "Fe std.msa"), mat"Fe"),
    # specify a conductive surface coating layer using the `coating` named argument
    reference(n"Si", joinpath(path, "SiO2 std.msa"), mat"SiO2", coating = Film(pure(n"C"), 10.0e-7)),
    reference(n"O", joinpath(path, "SiO2 std.msa"), mat"SiO2", coating = Film(pure(n"C"), 10.0e-7)),
    reference(n"Ca", joinpath(path, "CaF2 std.msa"), mat"CaF2", coating = Film(pure(n"C"), 10.0e-7)),
    # Read the composition from the spectrum file's ##D2STDCMP tag
    reference(n"Mg", joinpath(path, "MgO std.msa"), coating = Film(pure(n"C"), 10.0e-7)),
    # Read the conductive coating from the spectrum file's ##CONDCOATING tag
    reference(n"Al", joinpath(path, "Al2O3 std.msa"), mat"Al2O3"),
  ],
  132.0  # Detector resolution at Mn Kα (eV)
)

Looking at

Code Select Expand

# Read the composition from the spectrum file's ##D2STDCMP tag
Is this something PFE could do? I understand ## is optional tag in EMSA/MSA and would it affect anything else reading EMSA. If PFE did add this tag what format would the composition be in?

[Nicholas Ritchie]

Code Select Expand

function parsedtsa2comp(value::AbstractString)::Material
    try
        sp = split(value, ",")
        name = sp[1]
        mf, density = Dict{Element,Float64}(), missing
        for item in sp[2:end]
            if item[1] == '(' && item[end] == ')'
                sp2 = split(item[2:end-1], ":")
                mf[parse(Element, sp2[1])] = 0.01 * parse(Float64, sp2[2])
            else
                density = parse(Float64, item)
            end
        end
        return material(name, mf, density=density)
    catch err
        @warn "Error parsing composition $(value) - $(err)"
    end
end
This code reads the contents of the ##D2STDCOMP tab.  It splits the value on commas.
The first item in the resulting list is material name. Subsequent (except maybe the last) are like "(Fe:43.2)" or "(Al:12.3)", an element abbreviation followed by a mass percentage.  The last item could be a number representing the optional density in g/cm^3.

[Ben Buse]

It be great if PFE could for standard spectra read standard composition from standard database and write to emsa file using this tag.
Does DTSA-2 use this tag or just NeXL?

[John Donovan]

It be great if PFE could for standard spectra read standard composition from standard database and write to emsa file using this tag.
Does DTSA-2 use this tag or just NeXL?

It appears to already be implemented, but using a slightly different tag spelling:

Code Select Expand

##D2STDCMP   : NBS K-411 mineral glass,(Si:25.382),(Fe:11.209),(Mg:8.847),(Ca:11.057),(Al:0.053),(Mn:0.077),(O:43.55805)

This code was implemented a while back I think at Nicholas' request... if my comments in the code are correct.

[Nicholas Ritchie]

Right John, the tag is ##D2STDCMP.  It is a tag I created for use in DTSA-II and also implemented in NeXL. You've probably already figured this out from the name but I'll state it explicitly anyway:   It is intended as a convenient way to record the composition of spectra collected from standards (from materials of known composition.) It isn't intended to record the measured composition.

[John Donovan]

Right John, the tag is ##D2STDCMP.  It is a tag I created for use in DTSA-II and also implemented in NeXL. You've probably already figured this out from the name but I'll state it explicitly anyway:  It is intended as a convenient way to record the composition of spectra collected from standards (from materials of known composition.) It isn't intended to record the measured composition.

OK, thanks for confirming the spelling of this tag.  And yes, the values output to this tag are the "published" values from the standard composition database. But only when the spectrum in question is from a standard sample.