Wish List for PFE Features

[Ben Buse]

Hi John,

I like your attempt to use MAN - collect MAN for various metals - which includes the contamination on those metals - and then subtract it, thus eliminating the need for a calibration curve and allowing phi-rho-z. I will have to give it a go!!

This method subtracts both the background and the contamination from each point. What do you think - do you think its as good as a calibration curve? Also do you think its as good as subtracting a set value for contamination and meansuring the background value to subtract?

Thanks

Ben

[Probeman]

Hi John,

I like your attempt to use MAN - collect MAN for various metals - which includes the contamination on those metals - and then subtract it, thus eliminating the need for a calibration curve and allowing phi-rho-z. I will have to give it a go!!

This method subtracts both the background and the contamination from each point. What do you think - do you think its as good as a calibration curve? Also do you think its as good as subtracting a set value for contamination and meansuring the background value to subtract?

Thanks

Ben

Hi Ben,
Let me make sure I understand your point.  You are saying that if one uses a MAN background calibration curve for carbon measurements, then the natural carbon contamination rate would get normalized out in the background correction?  Yes, this is essentially what happens when one uses the multi-standard calibration curve method for carbon analyses, but your idea would allow us to still utilize phi-rho-z, etc.

If this is what you mean, I have to say it might be possible.  The only issue I can see is that the carbon contamination rate is somewhat dependent on the thermal conductivity of the surface. That is, the higher the thermal conductivity, the slower the cracking of hydrocarbons and subsequent deposition on the surface...  therefore one might want to try and make sure that standards used for the MAN calibration are similar in thermal conductivity to the unknown material.  For example, for carbon in steel, one might want to utilize pure metals rather than pure oxides for the MAN calibration...

It's worth a try.  Please post your results here, or maybe even better, start a carbon measurement topic and put it there.  I'd be very interested to see what you find.
john

[Ben Buse]

Hi John,

Yes you've got it. With pure metals we assume the contamination rate is the same as on the unknowns. It might be a while before I get a chance, then I'll post it

Thanks

Ben

[John Donovan]

2) Would it be possible to make a slight change to the sort order output options? Currently, the option to export in geologic (or atomic number) order is only offered when calculating with stoichiometric oxygen. The current options in "Analysis Options" for sort order during output are:
- Use Traditional Geological Sort Order
- Use Low to High Atomic Number Order
- Use High to Low Atomic Number Order

Could this be modified to have four options:
- Use Traditional Geological Sort Order
- Use Low to High Atomic Number Order
- Use High to Low Atomic Number Order
- Do not re-sort elements (i.e. if this box is checked, don't sort anything)

And have the sort order on output depend on which of those four options is selected, regardless of whether stoichiometric oxygen is used, with the default option able to be specified in the INI file?

Your wish is granted!   There is already an option for the default sort order in the INI file.  Note that I had to re-index these sort methods, so zero used to be traditional geological order, but now it means no sort.

3) This one may be a bug, or a misunderstanding on my part. In the "Elements/Cations" dialog (accessible from Acquire and Analyze), we have the option to change the cation/oxygen proportions, and the elemental charge, an especially useful feature for things like Fe. I have noticed that when I try to change these parameters, the Cations and Oxygens fields update, but the Charge field does not.

As an example, if Fe is calcualted as FeO (Fe2+) in my initial setup, and I want to change it to Fe2O3 (Fe3+) in post-production, I will:
- Open the Fe element dialog (Analyze --> Elements/Cations --> Fe)
- Change the Cations field from 1 to 2
- Change the Oxygens field from 1 to 3
- Change the Charge field from 2 to 3.
- Hit OK on the Fe dialog and then the Elements/Cations dialog.

If I do this, it will calculate Fe as Fe2O3 without problem. However, if I re-open the the Fe dialog window (Analyze --> Elements/Cations --> Fe) after performing the sequence above, I find that:
- The Cations field still shows 2 (as it should)
- The Oxygens field still shows 3 (as it should)
- But the Charge field will show 2 (when I had put in 3).

