I did forget one thing! You'll want the "conda activate smakenv" in the script... so the script line above should be: do script "conda activate smakenv; cd /YOUR_DIRECTORY_TO_SMAK/; python smak.py"

For a PCA TT analysis, you would (a) load many samples that have a variation in them (b) do PCA (c) select only the components - by clicking and selecting them - that are relevant and have signal - you cannot use all the components, and you also need more than 1 (d) load the standard file that you want to TT against in the TT box. The values you get (R and SPOIL) should give you a relative idea if that standard is a reasonable useage in the variation of the samples that you have.

If you want to do the analysis in EXAFS, then chi files are good - for XANES, you would want the mu. Either export from Athena should be a 2 column text file, which should be able to load in SIXPACK, even if it doesn't have the proper extension. XDI files will open in the PC section as well.

SIXPACK does not support Athena PRJ project files. You would need to export your data from Athena in a general format -- you can do either general text or XDI formats. These should be covered in the Athena manuals in Sections 8 and 11.

All of our SSRL fluorescence detectors are Si (silicon) drift detectors, so the appropriate setting is just "Si".

You'll want to check your configuration... This usually happens when the default detector material is not set (its just a "--") and it should be a valid element, like "Si". This is found on the tabs after the detection elements and is in the materials parameters region of the fitting configuration.

Can you check your version? I found this error earlier, and its a "silly" one where its missing a \ in the code -- C:\Users\andre\.conda\envs\smakenv\Lib\site-packages\smakpyMcaConfigs\defaultPyMCAConfig.cfg should really be C:\Users\andre\.conda\envs\smakenv\Lib\site-packages\smak\pyMcaConfigs\defaultPyMCAConfig.cfg I think this should be fixed in the latest (3.0.8)? If you are current, let me know and (1) I'll make sure the fix gets in the correct place, and (2) let you know where to edit to code for immediate relief! S

Ok - I found the error! It's quite stupid the way the data for the x-axis stored. There was an error in the file reader... regardless, it is fixed in the code now, the next release (3.0.8) will have the proper code for reading the wavenumbers correctly. You'll want to reload the raw data from the originals (ie. remove any of the -ftir.hdf5 files and reopen the original data file) to get the correct values.

Ok - that's manageable at least. Not sure why the Agilent data file reader is off that way -- Its not overly documented, but I'll take a look and see if I can find anything in the data file that looks like an offset. If so, I'll make an edit in the reader. Otherwise, I can put an energy offset in SMAK for you -- would it be "better" to have the energy offset (1) entered in the first read of the FTIR data file so that it is a fix for the data file at first reading - but always a prompt when loading a data file for the first time, (2) a fix to the FTIR data file (i.e. MCA type data) after the initial read that gets saved in the data file, (3) an offset that you apply each time you open a FTIR (MCA) data file session?

Can you actually confirm that the peak positions in the spectra are NOT correct. The spacing in the (sample) dmt files that I have from you from an earlier file are at 1.928467 cm-1 (which you think is correct?). I would think that your data range that you are hoping the see is a slightly different range in the spectral array - maybe something that was set in the viewer of the Agilent? The data file is pretty "set" in those numbers, meaning there's not a good alternate interpretation of those binary numbers... Unless you think the instrument itself was calibrated poorly and you have a different calibration you want to override with?

The MCA Spectra -> FTIR Support -> load IR Settings is for the background subtraction parameters, so won't adjust your FTIR x-axis. I presume you've done the MCA Spectra -> MCA View Options -> and selected "Spectrum" over "Bins" (otherwise you probably wouldn't have seen the wavenumbers to start with!). Looking at the Agilent loading code, the reader is extracting several binary bits for the spectrum, treating the first wavenumber as an integer, the number of points in the spectrum as an integer, and then the wavenumber step as a double precision float. I will look at the parameters in the file and see if we can find the correct interpretation of the spectrum from the data file... Cheers! S