Fixed order in iteration variables and constraint equations in MFILE

[jonmaddock]

In GitLab by @Hlux on Jul 17, 2017, 14:38

At the moment, mfile_comparison.py that is used to e.g. compare files in the test_suite, compares itvar, nitvar and xcm, which are the value of the iteration variables/normalised iteration variables and constraint equations, numbered by the order given in IN.DAT. However, in_dat.py has a fixed output order for the iteration variables and that might differ from generally created user orders. Hence, different IN.DAT files with a different ordering will lead to discrepancies in the mfile_comparison tool, even if both give the same physical results. To avoid this, PROCESS should always output iteration variables and constraint equations in the same order they appear in the vardes file.

Additionally it would be helpful to add a check to mfile_comparison whether the first(/all) iteration variables/constraint equations have the same label.

[jonmaddock]

In GitLab by @mkovari on Jul 18, 2017, 08:33

See also Issue #472, "Improved OUT.DAT".

Hanni's request will also make it easy to check if the same iteration variable appears twice!

[jonmaddock]

In GitLab by @mkovari on Jul 19, 2017, 12:55

Numerous variables are output more than once by PROCESS. Our convention (not always followed) is that occurrences after the first should have a dot after the name, for example '(rmajor.)' It would make sense to modify the output routines to omit these from the MFILE automatically.

This avoids cluttering up the MFILE, and prevents other scripts such as make_plot.py from writing things twice where they really shouldn't.

[jonmaddock]

Currently, if optimisation parameters are defined in different orders in two input files, the mfile_comparison.py tool will register differences in the optimisation parameters even if the values are the same (e.g. itvar001 will correspond to different optimisation parameters in each mfile).

What is required is an ordering of the optimisation parameters in the array by optimisation parameter number (e.g. ixc = [7, 3, 9] becomes [3, 7, 9]. Provided that other arrays requiring the same order (e.g. xcm, bndl and bndu) are also ordered in the same way, this should fix the problem.

I can think of two solutions to this. The first is to use in_dat.py to read in, order, write and then read in again the ordered optimisation parameters. This is obviously ugly.

The second is to sort the optimisation parameters once they've been read in from the input file, which is a better solution.