Proper Handling of Background Term in Invariant Analysis

[butler]

We have recently seen a couple of issues with the invariant failing. These have been traced back to using too large a background term which is a user input field. The traceback error is not terribly helpful to the user and in fact this should not cause a failure unless perhaps if massively overestimated.

Lionel Porcar is now asking how the Invariant calculation handles negatives at high Q when subtracting background. This needs to be checked but could be the source of the above problem. If the data set is noisy and reaches background the subtraction will always produce some negative values. Decreasing the background till all points remain positive after subtraction is in fact incorrect!!! It will provide an overestimate of the invariant which could be substantial since q is large at this point.

Aside from ensuring a proper calculation, providing an automated background estimate as for Pr could be helpful. Also it may be useful for both invariant and Pr to allow for an array to represent the background for instruments (such as at pulsed sources) where the background may not be flat?

[butler]

Conversations with Richard Heenan and Andrew Jackson leads to the conclusion that we in fact should not worry about a Q dependent background and instead ensure the documentation makes clear that the data must be background subtracted to the point that any residual background must be Q independent.

Need to modify docs besides ensuring the code behaves correctly. These are computational and should be done sooner than later so part of 4.2 or 4.3 Adding an option to auto find the background should be a 5.0 task.

This ticket should therefore only refer to the first part. A new ticket to be created for 5.0 will address the auto background estimate.