Closed tomlunderwood closed 1 month ago
@tomlunderwood this should be added by #78. I also needed to vary degeneracy for paper 1. It's a bit more subtle than the other parameters since if it's not set then the FEFF path value is implicitly used as you point out. It seemed to work OK for me but again feel free to verify if you want, otherwise I'll let you know when it's released and installed on prod.
@patrick-austin thanks for your work on this. The functionality is what I need for paper 8. However I noticed a bug in the new functionality. I'll close this issue and raise the bug as a new issue.
Reproducing the EXAFS fits in paper 8 (https://github.com/MaterialsGalaxy/larch-tools/issues/33) doesn't seem possible with the current Galaxy tools for a couple of reasons. The current set-up allows a lot of flexibility with regards to the free parameters which can be varied during the fitting. E.g. the quantities 'S02' and 'E0' can be fixed to a user-defined value during the fitting, varied during the fitting but constrained to take the same value for all selected FEFF paths, or varied during the fitting and allowed to take different values for all selected FEFF paths. However, more flexibility than is currently provided in the Galaxy tools is required to reproduce the exact fitting procedure used in paper 8.
To elaborate, each FEFF path has a 'degeneracy' associated with it, something which reflects the number of equivalent instances of the path in the local environment of the absorbing atom in the system of interest (as represented by a cif file). This is referred to as the coordination number (CN) in the paper, and corresponds to the variable 'n' in larch (while, e.g. 's02' refers to S02 in larch -as can be seen in a GDS file). Currently in Galaxy 'n' for each selected FEFF path is implicitly fixed during EXAFS fitting, and takes the value deduced by FEFF from the cif file (see the 'deg' quantity in a 'CSV summary of paths' file generated by Larch FEFF to see what this value is for a given path). I cannot see how to change this behaviour. However, in paper 8, and in Abraham's Jupyter notebook (https://github.com/UK-Catalysis-Hub/XAS-Workflow-Demo/blob/main/psdi_phase_1/larch/Paper%2008%20Reproduce%20XAS.ipynb) where he attempts to reproduce the EXAFS fits in that paper, the values of 'n' are not fixed in the fitting procedure; they can vary, and moreover are allowed to take a different value for each selected path, something I deduced from looking at the GDS files in Abraham's repository. The result is that Galaxy cannot obtain fits as good as paper 8, since parameters allowed to vary in the fitting procedure used in the paper are always fixed in Galaxy.
Hence I request that in the 'GDS variable defaults' for the 'Larch Select Paths' tool an extra box is added allowing the user to control whether or not to allow 'n' to vary in the fitting, similarly to as is currently possible for 'S02'.
Interestingly, there is a workaround which exploits the fact that in the functional form for chi(k) used for the fit 's02' and 'n' appear as a product 's02n', and noting that 's02n' is the key quantity in the fit rather than 's02' or 'n' separately - getting 's02n' correct is what matters. Hence allowing 's02' to vary during the fit while keeping 'n' fixed - something currently possible in Galaxy - can potentially yield the same value for 's02n' as the procedure used in the paper, namely keeping 's02' fixed while varying 'n'. However this is not entirely satisfactory since, while you may obtain a good fit doing this, the values for 's02' and 'n' obtained from the fit will be unphysical. Of course one could correct for this 'hack', but I think this is beyond what we should expect users to do.