I don't know if this actually affects anything (again, the cation/oxygen proportions change as they should), so I may be nit-picking, or completely misusing the feature. That said, is there any reason that updates to the Charge field don't persist? And does this affect any of the charge balance-based calculations?

This was a bug, but is now fixed.  The only thing that the elemental atomic charge values are used for is to calculate the charge balance of the composition (see Analytical | Analysis Options menu) and for deciding which elements are cations and which are anions for sum of cation calculations.

[Karsten Goemann]

The new sort order options (geo, atomic number...) are working great!

I wished it was possible to send the Save User Specified Format Output directly to Excel, without generating .DAT files first and asking for confirmation.

It would also be great if the column headers didn't have leading spaces. At the moment the first thing I always do in a newly exported Excel file is search for the spaces in the headings and replace them with nothing.

[John Donovan]

The new sort order options (geo, atomic number...) are working great!

Thank-you.

I wished it was possible to send the Save User Specified Format Output directly to Excel, without generating .DAT files first and asking for confirmation.

You can. Just select the data type you want to output to Excel in Analytical | Analysis Options menu, use the Output menu to open a link to Excel, then select all samples in the Analyze Window and click Analyze.

It would also be great if the column headers didn't have leading spaces. At the moment the first thing I always do in a newly exported Excel file is search for the spaces in the headings and replace them with nothing.

Why does this matter?

I did it so the DAT file when opened in a text editor looks pretty. Not a great reason, but why do spaces matter?  Also, it's always 8 characters, so consistent at least.

[Karsten Goemann]

I wished it was possible to send the Save User Specified Format Output directly to Excel, without generating .DAT files first and asking for confirmation.

You can. Just select the data type you want to output to Excel in Analytical | Analysis Options menu, use the Output menu to open a link to Excel, then select all samples in the Analyze Window and click Analyze.

If I do that it will quantify all the data but it does not appear in the Excel file. If I push the ">>Excel" button in the Analyze window it will export the last displayed dataset. Also, it will only export the wt% (or whatever is selected) but not all of the data types I selected in the user specified output options.

It would also be great if the column headers didn't have leading spaces. At the moment the first thing I always do in a newly exported Excel file is search for the spaces in the headings and replace them with nothing.

Why does this matter?

I did it so the DAT file when opened in a text editor looks pretty. Not a great reason, but why do spaces matter?  Also, it's always 8 characters, so consistent at least.

I never use the DAT files so the columns don't have to line up in a monospace font for me. The leading spaces make the columns wider than they need to be so there's lots of scrolling involved (as I always export wt%, ox%, CDL, %err, intensities, correction factors... together). The leading spaces also can cause trouble when sorting columns. Some column headers (e.g. intensities, k-raws) and some of the data (DATETIME) have more than 8 characters, don't they?

[John Donovan]

I wished it was possible to send the Save User Specified Format Output directly to Excel, without generating .DAT files first and asking for confirmation.

You can. Just select the data type you want to output to Excel in Analytical | Analysis Options menu, use the Output menu to open a link to Excel, then select all samples in the Analyze Window and click Analyze.

If I do that it will quantify all the data but it does not appear in the Excel file. If I push the ">>Excel" button in the Analyze window it will export the last displayed dataset. Also, it will only export the wt% (or whatever is selected) but not all of the data types I selected in the user specified output options.

It would also be great if the column headers didn't have leading spaces. At the moment the first thing I always do in a newly exported Excel file is search for the spaces in the headings and replace them with nothing.

Why does this matter?

I did it so the DAT file when opened in a text editor looks pretty. Not a great reason, but why do spaces matter?  Also, it's always 8 characters, so consistent at least.

I never use the DAT files so the columns don't have to line up in a monospace font for me. The leading spaces make the columns wider than they need to be so there's lots of scrolling involved (as I always export wt%, ox%, CDL, %err, intensities, correction factors... together). The leading spaces also can cause trouble when sorting columns. Some column headers (e.g. intensities, k-raws) and some of the data (DATETIME) have more than 8 characters, don't they?

