Skip to content

Resolution lookup #188

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 12 commits into from
Jun 27, 2025
Merged

Conversation

mguthriem
Copy link
Contributor

This PR includes work to implement an existing partial support for a second instrument parameter dicitionary that contains tabular data. The focus was on doing this for TOF diffraction data from multibank instruments.

In this PR, I added the ability to load and save instprm format files that contain a tabular description of the instrument resolution in the form of (already supported) multiline input with each line consisting of 5 comma separated values.

Example entry for bank 1 (also see attached instprm file and matching dataset for testing purposes):

#Bank 1: GSAS-II instrument parameter file. do not add/delete items!
Type:PNT
beta-0:0.0235
fltPath:15.5729
alpha:0.986512012223
sig-1:66
2-theta:101.994
sig-q:0.0
sig-0:0.0
sig-2:0.0
Zero:0.0
difA:0.0
difB:0.0
Azimuth:0.0
Y:0.0
X:0.0
beta-1:0.03
Z:0.0
difC:6090.05
beta-q:0.0
pdabc:"""0.3048,   1884.0, 0.000000, 0.000000, 15.936936
 0.3063,   1893.4, 0.000000, 0.000000, 16.079854
 0.3079,   1902.9, 0.000000, 0.000000, 0.000000
 0.3094,   1912.4, 0.000000, 0.000000, 0.000000
 0.3109,   1921.9, 0.000000, 0.000000, 0.000000
 0.3125,   1931.5, 0.000000, 0.000000, 0.000000
 0.3141,   1941.2, 0.000000, 0.000000, 0.000000
 0.3156,   1950.9, 0.000000, 0.000000, 0.000000
 0.3172,   1960.7, 0.000000, 0.000000, 0.000000

...

 4.9776,  30765.7, 0.000000, 0.000000, 201.683656
 5.0025,  30919.6, 0.000000, 0.000000, 202.692075
 5.0275,  31074.2, 0.000000, 0.000000, 203.705535
 5.0526,  31229.5, 0.000000, 0.000000, 204.724063
 5.0779,  31385.7, 0.000000, 0.000000, 205.747683
 5.1033,  31542.6, 0.000000, 0.000000, 206.776422
 5.1288,  31700.3, 0.000000, 0.000000, 207.810304
 5.1544,  31853.0, 0.000000, 0.000000, 208.811250
 5.1764,  31994.7, 0.000000, 0.000000, 209.739876"""
Bank:1

It is mandatory that the number of entries for all lines is identical and all entries are expected to be readable as floats. The data are loaded into a dictionary with keys : "d", "TOF","alp","bet","sig", each with a list of values.

This dictionary is then included in the instprm1 dictionary with the key pdabc, allowing possible extension of instprm1 with other future entries.

Functions accepting the original instprm as a single dictionary have been modified to accept both instprm and instprm1 dictionaries as separate parameters. Some functions already accepted instprm as a list of two dictionaries, these were left as is.

So far, the only use of the new dictionary, with the pdabc entry, is the interpolation of an additional additive term in the TOF sigma parameter calculation. This term is determined via interpolation of the tabulation of instprm1["pdabc"]["sig"] according to the d-spacing of the reflection. However, this could be extended to have much broader usage.

Notes:

  1. I also uncommented the HStrainShift which prevented the eA and d11 parameters having any effect during refinenemtns
  2. I kept encountering bank ID's being saved as float values. I don't know where these become float, but have now hardwired these to be integer when saving an instprm.
  3. saving the pdabc entry is currently only implemented in the function OnSaveAll, not in the function OnSave.
  4. An if statement that precluded refinement of DIFC, DIFA, alp-1,-bet-0 etc. when pdabc data are present was disabled as the intention - with the current implementation - was to refine these values and to treat the resolution table as an additive contribution to peak profile, allowing the other params to still be refined.
  5. In keeping with the majority of other instprm keys, I chose the key "pdabc" all lower case

Test data:
pdabc.zip

mguthriem added 5 commits May 29, 2025 13:35
…r to every function that previously had as a parameter parmDict, a large dictionary of refinable parameters that contains the original histDict
@mguthriem mguthriem marked this pull request as draft June 11, 2025 15:26
@mguthriem mguthriem marked this pull request as ready for review June 11, 2025 15:31
@briantoby
Copy link
Collaborator

@vondreele I am going to ask Bob to look at this. I suspect the conflicts are because he also fixed the hstrain bug.

@vondreele
Copy link
Collaborator

vondreele commented Jun 16, 2025 via email

@mguthriem
Copy link
Contributor Author

Hi both, thanks for looking over this, just let me know if I need to change anything :)

@briantoby
Copy link
Collaborator

I have brought this up-to-date with the current GSAS-II release (this PR was pretty far behind), looking fairly carefully to make sure that the changes here are pretty much the same as what Malcolm added originally. Self-tests work, but that is pretty much only testing for gross syntax errors. I think this is ready for a merge, but:

  • @mguthriem could you check that this PR branch still handles the resolution lookup computation correctly?
  • @vondreele could you review the changes?

