24.2 Design and implementation

FieldConvert utility in Python was designed to provide the user with an easy workflow. Hence, a minimum effort is required to set up the conversion and the majority of work is done behind the scenes.

This section will discuss the design of the utility, including the description of work yet to be done, as well as the user workflow required to execute the basic conversions.

24.2.1 FieldConverter class

The entire procedure outlined in the original FieldConvert utility is managed by the FieldConverter class located in utilities/FieldConvert/Python/FieldConvert.py. The class has the following attributes:

• fieldSharedPtr: a shared pointer to the field, necessary to initialise a module;
  • TO-DO: FieldSharedPtr type remains to be wrapped.
  • TO-DO: Whether a separate FieldSharedPtr is needed for each module initialisation needs to be discussed.
• moduleFactory: would be equivalent to GetModuleFactory() in the original utility;
  • TO-DO: Whether this is possible needs to be discussed.
  • TO-DO: It would be best to wrap the general template NekFactory and initialise a module factory this way.
• availableModuleList: holds a list of available modules in order to assert that the modules requested by the user are available;
  • TO-DO: PrintAvailableClasses method needs to be wrapped.
  • TO-DO: It would definitely be neater if the available modules existed as an enum rather than just strings containing names.
• sessionFile, inputFile, outputFile: hold the necessary filenames;
• moduleList: holds a list of Module objects, created as requested by the user;
• variableMap: equivalent of vm variable from the original utility.
  • TO-DO: This variable map needs to be constructed from user input as it needs to be passed into Process method of Module class.

24.2.2 User workflow

The currently suggested user workflow is as follows:

1. Initialise an instance of FieldConverter class.
2. Add a session file as well as an input and an output file.
   • The converter will assert that the session file and the input file exist, assert that the file extensions are supported and create appropriate modules.
3. Add any modules, e.g. vorticity.
   • Currently the argument passed into addProcessModule is a string containing the module name.
   • TO-DO: As mentioned before, it would be neater if said argument was an enum.
   • TO-DO: Some more thought is required about how to support modules requiring or permitting parameters. One solution would be to pass a tuple containing module name and parameters. Care needs to be taking in asserting the validity of parameters.
   • As before, the converter will assert that the module exists and create an appropriate Module class object.
4. Run the conversion.

The code showcasing the suggested workflow can be found in the main function of the FieldConvert.py file.

24.2.3 Conversion process