GEM - Umbrella Ticket

[Peter Parker]

An "umbrella" ticket for any work to be done for GEM.

First task is to liaise with Alex Hannon to see what needs to be done.

[Peter Parker]

Nick and I met with Alex on 2013/11/08:

• Alex highlighted his current ability to understand and modify the code as something he did not want to lose. For this reason, a full conversion of the existing Fortran code to Python/C++ was rejected. Using F2Py to wrap it and call it from inside Python was seen as the best compromise.

• Nick made it clear that there were limitations in using F2Py:
  • Only Windows would be supported.
  • The "top layer" that is currently called by OpenGENIE would have to be changed to accommodate calling from inside Mantid.

• Alex suggested that some code to convert standard OpenGENIE workspaces to/from Mantid workspaces would be useful. Nick in agreement.

• Alex has sent me his current code, as well as details about how to access GEM data and how to run it using OpenGENIE.

[Peter Parker]

I spoke with Alex again on 2013/11/25 and cleared up a few misconceptions I had about the nature of the codebase for GEM:

• The code he provided included, amongst other things, the code for the program "GSQ", but was not the entire codebase. GSQ is the most commonly used GEM program on the beamline and was decided as a good starting point for us.

• The code did NOT include any Fortran. There is Fortran code being used on GEM, but only for computationally intensive parts that were not included.

[Nick Draper]

bulk move to assigned at the into of the triage step

[Stuart Campbell]

This ticket has been transferred to github issue ​9212