7.1. Sanity checking your fitting model

ARTEMIS is complex and it is quite easy to make mistakes. Many common mistakes are obvious and discoverable by automated analysis of the fitting model. Before running a fit, ARTEMIS applies each of the following test to your fitting model. If any of them are triggered, the fit is halted and a (hopefully) useful error message is posted in the Log window. Think of this like ARTEMIS' spell checker!

Any problems that are found must be corrected before ARTEMIS will allow the fit to proceed.

Some of these tests can be disabled using the Fit ‣ Disable sanity checks menu in the Main window.

  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.

As a side note, item 15 is particularly interesting. DEMETER does a simple lexical analysis on the ensemble of math expressions defined on the GDS window, then uses a formal graph theory tool to develop a graph depiction of the parameters. Loops (like the first example) and cycles (like the second) a trivially evident when the parameters are viewed as a formal graph. That was a really fun part of DEMETER to write.



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.