Kvec talks to isodistort

[Kvieta1990]

I added in the capability to communicate with the isodistort server after the k-vector search in GSAS-II. Once we get the searched k-vector table, we can select either of the k vectors in the table and click on the button to talk to isodistort.

Currently, I am only outputting all the CIF files corresponding to all the isotropic subgroups associated with the selected k vector. The next step will be to incorporate those CIF files into independent GSAS-II project file, which I may need help from @briantoby

N.B. For the moment, I am outputting all the CIF files into os.getpwd(). Not sure whether this is the optimal solution. Also, after the output is done, I am having a message box saying the job is done and include the output path in the message box. However, it seems the path in the message box would be wrapped up and I don't know the way to control the message box window size so that the path can be displayed in a single line.

Here is the file that we can use for testing and further development.
Ba6Co6_nuc_refine.gpx.zip

[briantoby]

The routine GSASIIphsGUI...OnApplySubgroups() shows code that creates multiple .gpx files.

• Line 4168 saves the current project.
• Then I delete sections of the project that would not be correct after the phase is updated (this is probably not needed if a magnetic phase will be added rather than replacing a phase).
• The code inside the loop replaces the phase
• Once the loop is done (line 4250) the .gpx file saved in 4168 is reread
• The _ShowPhase routine opens the data tree to the previously displayed location so the user see the same info as previously displayed.

Note that G2frame.GSASprojectfile is the name of the current .gpx file and G2frame.LastGPXdir is the directory where that file was saved. There is also a path, G2frame.dirname but I'm really not sure what that is used for. At one time we tracked a directory where data would be read from (for example with tutorials). I'm not sure if that still works, but that might be what G2frame.dirname is all about.

[briantoby]

As far as message box goes, I think you are referring to wx.MessageBox which is somewhat unpredictable. It uses a native widget to Linux, Windows and Mac can all behave differently (and probably different on different flavors of Linux.) To deal with that, I plan to change GSASIIctrlGUI.G2MessageBox to create its own window, but I have not gotten around to that.

You can use GSASIIctrlGUI.ShowScrolledInfo, where you can control the size of the window (but it does wrap text that is too wide for the supplied width). It would not be that hard to add an option to ShowScrolledInfo to turn off text wrapping or perhaps a routine to create a window that scrolls and does not wrap. I don't think one would want to make the window expand to fit the text (in case the text is really long).

[Kvieta1990]

Thanks a lot Brian for your comments! I will work further on this branch and I will let you know when the PR is ready for you to check again before merging into master. Thanks!

[briantoby]

If you need any help, please ask

[Kvieta1990]

Got the project generated successfully but it seems that the phase in the new generated project file is not changed. Not sure why. will keep working on this.

[briantoby]

I have made changes but was prepared to test them. I think this will now rename the phase properly in the data tree for the created .gpx files. Please let me know if there are any non-obvious bugs that I have created

[Kvieta1990]

Hi @briantoby Just a quick update on this. I have been working on the tutorial concerning this PR. As I am working on this, I found something more on the implementation side to work on,

• Isodistort server seems to be updated and some of the URL no longer works. Fortunately the change on the isodistort side is pretty consistent so the adjustment the GSAS-II side is not that much.
• For the tutorial, I was using a cubic system and when using it for talking to the isodistort server, I realize that the parameters that we need to pass to the isodistort server are dependent on the crystal system since the name for the k vector passed to isodistort will change. This means I may have to create an exhaustive list of those k vector names for all the possible cases. Or, possibly, I can try to see whether we can extract such a list from isodistort intermediate output.
• For specific crystal systems, e.g., the cubic one I was playing around with now, some of the k-vectors are equivalent, e.g., (1/2,0,0) is equivalent to (0,1/2,0) and (0,0,1/2). By default, isodistort only lists out one of them and this is also something we need to adapt to, according to their convention.

It may take some time longer than I was expecting, but I will try my best to do this as soon as I can.

[Kvieta1990]

turns out I have a lot to work on...we can talk about this tomorrow and I will show you what the problem is and my intended solution (which needs a lot of work).

[Kvieta1990]

@briantoby I just finished all the implementations regarding this PR, including,

• Talking to ISOCIF to upload and export a CIF compatible with some of the downstream routines.
• Figuring out which format the provided k-vector is in, regarding the list of acceptable k-vector format by ISODISTORT. Thanks to the help from Prof. Branton Campbell, I wrote the Python routine for looping over all the k-vector arms, search for the compatible format with the ISODISTORT list of options, and solving the parameters to be populated into the ISODISTORT input boxes.

I will need to do some testing and probably some debugging. I will then give you an update once the implementation turns out to be working fine.

[Kvieta1990]

@briantoby Hi Brian, I believe the PR is ready to be merged. I finally debugged the communication to the new ISODISTORT server. I sent Branton and you an email about this. Basically, it is about the new interactive plot capability that was recently added in ISODISTORT -- when trying to make requests to the server, having the button there in the request would cause permission deny.

Anyhow, given the current form of the PR, I did a local test and things are working as expected.

Could you please help review the code to see whether you are happy with it? I already pulled in all the new commits from the main branch so a clean fast-forward merge is straightforward, meaning my branch is purely ahead of the main and all the new commits are k-vector related.

Please feel free to let me know if you have any comments. Thanks a lot!