Ok, yes you are correct.  I think I had an option there at one time, but it's missing now it seems.  I could add it back in if that would be helpful.  But it sounds that an output to Excel wouldn't be useful to you unless it's exactly the user specified output options?   I wonder if I could add an option to use that format, but on the other hand, this seems merely an effort to save one or two mouse clicks at the end of the run.  Are we spoiling you just a wee little bit?   

On the leading spaces in Excel, yes, they aren't all 8 spaces, but they are consistent on a per column basis. 

Are you sure extra spaces in the header row causes sorting problems?   Maybe just don't select the first header row when sorting?

[Karsten Goemann]

Yes, I admit this is a trivial work flow thing, but after doing the same 10-20 clicks over years it gets a bit annoying and maybe it's not just me and it might be helpful for other people as well? Are many people still using the DAT files and work with their data in a text editor? The procedure involves other steps like always having to delete the .DAT files afterwards. I'm exclusively using the User Specified Output export to Excel and always selecting ranges of datasets to export in Analyze.

I've been using the first row in Excel for sorting (custom lists...) so I can't really exclude it. :-) But now with the better geo and atomic number output sorting I might not have to do that so much anymore.

[John Donovan]

Yes, I admit this is a trivial work flow thing, but after doing the same 10-20 clicks over years it gets a bit annoying and maybe it's not just me and it might be helpful for other people as well? Are many people still using the DAT files and work with their data in a text editor? The procedure involves other steps like always having to delete the .DAT files afterwards. I'm exclusively using the User Specified Output export to Excel and always selecting ranges of datasets to export in Analyze.

I've been using the first row in Excel for sorting (custom lists...) so I can't really exclude it. :-) But now with the better geo and atomic number output sorting I might not have to do that so much anymore.

Hi Karsten,
Right now, PFE uses the .DAT file to import into Excel.  Otherwise the import would be much, much slower and then I'll hear complaints about that!    But seriously, why bother deleting the .DAT file at all?  Don't be so "tidy" and just think of it as a "backup"!   Besides, the .DAT file has many uses, for example it can be read directly by Surfer, Grapher and many other apps.

I'll have to see if I can think of a clever way to write some code to export quickly to Excel without the .DAT file... maybe it will only take me a few thousand keystrokes and mouse clicks!   

[Karsten Goemann]

Hi John, if it's not easy to do and complicates things don't worry about it! As I don't know the internal machinations that's usually not clear to me before asking. If the .DAT export route is fastest it sounds like a good way of doing it.

Regarding Grapher import I think what works very nicely is linking Excel spreadsheets as data source, basically using Grapher as a plotting backend for Excel.

[John Donovan]

Hi John, if it's not easy to do and complicates things don't worry about it! As I don't know the internal machinations that's usually not clear to me before asking. If the .DAT export route is fastest it sounds like a good way of doing it.

Regarding Grapher import I think what works very nicely is linking Excel spreadsheets as data source, basically using Grapher as a plotting backend for Excel.

Yup. Or reading with other scripts. 

I just have to see if I can think of a clever method to do the user specified output directly to Excel without the DAT file, but I promised Phil Gopon that I'd work on adding non-traditional lines to the program,  so I'll be focusing on that for the time being...
john

[Malcolm Roberts]

John
TDI. Currently increments XY values during acquisition. Have you thought about allowing these points to be manually automated? My reason is that I am analysing some vesicular glasses with a broad beam. Sometimes there just ain't the space.
Cheers,
Malc.

[John Donovan]

John
TDI. Currently increments XY values during acquisition. Have you thought about allowing these points to be manually automated? My reason is that I am analysing some vesicular glasses with a broad beam. Sometimes there just ain't the space.
Cheers,
Malc.

Hi Malcolm,
As I suggested previously, you should not be using the assigned TDI. Please use the self TDI and all will be well. See here:

http://probesoftware.com/smf/index.php?topic=11.msg252#msg252

john

[Malcolm Roberts]

Hi John
Irrespective of how I go about skinning my cat, how's about thinking about my idea? I'm sure that when doing the acquired TDI, the standards would be in good condition (maybe), but the docs also state that this can be done for an unknown sample  similar or more or less the same in composition (matrix) as the actual unknowns. I thought it might be handy in this case to have an addition option for locality selection.
Cheers,
Malc.