PROCESS Improvement Strategy

In GitLab by @mkovari on Jan 7, 2020, 11:39

This is based on my note PROCESS strategy 2019.docx. The aim is to create a new improved version of PROCESS that is more numerically robust and physically self-consistent, easier to use, and better documented and referenced. It should also be easier for collaborators around the world to use it and improve it.

Structure and usability

1. Input interface

Two input interfaces have been created, written by Manoj and Tom Miller.

As far as I know Manoj’s interface will run but is not ready for use. It relies on all the input variables being described in a json file. So far as I know this file is not yet generated automatically, and is therefore not complete. The only other serious drawback is the lack of a global search. It uses QT and C++.

Tom Miller’s interface is not currently working. It relies on all the input variables being described in a python dictionary. This file is generated automatically by scanning the Fortran, and is also required by the other utilities. The interface has a global search feature. It uses Django, which is well-known but not in the PROCESS group.

In my opinion an input interface (a user interface to create the input file) is very useful. The Minimum Viable Product must be easier to use than the current method of using a text editor, so it needs the following features.
• Automatic updating whenever new input variables are added
• Robust
• Easy to maintain
• Global search.

Other features can be added later:
• Context data so that irrelevant variables are greyed out. (Some of this data is already included in Manoj’s interface.)

Another benefit of a suitably designed interface is that it can be extended to provide additional functions – see below.

2. Interface to run process and utilities
   It would be fairly trivial to create an interface to run process and the various utilities. The utilities in particular are easy to forget, and indeed we have several that have fallen out of use. The Minimum Viable Product would be as follows.
   • Menu with process.exe and all the python utilities
   • Folder selection for input file
   • Path selection for process executable and utilities.

Other features can be added:
• Menu-based input of configuration data.

3. Browser output

James has written a utility to create an html output file (output_detailed.py), but this is not in common use. This has many advantages over the text file OUT.DAT – it includes graphs and diagrams, colour, a contents page with internal links etc. It would be nice to explore this option further.

4. Programming interface

I have recently revised the way in which iteration variables are created, so that the labels and bounds and the code for packing and unpacking are all in a single block.

Creation of new input variables, figures of merit, constraints and scan variables is still tedious. An interface to make it easier for the developer to create any of these objects would be desirable.

The interface could then write the required Fortran code for new input variables, figures of merit, constraints and scan variables automatically (as in the meta-compiler currently under development), but this is not part of standard programming methodology.

An alternative may be to rewrite key parts of the code in a more powerful language that is capable of creating the required data structures during execution, and passing them to the Fortran code. This is hardly ideal either.

5. Data flow and modularity

Greater use of derived types may make it easier to pass the relevant variables to subroutines as arguments, although this may make parts of the code look more cumbersome. Note that this does not protect variables from being changed unexpectedly.

The sparing use of getters and setters may be justified to protect variables.

6. Version monitoring and the test suite

The test suite has been a major improvement in our workflow. It can be extended so that it exercises more of the code.

However, new algorithms can change the output in ways that may be difficult to understand. A tracking tool now exists for the DEMO baseline, but it is not integrated with the test suite, which has a rather basic output check. It would be good to see in more detail what effect each code revision has on all the test suite outputs.

7. Unit tests

The introduction of unit tests by Manoj, James and Ryan promises to be a major advance. Many more tests should be created, and the creation of new tests should be streamlined if at all possible.

Convergence and speed

8. Convergence

Create tools to help users make progress when the optimiser fails to find a design point that satisfies the constraints. We have made good progress in this in the past. Further tools could work by incrementally removing constraints, for example.

9. Speed

James has now set up profiling, discovering that there are some routines that run 5,000,000 times during the course of a single PROCESS run. I am fairly sure that the organisation of the code is inefficient and that this can be reduced.

In the longer term, we want to use more detailed physics models such as Plasmod and RABBIT. It would be good to design an architecture that allows these slower codes to be run less frequently, while still generating a self-consistent solution.

---

I know that we have had many discussions on improving PROCESS, but I think it is worth putting the key desiderata into one place, before we spend a great deal of time on details. @ajpearcey @jmorris-uk @jonmaddock @skahn @stuartmuldrew

No single implementation entry point or bounded deliverable is identified. Start by reviewing output_detailed.py, the process.exe and Python utilities interface, the test suite, and the DEMO baseline tracking tool mentioned in the issue. Done cannot be defined until one of these improvements is separately scoped with specific files, tests, and acceptance criteria.