@briantoby briantoby requested a review from vondreele June 25, 2025 16:16
@briantoby briantoby added enhancement New feature or request ORNL Bug or need identified/requested by ORNL user/staff Done? Probably complete, but not yet closed labels Jun 25, 2025
@vondreele
Copy link
Collaborator

vondreele commented Jun 25, 2025 via email

@mguthriem
Copy link
Contributor Author

@briantoby sorry if I used an out of date starting point for my edits cand caused extra work! Anyway, once I figure out how to pull your branch I will run it locally with my SNS data. Thanks.

@mguthriem
Copy link
Contributor Author

@briantoby I tested your commits and confirmed the following:

  1. loading multibank data where the instprm contains a resolution lookup table works.
  2. Refinements with said data work. The terminal reports d,sig, sigtable and total. The value for sigtable matches the table in the instprm.
  3. setting powder pattern units to d-spacing does not create the min() arg error (THANK YOU!!!)
  4. The d-range remains constant when swapping between histograms (AGAIN THANK YOU!!!)
  5. At some point this error appeared:
GPX load successful. Last saved with GSAS-II revision #5815, v5.4.8 git 750f8280
Traceback (most recent call last):
  File "/gpfs/neutronsfs/instruments/SNAP/shared/Malcolm/code/GSAS-II/pixi/.pixi/envs/default/lib/python3.12/site-packages/wx/core.py", line 3427, in <lambda>
    lambda event: event.callable(*event.args, **event.kw) )
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/gpfs/neutronsfs/instruments/SNAP/shared/Malcolm/code/GSAS-II/GSASII/GSASIIdataGUI.py", line 8873, in SelectDataTreeItem
    G2plt.PlotPeakWidths(G2frame)
  File "/gpfs/neutronsfs/instruments/SNAP/shared/Malcolm/code/GSAS-II/GSASII/GSASIIplot.py", line 3214, in PlotPeakWidths
    data = G2mth.setPeakparms(Parms,Parms2,T,Z)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/gpfs/neutronsfs/instruments/SNAP/shared/Malcolm/code/GSAS-II/GSASII/GSASIImath.py", line 5129, in setPeakparms
    Pdabc = Parms2['pdabc'].T
            ^^^^^^^^^^^^^^^^^
AttributeError: 'dict' object has no attribute 'T'

I'm not sure what it's impact is. Refinements could continue.
6. I was able to save a multibank instprm pdabc entry was present.
7. I was able to load a fresh dataset using the output instprm.

So, other than the error above, it seems to be working.

@briantoby
Copy link
Collaborator

71ae6ac should address error message 5 in above.

I think this error occurred when plotting peak widths. You might confirm this before updating by opening the .gpx and selecting the "Instrument Parameters" tree item and confirm that this produces the error. If you update and the error goes away (and I hope the alpha & beta values look correct) then my fix was correct.

@mguthriem
Copy link
Contributor Author

I pulled the latest version (71ae6ac) and the error changed:

Traceback (most recent call last):
  File "/gpfs/neutronsfs/instruments/SNAP/shared/Malcolm/code/GSAS-II/pixi/.pixi/envs/default/lib/python3.12/site-packages/wx/core.py", line 3427, in <lambda>
    lambda event: event.callable(*event.args, **event.kw) )
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/gpfs/neutronsfs/instruments/SNAP/shared/Malcolm/code/GSAS-II/GSASII/GSASIIdataGUI.py", line 8873, in SelectDataTreeItem
    G2plt.PlotPeakWidths(G2frame)
  File "/gpfs/neutronsfs/instruments/SNAP/shared/Malcolm/code/GSAS-II/GSASII/GSASIIplot.py", line 3214, in PlotPeakWidths
    data = G2mth.setPeakparms(Parms,Parms2,T,Z)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/gpfs/neutronsfs/instruments/SNAP/shared/Malcolm/code/GSAS-II/GSASII/GSASIImath.py", line 5130, in setPeakparms
    alp = np.interp(dsp,Pdabc[0],Pdabc[1])
                        ~~~~~^^^
KeyError: 0

@briantoby
Copy link
Collaborator

ok, my attempt to fix this by looking at code in another routine failed. I'd better do this in a more systematic way. Could you e-mail me the .gpx file?

@briantoby briantoby merged commit ce60e5a into AdvancedPhotonSource:main Jun 27, 2025
@briantoby
Copy link
Collaborator

These changes had an unintended consequence, since the call signature for errRefine changed, all calls to that needed to be updated. I have done that, but in many places the new histDict1 array was not available so I passed {} as a placeholder, but obviously computations in those places will not give the right result when the width table is used with TOF (~5 places each in testDeriv and GSASIIstrMain, see 41c552b).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Done? Probably complete, but not yet closed enhancement New feature or request ORNL Bug or need identified/requested by ORNL user/staff
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants