Source Model Bugs: general

Bugs

1. After an error in the instrument stack, Sherpa returns an error while trying to define the source model.

2. In the case of any XSPEC model, or Sherpa model that is not analytically integrable, flux calculation is restricted to the instrument model grid.

3. If you set a notice filter on a PHA file that doesn't actually notice any data, then you cannot define a source expression.

4. If every parameter of a model is frozen, it is evaluated only once per fit; this affects every model when all parameters are frozen.

5. Sherpa will crash with a segmentation violation (SegV) if: (a) one uses gcc-compiled code (e.g., RH 6.2), (b) one uses an optimizer other than Levenberg-Marquardt, and (c) an error occurs (an exception is thrown) in statistic-computing code.

6. By default, Sherpa does not allow a model label to be reused in a model definition (unless an ERASE command is issued between uses).

Bugs

1. After an error in the instrument stack, Sherpa returns an error while trying to define the source model.

   Retyping the source command correctly defines the source model.

2. In the case of any XSPEC model, or Sherpa model that is not analytically integrable, flux calculation is restricted to the instrument model grid.

3. If you set a notice filter on a PHA file that doesn't actually notice any data, then you cannot define a source expression.

4. If every parameter of a model is frozen, it is evaluated only once per fit; this affects every model when all parameters are frozen.

   Changing the value of the parameter and refitting will have no effect on the fit results, since Sherpa doesn't necessarily reinitialize its internals if the filter is unchanged, etc. The first evaluation will remain through all subsequent other fits; i.e. as far as Sherpa was concerned, it never saw the parameter change.

   The same problem will occur if you freeze the parameter, then do a plot or fit (initialize internals), then thaw the parameter and fit again. Sherpa won't pick up the thawing.

   Workaround:

   issue the "ignore all" and "notice all" commands between every fit. Then Sherpa would reinitialize internals and pick up the model change.

5. Sherpa will crash with a segmentation violation (SegV) if: (a) one uses gcc-compiled code (e.g., RH 6.2), (b) one uses an optimizer other than Levenberg-Marquardt, and (c) an error occurs (an exception is thrown) in statistic-computing code.

   Why? Most Sherpa optimizers are written in Fortran, and the statistic computers are written in C++; there may be a bug in the gcc compiler which causes Sherpa to crash when it tries to recover after the error, as execution passes upwards through the Fortran optimization layer. This supposition is based on empirical data, and is not proven.

   The most likely way the user can cause such a crash is to use a model that evaluates to NaN, for whatever reason. The workaround for this is to change the initial parameter value guesses/settings by hand until the model evaluates to reasonable (finite) numbers.

6. By default, Sherpa does not allow a model label to be reused in a model definition (unless an ERASE command is issued between uses).

   However, if the label is a pre-defined Sherpa model name, no error message is seen, although the re-use is prohibited. This is best seen with an example:

   sherpa> gauss[g1]
   sherpa> gauss[g1]
   Error: g1 is currently being used in a stack definition.
   sherpa>
   ...
   sherpa> gauss
   sherpa> gauss
   sherpa>