Skip to content

PACE project objectives

Jump to bottom
Rebecca Fair edited this page Aug 1, 2019 · 2 revisions

Go back: Horace framework redesign ideas

PACE project objectives

From the PACE project brief (to be put online once sensitive information has been redacted):

  1. Parallelise HORACE for multiple core computers and distributed computing, particularly to operate on IDAaaS and SCARF. A Python as well as a Matlab interface to the code should be provided.
  2. Parallelise TobyFit under the framework of (1), and extend the TobyFit formulism to instruments with neutron guides.
  3. Parallelise SpinW.
  4. Computation of scattering function from ab initio calculations of phonons.
  5. Develop an API for third-party modelling codes so they can interface with HORACE / TobyFit. Interfaces to SpinW and CASTEP to be implemented as an example of this API. User written code can be in either Matlab or Python, and should be able to take advantage of parallelisation.
  6. Construct a GUI "workbench" for data analysis, especially fitting with resolution convolution.
  7. Mantid-based handling of powder data including resolution convolution, modelling and fitting capabilities of PACE.

Further details

  • The minimum proposal (from AB) which would satisfy objective (1) is:

    • Write an additional C++ mexed class which wraps an MPI library to provide internode/interprocess communications between (compiled) Matlab instances.
    • Pro: Easiest to implement (AB estimates 6 person-weeks).
    • Pro: If using compiled Matlab for child nodes, will not need parallel toolkit license or additional normal Matlab licenses (just license for master Matlab process).
    • Pro: If the main process uses a compiled Matlab instance through Python, no licenses will be needed at all.
    • Con: Compiled Matlab needs a 1G runtime to be installed on each node.
    • Con: Python interface to compiled Matlab code is fragile and doesn't work in some instances (e.g. returning structures of classes).
    • Con: May be slow (will need to benchmark prototype) - but won't know for sure until it's implemented.
    • Con: Will need special set-up of continuous automation software (server will need Matlab installed and a license).
    • Most of the cons also apply to everything but a complete rewrite of Horace in Python or C++ so may not be such a disadvantage.

  • The original project plan envisaged rewriting the core of Horace in Python/C++ but this is implicit rather than specified in any objective or deliverable. The PACE project documentation only specifies that a Python interface should be provided. If this interface uses compiled Matlab, it would probably take approximately 1 person-months to implement and debug (MDL estimate).

  • Regarding objective (5) within this minimum model, Matlab can, in principle, call Python functions and vice versa (Python calling Matlab functions) although the data has to be converted before hand. This will introduce some overheads but it is unclear how significant this would be.

  • Objective (2) is being actively worked on by GT (and in principle TGP and MDL but this has been put in abeyance).

  • Objective (3) is not being actively worked on. It was hoped that ESS effort would be used for this but none has so far been forthcoming.

  • Objective (4) is the Euphonic project

  • Objective (5) and (6) are not being actively worked on.

  • Objective (7) includes the MSlice sub-project of Mantid but is also not being actively worked on.

Go back: Horace framework redesign ideas

Clone this wiki locally