The "EPMA - Method Development Tool" is a database of maximum range wavelength scans of more than 170 of the most common standard materials. It was created to support lab managers and users of electron microprobe facilities with the setup of analyses programs as well as for teaching purposes. The scans were collected on PC2, PC1, PC0, TAP, PET, LPET and LLIF diffracting crystals using a CAMECA SX-100 electron microprobe at the Central Science Laboratory, University of Tasmania, Australia.
The tool can be accessed using the following link: epma-mdt.csl.utas.edu.au (http://epma-mdt.csl.utas.edu.au)
For any comments, suggestions or feedback please contact Sandrin Feig (epma.mdt@utas.edu.au) or post it here
(https://smf.probesoftware.com/gallery/8_30_05_16_5_22_51.jpeg)
The tool is particularly useful in identifying interferences and to determine suitable background positions.
(https://smf.probesoftware.com/gallery/8_30_05_16_10_57_18.jpeg)
And also shows edges and holes quite well.
(https://smf.probesoftware.com/gallery/8_30_05_16_10_52_18.jpeg)
Very cool!
Now you just need some wavescans from JEOL instruments... can you provide us with details on what you need format-wise to incorporate JEOL wavescans?
Yes, it would be good to also add JEOL wavescans to the page and I am planning to do that. There are a few options I can think of at this stage:
1: During the EPMA2016 conference somebody suggested to add a second x-axis with JEOL units. Although I am not entirely sure to what extend recalculated CAMECA scans can be applied to JEOL instruments, I will definitely give it a go and add the axis. Maybe once it is implemented, somebody with a JEOL instrument can give some feedback on that.
2: JEOL users send me their wavescans and I include them into the tool. For that I probably have to create a second database and we have to define certain conditions to make the scans comparable and compatible (range, step size, peak position to avoid offsets, diffracting crystal range to be covered, etc.). At the moment I am using csv files and I can only load one file at a time. To be able to compare scans, the scans have to be in the same file and use the same x-axis values!
3: I take my standards to a JEOL instrument and run them all. I have already quite a few updates for this page in mind, but after that I will try to get access to a JEOL and apply for money to do the scans. I kind of like this idea since it means that all scans were acquired using the same standards and the same conditions. However, it will take some time till I can collect the scans.
Hi Sandrin,
I don't think it's necessary to display both JEOL and Cameca wavescans at the same time.
What I would do (if it were my app), would be to have two options: JEOL or Cameca. And depending on which option was selected, the app would only list the wavescans from the appropriate database. And when the user select a different instrument option the app would clear the display and load the available wavescans for that instrument type.
Of course another approach would be to have a third mode which displays wavescans from both instruments, and for that I would simply convert the x-axis data for both instruments to angstroms (or keV) and then one could display them together.
Question: is the csv format you are using the output from Probe for EPMA? If so, that would make it easy for other users to provide you with more wavescans for import. Perhaps I could add a txt file to the wavescan output which could contain the condition parameters for each wavescan...?
john
Hi John
Yes, that is exactly what I have in mind. ;)
Once we have a comprehensive database of JEOL wavescans, there is no need to mix them with CAMECA scans anymore and they can definitely be in separate files, where the user can than choose between JEOL and CAMECA. Especially if I end up capturing scans on the same standards that currently exist for CAMECA my database.
But the problem is that at the moment all scans that you want to display have to be in the same csv file using the 1st column for the x values and the other columns for the individual scans. Furthermore, all wavescans have to be collected with the same x values since I only have one column for them. If I find time, I will look into transferring the csv files over to sql.
The csv format that I am using is fairly similar to the Probe for EPMA output file. In my csv files the first row contains the labels (e.g., standard or mineral names). The first column has all the x values and the other columns carry the wavescans. When I export wavescans collected with your software I basically just have to delete the multiple x columns and adjust the label a little bit, because that is what comes up in the legend under the graph.
At the moment, to be able to easily add wavescans from other labs, the scans should be from 23000 to 80000 with # Points 2048 in the acquisition window (and I use a time of 0.5 sec.). Using these parameters, our instrument than produces scans that start at 23000 and run with a step size of 27 units (23000, 23027, 23054, etc.) to ~78242. Although the end is not too important. The important bit is the step size so that I can use the same x values for everything.
Hi Sandrin,
Too bad you made the format so "rigid". It seems to me that such an app should be able to handle multiple scans with different numbers of points and x-axis values... and couldn't you recalculate the x-axis values (spectrometer position) "on the fly" based on the instrument type?
By the way, if you are interested I could "ask donovan" to implement a special output option in PFE for exporting exactly the wavescan output one needs for your app. I assume you'll want (in addition to the sample label), fields for instrument type, keV, beam current, etc., etc.
Wouldn't that be cool?
john
Hi John
Well, if you could have a chat with "Donovan" about a slightly different output format that would be awesome!
The format is partially controlled by the csv file and the fact that I can only load one at a time and by the graph gadget that I am using. I will look into changing the format to be a bit more flexible with the x values.
When I started programming the website my focus was more on getting it to work in the first place. And I had to get it ready for the conference...
I will definitely add it to the long list of things that will be optimized soon.
I had a brilliant idea this morning. Should I add some "mystery" scans? These scans could be used for teaching/testing students, What do you think?
Cheers
Sandrin
Quote from: Sandrin Feig on June 02, 2016, 06:26:17 PM
Hi John
Well, if you could have a chat with "Donovan" about a slightly different output format that would be awesome!
The format is partially controlled by the csv file and the fact that I can only load one at a time and by the graph gadget that I am using. I will look into changing the format to be a bit more flexible with the x values.
When I started programming the website my focus was more on getting it to work in the first place. And I had to get it ready for the conference...
I will definitely add it to the long list of things that will be optimized soon.
I had a brilliant idea this morning. Should I add some "mystery" scans? These scans could be used for teaching/testing students, What do you think?
Cheers
Sandrin
Hi Sandrin,
I think "Donovan" knows something about "the long list of things" as well! ;)
Some mystery scans would be useful for teaching I think.
Please provide "Donovan" with a formal criteria of what you would like for an import file. This doesn't have to be any time soon- you should think through future ideas for implementation now that you have v. 1 up and running. One suggestion for the next import file format: add a version number to the import file, so it can be added to or modified later while maintaining compatibility with previous import file formats. One easy way to do this would be to just add a version number to the first line and new stuff at the end of the file.
Again, great work. I think this will be useful.
john
Version 1.1 is now online
Most important new feature is the unit selection option for the x-axis. You can now enjoy the scans also with JEOL units (mm), or KeV, or angstrom...
(https://smf.probesoftware.com/gallery/8_30_08_16_6_24_01.jpeg)
Cheers
Sandrin
Quote from: Sandrin Feig on August 30, 2016, 06:33:05 PM
Version 1.1 is now online
Most important new feature is the unit selection option for the x-axis. You can now enjoy the scans also with JEOL units (mm), or KeV, or angstrom...
(https://smf.probesoftware.com/gallery/8_30_08_16_6_24_01.jpeg)
Cheers
Sandrin
Hi Sandrin,
Very nice!
So have you got a well defined import format you can provide for us? I'm wondering if I should implement a method in Probe for EPMA for wavescan output that will import easily into your web page... what do you currently do in PFE to create an import file for your tool?
john
Is there a way of running this tool off-line? Unfortunately I'm one of the few people who doesn't have the luxury of an internet connection at my instrument.
P.S. The country drop-down list doesn't seem to work properly on a Mac - it doesn't give any options to select so the registration can't be completed. Worked OK on my pc laptop though.
Hi Mike
Unfortunately, at the moment there is no way of running it offline, sorry.
Thanks for pointing out the problem with the Mac and the country list. May I ask which browser you are using. It might be more a browser rather than a Mac problem.
I remember your presentation in Sydney at the conference a couple of years ago. If you send me wavescans of the rather uncommon material you are working with I can include them into the tool. I guess that would make the tool a bit more useful for you. Depending of course if you are allowed to share them.
Cheers
Sandrin
Quote from: John Donovan on August 31, 2016, 11:53:29 AM
Quote from: Sandrin Feig on August 30, 2016, 06:33:05 PM
Version 1.1 is now online
Most important new feature is the unit selection option for the x-axis. You can now enjoy the scans also with JEOL units (mm), or KeV, or angstrom...
(https://smf.probesoftware.com/gallery/8_30_08_16_6_24_01.jpeg)
Cheers
Sandrin
Hi Sandrin,
Very nice!
So have you got a well defined import format you can provide for us? I'm wondering if I should implement a method in Probe for EPMA for wavescan output that will import easily into your web page... what do you currently do in PFE to create an import file for your tool?
john
Hi John
The format of the CSV-file that I import into the tool is very simple at this stage.
(https://smf.probesoftware.com/gallery/8_11_09_16_6_23_37.jpeg)
The first column has the x-values and any consecutive column has y-values of the wavescans. The first row contains the titles of the scans that will appear in the legend of the graph. That is all. However, I am wondering, if we should export wavescan conditions as well (in a separate file?). That might be useful some time down the track...
If Donovan could add such an export function to his software, that would be awesome! I will try to find a way to allow users of the tool to temporarily upload the scan of the material they are working with for comparison with the scans in the tool. I think that would add another interesting option.
Cheers
Sandrin
Quote from: Sandrin Feig on September 11, 2016, 06:12:17 PM
Hi Mike
Unfortunately, at the moment there is no way of running it offline, sorry.
Thanks for pointing out the problem with the Mac and the country list. May I ask which browser you are using. It might be more a browser rather than a Mac problem.
I remember your presentation in Sydney at the conference a couple of years ago. If you send me wavescans of the rather uncommon material you are working with I can include them into the tool. I guess that would make the tool a bit more useful for you. Depending of course if you are allowed to share them.
Cheers
Sandrin
Hi Mike
I think I known what the problem is, you select Europe as a region, but UK is not part of Europe anymore...
I managed to reproduce the error on a Mac with Safari. It works fine with Chrome.
I will modify the code so that it also works with Safari.
Thanks again.
Cheers
Sandrin
Quote from: Sandrin Feig on September 11, 2016, 09:27:21 PM
I think I known what the problem is, you select Europe as a region, but UK is not part of Europe anymore...
I managed to reproduce the error on a Mac with Safari. It works fine with Chrome.
I will modify the code so that it also works with Safari.
Hi Sandrin,
Welcome to the world of pain- sorry, I mean code development!
john
Quote from: Sandrin Feig on September 11, 2016, 06:40:54 PM
The format of the CSV-file that I import into the tool is very simple at this stage.
(https://smf.probesoftware.com/gallery/8_11_09_16_6_23_37.jpeg)
The first column has the x-values and any consecutive column has y-values of the wavescans. The first row contains the titles of the scans that will appear in the legend of the graph. That is all. However, I am wondering, if we should export wavescan conditions as well (in a separate file?). That might be useful some time down the track...
Hi Sandrin,
It appears that you only have the first column for the spectrometer positions, but multiple columns for the intensities. So this assumes that every sample is run exactly the same way on the same spectrometer? Is that the case?
So can the data file simply be one sample per file? That is the first column with the spectrometer positions and the second column the spectrometer intensities? I assume in cps/nA?
I could add a separate file for the condition details, but wouldn't it be better to have the first column header be the spectro number and crystal type? Just having "SP UNITS" doesn't provide much information...
How about the first column header like this:
SP1, PET, 15, 50, 5
where the 15, 50 and 5 refer to keV, nA and beam size respectively?
john
Thanks Sandrin.
I'll see if I can send you some spectra of my 'special' metal.
Quote from: John Donovan on September 12, 2016, 10:56:23 AM
Quote from: Sandrin Feig on September 11, 2016, 06:40:54 PM
The format of the CSV-file that I import into the tool is very simple at this stage.
(https://smf.probesoftware.com/gallery/8_11_09_16_6_23_37.jpeg)
The first column has the x-values and any consecutive column has y-values of the wavescans. The first row contains the titles of the scans that will appear in the legend of the graph. That is all. However, I am wondering, if we should export wavescan conditions as well (in a separate file?). That might be useful some time down the track...
Hi Sandrin,
It appears that you only have the first column for the spectrometer positions, but multiple columns for the intensities. So this assumes that every sample is run exactly the same way on the same spectrometer? Is that the case?
So can the data file simply be one sample per file? That is the first column with the spectrometer positions and the second column the spectrometer intensities? I assume in cps/nA?
I could add a separate file for the condition details, but wouldn't it be better to have the first column header be the spectro number and crystal type? Just having "SP UNITS" doesn't provide much information...
How about the first column header like this:
SP1, PET, 15, 50, 5
where the 15, 50 and 5 refer to keV, nA and beam size respectively?
john
Hi John
At the beginning every scan had to be done the same way. Than I added the annotations which in most cases don't exactly match the position of the scan where a data point was collected. So what I am doing now is temporarily merging two files with different x values into one. In other words, I think it is ok if the x values of scans that people produce is not exactly the same as mine.
The amount of samples per file:
If we assume that I create an option where people can upload scans of an unknown sample than yes, one sample per file, because most of the time, people are producing scans using multiple crystals. Therefore, I think ideally the file would have the x values in column A and than the columns B, C, D, E, ... are filed with scans of the same sample but with a different crystal used.
Column A: x values
Column B: PC3
Column C: PC2
Column D: PC1
Column E: TAP
...
like this we could import everything from the unknown sample by importing just one file and I could fairly easily add the scans to the appropriate crystal.
Yes, first column spec units and second intensity in cps/nA.
Good idea to replace "SP units" with conditions. If we have crystals in dedicated columns than we don't need them here. So we could just do 15 50 5. Do you have information about the instrument? Could we add the model? Or even the instrument number?
For us that would be: CamecaSX100 SX846 15 50 5
Also, what we would need is the sample name in the first row of all the y values (e,g, Column B, C, D, ...) These names will end up in the legend of the graph later on.
Cheers
Sandrin
Quote from: Sandrin Feig on September 12, 2016, 07:40:58 PM
Yes, first column spec units and second intensity in cps/nA.
Good idea to replace "SP units" with conditions. If we have crystals in dedicated columns than we don't need them here. So we could just do 15 50 5. Do you have information about the instrument? Could we add the model? Or even the instrument number? For us that would be: CamecaSX100 SX846 15 50 5
Hi Sandrin,
I'm trying to avoid making you change your code too much (I know how much of a hassle that can be!), but it seems that requiring all spectrometers to have the same range and step size is very limiting. If we insist on having this file import limitation, I would have to check at PFE export time that that the acquisition was performed with all spectrometers using the same ranges and step sizes... causing much consternation and gnashing of teeth if they hadn't already done that!
On the Cameca maybe not so much because the Cameca spectrometers generally all have the same range (more or less except for the 180 mm focal circle spectrometer which I have never seen in the wild). However JEOL instruments often have different focal circle spectrometers with different ranges. Normally from 60 to 260 or so for the 140 mm focal circle spectrometers, but those with a 100 mm focal circle only go from 85 to 250 or so.
In addition it makes no sense to require the same step size on an LIF crystal as an LDE crystal. It would make more sense to utilize larger steps but longer integration times for the LDE crystals.
So if we require all spectrometers to have the same range and step size, this will force JEOL users with 100 mm focal circle spectrometers to "throw away" some of their 140 mm spectrometer scanning range. We should think hard about this and see if we really want to limit the import format like this. I suggested a while back that we provide a spectro position column for each spectrometer and I think this is still a good idea, but I understand if it would be too much work to implement- I feel that way all the time! :D
On the sample conditions and spectrometer parameters front, I wonder if we should include the spectro number and crystal info in the x-axis column (if you decide to implement separate spectrometer position columns for each spectrometer), and for the conditions maybe just a separate line as I think we can assume that all spectrometers in an import file will have been scanned at the same beam conditions.
With that in mind here is one possible import format for a single sample:
First line: sample name, e.g., "Actinolite, Cazadero"
Second line: beam conditions, e.g., "40 degrees, 15 keV, 40 nA, 5 um"
Third line: scan data labels with 2 columns for each spectrometer, that is a column for the spectro position and a column for the intensities, e.g., "SP1 LPET", "Ca Ka 4 sec", "SP2 LTAP", "Si Ka 4 sec", etc. where the element-xray pair indicates the emission peak the spectrometer was calibrated to and the integration time for each spectrometer step.
Fourth line: start of scan data with 2 columns for each spectrometer, that is a column for the spectro position (in instrument units) and a column for the intensities (in cps/nA), e.g., "23345", "0.5657", "23543", "0.4345", etc.
I realize that this is asking a lot, but I have learned *the hard way* that we have to write code not for ease of writing, but for ease of use!
What do you think?
john
Hi Sandrin,
I've attached a 16 hour full wavescan (.DAT and .XLXS) on a natural (Toba) zircon using LIF, PET, TAP and PC1 crystals. The only interesting thing I saw was a possible trace Yb in the LiF scan as seen here:
(https://smf.probesoftware.com/gallery/395_26_10_16_12_15_48.png)
This is the normal PFE output format for wavescan samples, so I hope you would be willing to consider allowing this to be imported directly into your method development tool. Or specify a new import format that can handle multiple spectrometers with different x-axis values. I would be pleased to work with you on this.
john
Quote from: John Donovan on September 13, 2016, 10:07:35 AM
Quote from: Sandrin Feig on September 12, 2016, 07:40:58 PM
Yes, first column spec units and second intensity in cps/nA.
Good idea to replace "SP units" with conditions. If we have crystals in dedicated columns than we don't need them here. So we could just do 15 50 5. Do you have information about the instrument? Could we add the model? Or even the instrument number? For us that would be: CamecaSX100 SX846 15 50 5
Hi Sandrin,
I'm trying to avoid making you change your code too much (I know how much of a hassle that can be!), but it seems that requiring all spectrometers to have the same range and step size is very limiting. If we insist on having this file import limitation, I would have to check at PFE export time that that the acquisition was performed with all spectrometers using the same ranges and step sizes... causing much consternation and gnashing of teeth if they hadn't already done that!
On the Cameca maybe not so much because the Cameca spectrometers generally all have the same range (more or less except for the 180 mm focal circle spectrometer which I have never seen in the wild). However JEOL instruments often have different focal circle spectrometers with different ranges. Normally from 60 to 260 or so for the 140 mm focal circle spectrometers, but those with a 100 mm focal circle only go from 85 to 250 or so.
In addition it makes no sense to require the same step size on an LIF crystal as an LDE crystal. It would make more sense to utilize larger steps but longer integration times for the LDE crystals.
So if we require all spectrometers to have the same range and step size, this will force JEOL users with 100 mm focal circle spectrometers to "throw away" some of their 140 mm spectrometer scanning range. We should think hard about this and see if we really want to limit the import format like this. I suggested a while back that we provide a spectro position column for each spectrometer and I think this is still a good idea, but I understand if it would be too much work to implement- I feel that way all the time! :D
On the sample conditions and spectrometer parameters front, I wonder if we should include the spectro number and crystal info in the x-axis column (if you decide to implement separate spectrometer position columns for each spectrometer), and for the conditions maybe just a separate line as I think we can assume that all spectrometers in an import file will have been scanned at the same beam conditions.
With that in mind here is one possible import format for a single sample:
First line: sample name, e.g., "Actinolite, Cazadero"
Second line: beam conditions, e.g., "40 degrees, 15 keV, 40 nA, 5 um"
Third line: scan data labels with 2 columns for each spectrometer, that is a column for the spectro position and a column for the intensities, e.g., "SP1 LPET", "Ca Ka 4 sec", "SP2 LTAP", "Si Ka 4 sec", etc. where the element-xray pair indicates the emission peak the spectrometer was calibrated to and the integration time for each spectrometer step.
Fourth line: start of scan data with 2 columns for each spectrometer, that is a column for the spectro position (in instrument units) and a column for the intensities (in cps/nA), e.g., "23345", "0.5657", "23543", "0.4345", etc.
I realize that this is asking a lot, but I have learned *the hard way* that we have to write code not for ease of writing, but for ease of use!
What do you think?
john
Hi John
sorry for the late reply!!!
I have now modified the tool so that it can hopefully take any x-axis value.
I guess we have to split the output file into header and data part.
Header:
Maybe I can show the header information when you hover over the name of the scan in the tool? If I do it as a tool tip, than we could add a bit more text.
I think what would be nice is, if we have some general information as well (Instrument type and number and facility information e.g., Cameca SX100 SX846 UTAS). Do you have these information in your software and could include it into the output? Like this we would know where the scans came from.
Data part:
The data part has to start with #DATA and end with #END. Like this I can easily identify the part of the file that contains the data and extract them. Assuming we have (starting from the second row of the data part) two columns for each scan with first column to be spec position and second column to be intensity than we have to add information in the first row that tells us which crystal was used. The second cell of the first row has to be the sample name (whatever is in this cell will appear as legend entry). Therefore I suggest to add the scan conditions to the header.
So that the output would ideally look something like this:
Sample Name: Actinolite, Cazadero
Date collected: 28 Oct 2016
Instrument / Facility: Cameca SX100, SX846, UTAS
General conditions: 40 degrees, 15 keV, 40 nA, 5 um
Scan conditions:
SP1 LPET, Ca Ka, 4 sec, step size
SP2 TAP, Si Ka, 4 sec, step size
etc.
#DATA
LPET, Actinolite Cazadero, TAP, ...
23345, 0.5657, 23254, ...
23543, 0.4345, ...
...
#END
What do you think? Would that be possible? Does it make sense?
I have to finish off a few other things with the tool, but soon I will also add an option, where the user can upload a scan that they have collected on their instrument of an unknown material and compare with the scans in the tool. Also for that, the output format would be very useful.
Cheers
Sandrin
Quote from: Sandrin Feig on October 27, 2016, 10:39:03 PM
So that the output would ideally look something like this:
Sample Name: Actinolite, Cazadero
Date collected: 28 Oct 2016
Instrument / Facility: Cameca SX100, SX846, UTAS
General conditions: 40 degrees, 15 keV, 40 nA, 5 um
Scan conditions:
SP1 LPET, Ca Ka, 4 sec, step size
SP2 TAP, Si Ka, 4 sec, step size
etc.
#DATA
LPET, Actinolite Cazadero, TAP, ...
23345, 0.5657, 23254, ...
23543, 0.4345, ...
...
#END
What do you think? Would that be possible? Does it make sense?
Yes, that doesn't sound too hard to implement. Give me a few days, maybe next week.
john
Quote from: Sandrin Feig on October 27, 2016, 10:39:03 PM
So that the output would ideally look something like this:
Sample Name: Actinolite, Cazadero
Date collected: 28 Oct 2016
Instrument / Facility: Cameca SX100, SX846, UTAS
General conditions: 40 degrees, 15 keV, 40 nA, 5 um
Scan conditions:
SP1 LPET, Ca Ka, 4 sec, step size
SP2 TAP, Si Ka, 4 sec, step size
etc.
#DATA
LPET, Actinolite Cazadero, TAP, ...
23345, 0.5657, 23254, ...
23543, 0.4345, ...
...
#END
Sandrin,
On the Scan Conditions section are you assuming there are always 5 spectrometers, or will your import code handle if there are only 3 or 4 spectrometers? I assume you will count the number of SP# lines and use that value to parse the #DATA section?
Also, in the #DATA section you have duplicated the crystals and the sample name? Why? Shouldn't it just be pos1, intensity1, pos2, intensity2, etc. as the column headers?
Finally are you assuming the intensity data is always cps/nA?
john
Hi Sandrin,
Another question: in PFE each wavescan sample can have up to 72 elements (ROIs), but I assume that you always want to limit the output to 1 scan per spectrometer?
Also I assume that you always want the spectrometers output in spectrometer order (1,2,3... etc.)?
Finally, if the user acquires scans on fewer spectrometers than they actually have, should I just output zeros for those columns, or will your code skip the missing columns based on the missing parameters in the "Scan Conditions" lines?
john
Quote from: John Donovan on October 28, 2016, 05:01:24 PM
Quote from: Sandrin Feig on October 27, 2016, 10:39:03 PM
So that the output would ideally look something like this:
Sample Name: Actinolite, Cazadero
Date collected: 28 Oct 2016
Instrument / Facility: Cameca SX100, SX846, UTAS
General conditions: 40 degrees, 15 keV, 40 nA, 5 um
Scan conditions:
SP1 LPET, Ca Ka, 4 sec, step size
SP2 TAP, Si Ka, 4 sec, step size
etc.
#DATA
LPET, Actinolite Cazadero, TAP, ...
23345, 0.5657, 23254, ...
23543, 0.4345, ...
...
#END
Sandrin,
On the Scan Conditions section are you assuming there are always 5 spectrometers, or will your import code handle if there are only 3 or 4 spectrometers? I assume you will count the number of SP# lines and use that value to parse the #DATA section?
Also, in the #DATA section you have duplicated the crystals and the sample name? Why? Shouldn't it just be pos1, intensity1, pos2, intensity2, etc. as the column headers?
Finally are you assuming the intensity data is always cps/nA?
john
Hi John
The import code should be fine handling 4 or even just 3 spectrometers. Everything in the header will most likely be used for a tooltip or something like that.
In the #DATA section the crystal and the sample name are repeated, that is correct. The first, third, fifth, etc. cell of the first row will be used to identify which crystal was used. That is important so that I can match the scan to the corresponding scans that are already in the tool. The content of the second, fourth, sixth, etc. cell of the first row will be shown in the legend of the graph. Therefore I think repeating the sample name here would be best.
If we use pos1 and intensity1, etc. than I cannot extract which crystal was used and the legend would say "intensity1".
Yes, intensity data should be cps/nA. At least everything else in the tool is cps/nA.
Cheers
Sandrin
Quote from: John Donovan on October 29, 2016, 09:54:43 AM
Hi Sandrin,
Another question: in PFE each wavescan sample can have up to 72 elements (ROIs), but I assume that you always want to limit the output to 1 scan per spectrometer?
Also I assume that you always want the spectrometers output in spectrometer order (1,2,3... etc.)?
Finally, if the user acquires scans on fewer spectrometers than they actually have, should I just output zeros for those columns, or will your code skip the missing columns based on the missing parameters in the "Scan Conditions" lines?
john
Hi John
I think, if the user programs more than one scan per sample than the output should go into separate files. Otherwise it becomes very messy. Also, if you want to upload a scan, than one is enough. Or should we have an average option, where you can export the average of multiple scans collected on the sample sample? The spec units would be the same, just the intensity would be a bit smoother...
The spectrometer order is probably not too important since everybody is using a customized instruments. Therefore we have to use the first cell, first row of the #DATA section to identify which crystal was used. But yes, it is probably good to be consistent, so let's do 1,2,3,etc.
With fewer spectrometers I am not sure. I think it might be best to leave the unused ones blank. But I have to test and see what happens.
Cheers
Sandrin
Quote from: Sandrin Feig on October 30, 2016, 04:14:57 PM
With fewer spectrometers I am not sure. I think it might be best to leave the unused ones blank. But I have to test and see what happens.
By "blank" do you missing or present with two columns of zeros?
john
Quote from: John Donovan on October 30, 2016, 04:32:56 PM
Quote from: Sandrin Feig on October 30, 2016, 04:14:57 PM
With fewer spectrometers I am not sure. I think it might be best to leave the unused ones blank. But I have to test and see what happens.
By "blank" do you missing or present with two columns of zeros?
john
I think we should go with "missing"
Cheers
Sandrin
Hi Sandrin,
I made a first attempt at an output format for your EPMA Development Tool import. Please let me know if you want further changes. I've assumed you don't want a tab delimited file? The complete output file is attached below if you want to play with it.
john
#SAMPLE NAME: Toba Zircon (full scan)
#DATE COLLECTED: 10/25/2016 05:42:43 PM
#INSTRUMENT/FACILITY: Cameca SX100, UofO
#GENERAL CONDITIONS: 20 keV, 100 nA, 10 nA
#SCAN CONDITIONS SP1 : TAP, Hf Ma, 40 sec, 51.1475
#SCAN CONDITIONS SP2 : LPET, Zr La, 40 sec, 51.39684
#SCAN CONDITIONS SP3 : LLIF, Ni Ka, 40 sec, 51.06467
#SCAN CONDITIONS SP4 : PC1, O Ka, 40 sec, 51.555
#SCAN CONDITIONS SP5 : PET, Si Ka, 40 sec, 51.48008
TAP, Toba Zircon (full scan), LPET, Toba Zircon (full scan), LLIF, Toba Zircon (full scan), PC1, Toba Zircon (full scan), PET, Toba Zircon (full scan),
#DATA
84139.0, 1.46615 84138.0, 8.62505 83739.0, 9.26814 83728.0, 2.21885 83738.0, 2.58736
84087.0, 1.59160 84087.0, 9.74642 83687.0, 9.29166 83676.0, 2.39134 83687.0, 2.36782
84036.0, 1.70137 84035.0, 10.3502 83636.0, 9.15051 83625.0, 2.36782 83635.0, 2.88531
83985.0, 1.57592 83984.0, 10.5385 83585.0, 8.90741 83573.0, 2.34430 83584.0, 4.79065
83934.0, 1.62296 83932.0, 10.6482 83534.0, 9.72297 83522.0, 2.39134 83532.0, 4.64167
83883.0, 1.65433 83881.0, 10.8678 83483.0, 9.15835 83470.0, 2.32862 83480.0, 3.72427
83831.0, 1.67001 83830.0, 11.0874 83432.0, 9.29166 83418.0, 2.26589 83429.0, 2.90099
Edit by John: I removed the attached file and attached a newer format example file in the next post.
Quote from: John Donovan on October 31, 2016, 12:58:13 PM
Hi Sandrin,
I made a first attempt at an output format for your EPMA Development Tool import. Please let me know if you want further changes. I've assumed you don't want a tab delimited file? The complete output file is attached below if you want to play with it.
john
#SAMPLE NAME: Toba Zircon (full scan)
#DATE COLLECTED: 10/25/2016 05:42:43 PM
#INSTRUMENT/FACILITY: Cameca SX100, UofO
#GENERAL CONDITIONS: 20 keV, 100 nA, 10 nA
#SCAN CONDITIONS SP1 : TAP, Hf Ma, 40 sec, 51.1475
#SCAN CONDITIONS SP2 : LPET, Zr La, 40 sec, 51.39684
#SCAN CONDITIONS SP3 : LLIF, Ni Ka, 40 sec, 51.06467
#SCAN CONDITIONS SP4 : PC1, O Ka, 40 sec, 51.555
#SCAN CONDITIONS SP5 : PET, Si Ka, 40 sec, 51.48008
TAP, Toba Zircon (full scan), LPET, Toba Zircon (full scan), LLIF, Toba Zircon (full scan), PC1, Toba Zircon (full scan), PET, Toba Zircon (full scan),
#DATA
84139.0, 1.46615 84138.0, 8.62505 83739.0, 9.26814 83728.0, 2.21885 83738.0, 2.58736
84087.0, 1.59160 84087.0, 9.74642 83687.0, 9.29166 83676.0, 2.39134 83687.0, 2.36782
84036.0, 1.70137 84035.0, 10.3502 83636.0, 9.15051 83625.0, 2.36782 83635.0, 2.88531
83985.0, 1.57592 83984.0, 10.5385 83585.0, 8.90741 83573.0, 2.34430 83584.0, 4.79065
83934.0, 1.62296 83932.0, 10.6482 83534.0, 9.72297 83522.0, 2.39134 83532.0, 4.64167
83883.0, 1.65433 83881.0, 10.8678 83483.0, 9.15835 83470.0, 2.32862 83480.0, 3.72427
83831.0, 1.67001 83830.0, 11.0874 83432.0, 9.29166 83418.0, 2.26589 83429.0, 2.90099
Hi John
Excellent, well done!
I will download the file and play with it.
One thing that I noticed is, that the #DATA has to be moved a little bit up.
Like this:
...
#SCAN CONDITIONS SP5 : PET, Si Ka, 40 sec, 51.48008
#DATA
TAP, Toba Zircon (full scan), LPET, Toba Zircon (full scan), LLIF, Toba Zircon (full scan), PC1, Toba Zircon (full scan), PET, Toba Zircon (full scan),
84139.0, 1.46615 84138.0, 8.62505 83739.0, 9.26814 83728.0, 2.21885 83738.0, 2.58736
...
#END
And can you please add "," behind every entry in the #DATA section?
84139.0, 1.46615, 84138.0, 8.62505, 83739.0, 9.26814, 83728.0, 2.21885, 83738.0, 2.58736,
otherwise it looks very good. I also noticed that I have been running the scans the other way, something that I haven't thought about. But I am pretty sure that doesn't matter.
Thanks
Cheers
Sandrin
Hi Sandrin,
OK, I uploaded a new v. 11.6.8 PFE and I think the format is now what you want. See attached example below.
john
#SAMPLE NAME: Toba Zircon (full scan)
#DATE COLLECTED: 10/25/2016 05:42:43 PM
#INSTRUMENT/FACILITY: Cameca SX100, UofO
#GENERAL CONDITIONS: 20 keV, 100 nA, 10 nA
#SCAN CONDITIONS SP1: TAP, Hf Ma, 40 sec, 51.1475
#SCAN CONDITIONS SP2: LPET, Zr La, 40 sec, 51.39684
#SCAN CONDITIONS SP3: LLIF, Ni Ka, 40 sec, 51.06467
#SCAN CONDITIONS SP4: PC1, O Ka, 40 sec, 51.555
#SCAN CONDITIONS SP5: PET, Si Ka, 40 sec, 51.48008
#DATA
TAP, Toba Zircon (full scan), LPET, Toba Zircon (full scan), LLIF, Toba Zircon (full scan), PC1, Toba Zircon (full scan), PET, Toba Zircon (full scan),
84139.0, 1.46615, 84138.0, 8.62505, 83739.0, 9.26814, 83728.0, 2.21885, 83738.0, 2.58736,
84087.0, 1.59160, 84087.0, 9.74642, 83687.0, 9.29166, 83676.0, 2.39134, 83687.0, 2.36782,
84036.0, 1.70137, 84035.0, 10.3502, 83636.0, 9.15051, 83625.0, 2.36782, 83635.0, 2.88531,
83985.0, 1.57592, 83984.0, 10.5385, 83585.0, 8.90741, 83573.0, 2.34430, 83584.0, 4.79065,
83934.0, 1.62296, 83932.0, 10.6482, 83534.0, 9.72297, 83522.0, 2.39134, 83532.0, 4.64167,
Hi John
I was thinking, the export format looks very promising for me. And if I find a way for users to upload a scan of an unknown material and use the scans in the tool to identify peaks than the export would also work for all the Cameca users out there. However, for JEOL users this wouldn't work....
JEOL crystals are different or have a different name and the spectrometers have different sizes. If the crystal name is just a bit different than I can merge them with the Cameca crystals, but the rest is a bit more "problematic"... I have to think a bit more about that. If I keep them completely separate and create new buttons for them then we cannot compare with the existing ones...
Cheers
Sandrin
Quote from: Sandrin Feig on November 03, 2016, 08:47:33 PM
I was thinking, the export format looks very promising for me. And if I find a way for users to upload a scan of an unknown material and use the scans in the tool to identify peaks than the export would also work for all the Cameca users out there. However, for JEOL users this wouldn't work....
JEOL crystals are different or have a different name and the spectrometers have different sizes. If the crystal name is just a bit different than I can merge them with the Cameca crystals, but the rest is a bit more "problematic"... I have to think a bit more about that. If I keep them completely separate and create new buttons for them then we cannot compare with the existing ones...
Welcome to my world of pain! ;D
I'd be happy to chat with you about how I deal with JEOL vs. Cameca in my own software. I even used to support ARL instrument spectrometers which used LiF angstrom units!
One thing I utilized from the beginning was a "hardware abstraction layer" or HAL in PFE, which is often utilized by any software that needs to run on (operating systems) or talk to (communication) different hardware. Basically all calls from the main app are directed through a device independent layer which sorts out which spectrometer type one is dealing with. Does that make sense?
john