Even small modifications to EWD or XNS should be followed by (more or less) automatic validation step. The
xns CVS module includes cases directory
Cases and script
Validate. Older scripts
<arch> can be
crayt3e, are also still available.
The steps required are:
- Make sure that
Cases/dallas.0153etc. directories are present and that they contain required mesh files.
Validateand modify two lines at the top that define old and new release name, like
R1204a. These will become a suffix to the newly-obtained log files. For just testing the current XNS and not committing it, the new release name should be set to
nonewhich disables saving the new log files. The old release name will be used to try and locate log files from a previous validation run, in the work directories. If this is a first validation run, one can comment out the
difflines; note that in this case we will not be able to compare new results to any old results.
- It simplifies debugging of later releases to save the XNS executable with the release suffix, e.g.,
- Start 8 PE interactive job if necessary and run the script. On the RZ Xeon or Bull cluster, small interactive MPI jobs can be run from the command line with
mpiexecand it is not necessary to interact with the job system.
- This will run all the validation cases in sequence (less than 30 s per case), stopping after each of them and comparing new log to an old log. Scroll through the
diffoutput, ignoring slight timing differences. There should be no differences other than timing, or the second line in the log file that contains the date. If there are differences in residual history, make sure you know where they come from, or start debugging! If some cases slowed down dramatically, that also needs to be explained. It is not necessary to justify dramatic speed-ups, should they occur.
Only following a successful validation, one should push major changes to the central Git branches, or tag a particular set of revisions.