Sanity checking the fitting model

A lot happens under the hood when the fit method is called by a Fit object. One of the first things that happens is an extensive series of sanity checks on the objects that make up the fitting model.

Here is the complete list of tests that are made on a fitting model:

1. If Data objects read directly from a column data file (rather than from, say, an ATHENA project file, all such data files included in the fit must exist.

2. If Path objects read directly from feffNNNN.dat files, all such files used in the fit must exist.

3. All guess parameters are used in at least one def parameter or path parameter.

4. No def or path parameters use parameters which have not been defined.

5. Binary operators are used correctly. This test specifically checks that none of these strings appear in a math expression:

      ++    --   //   ***   ^^
   

6. All IFEFFIT function names (i.e. strings that are followed by an open paren) are valid IFEFFIT functions.

7. All data and path objects have unique group attributes. (It is possible for a user to reset this attribute, although this is considered very bad practice.)

8. All GDS parameters have unique names.

9. All opening parens are matched by closing parens.

10. Data attribute related to fitting make sense, for example that fft_kmin is smaller than fft_kmax.

11. The number of guess parameters does not exceed the number of independent points.

12. The bft_rmin value is not greater than bkg_rbkg.

13. The R_eff of any path is not very far beyond bft_rmax.

14. IFEFFIT's hardwired limits on things like the maximum number of guess parameters and the maximum number of data sets are not exceeded by the fitting model.

15. No GDS parameters have the names of IFEFFIT program variables or other reserved words.

16. No merge parameters remain unresolved. Merge parameters are GDS parameters that are in naming conflict in a project that involves importing structural units or otherwise merging together elements of a fitting model. As of version 0.4, this is an unimplemented feature.

17. GDS parameter math expressions are checked to verify that they are neither self-referential nor part of a cycle of references, e.g.

    def a = b
    def b = c
    def c = d
    def d = a
    

If any of these sanity checks fail for your fitting model, the fit will not continue and a (hopefully) useful error message will be issued via DEMETER's error reporting system. For a script run at the command line, this error message is typically (and by default) issued to STDERR. For a Wx application, the warning text will normally be displayed in a dialog box or elsewhere. Disposal of the error text is left as a chore for the end-user application.

There are, as of version 0.4, several missing tests, including:

1. Test that every included Data object has at least 1 Path object associated with it.

2. Test that every Path object is associated with a Data object. This should be a warning, not an error. The unassociated Path can simply be ignored.

3. Test that each Data in the data array is properly defined.

4. Test that every Path points either to a ScatteringPath object or to a real path file.