10.2. Sanity checks

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. Check that any files associated with the data or the FEFF calculations exist.

  2. Check that all guess parameters are used in at least one def parameter or path parameter.

  3. Check that no def parameter or path parameter uses an undefined parameter.

  4. Check that none of these typos appear in any math expressions: ++, --, //, or ***

  5. Check that all function names used in math expression (i.e. a word followed by parentheses) are valid functions in IFEFFIT or LARCH (as appropriate). ARTEMIS does not make any check that the arguments of the function are sensible, however.

  6. Check that all GDS parameters have unique names.

  7. Check that parentheses match in all math expressions, i.e. that every open parenthesis has a matching close parenthesis.

  8. Check that Fourier transform and fit parameters are sensible (for example Rmin < Rmax) for all data sets.

  9. Check that the number of guess parameters is less than Nidp.

  10. Verify that Rmin≥ Rbkg for data imported from an ATHENA project file.

  11. Verify that Reff for each path is not well beyond Rmax. The margin beyond Rmax that a value of Reff is acceptable is set by Rmax, plus the value of ♦Warnings→reff_margin.

  12. Check that various compiled-in limits (e.g. maximum number of paths or maximum number of set parameters) in IFEFFIT are not exceeded. This check is ignored when using LARCH.

  13. Check that parameters do not have the same names as IFEFFIT program variables. For example, things like pi or dr1 are not allowed since IFEFFIT uses those strings for other purposes. Although not strictly necessary, this check is enforced by default when using LARCH.

  14. Check that there are no unresolved merge parameters. This feature is not yet implemented.

  15. Check that GDS math expressions do not have loops or cycles in their definitions. For example, either of the following would trigger this error.

    guess x = x  # a nod to Laurie Anderson fans....

    guess a = b
def   b = c
def   c = a

  16. Check for obvious cases of a data set used more than once.

  17. Check that each data set used in the fit has at least one path assigned to it.

  18. Check that each Path object has a way of computing its contribution, i.e. has an associated ScatteringPath object or is a valid pathlike object.

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.



DEMETER is copyright © 2009-2016 Bruce Ravel – This document is copyright © 2016 Bruce Ravel

This document is licensed under The Creative Commons Attribution-ShareAlike License.

If DEMETER and this document are useful to you, please consider supporting The Creative Commons.