Opened 11 years ago
Closed 9 years ago
#46 closed defect (fixed)
Error messages when a two-stage fit fails after first stage
Reported by: | Daniel Craik | Owned by: | Thomas Latham |
---|---|---|---|
Priority: | trivial | Milestone: | v3r1 |
Version: | Keywords: | ||
Cc: |
Description
When a two-stage fit fails after the first stage, a number of error messages are produced: Error in <operator()>: Request column(17) outside matrix range of 0 - 17
It looks like the covariance matrix is only large enough for the first-stage parameters but we still try to calculate for all of the fit parameters.
Change History (4)
comment:1 Changed 11 years ago by
Milestone: | → v3r1 |
---|
comment:2 Changed 10 years ago by
comment:3 Changed 9 years ago by
Owner: | set to Thomas Latham |
---|---|
Status: | new → assigned |
comment:4 Changed 9 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
(In [321]) Check the size of the covariance matrix wrt known number of parameters and act accordingly:
- If it is empty, just fill a diagonal correlation matrix and issue a warning.
- If it results from a failed first stage of a two-stage fit then the correlation matrix is padded with 1s and 0s for the parameters that were fixed in the first stage.
closes #46
Note: See
TracTickets for help on using
tickets.
The problem occurs in LauFitNtuple::storeCorrMatrix because the covariance matrix passed into the method as the 4th argument does not contain the second stage parameters. This method is called by the various implementations of LauAbsFitModel::finaliseFitResults which is, itself, called by LauAbsFitModel::fit and LauAbsFitModel::fitSlave.
This only happens when the fit has failed in the first stage so one fix would be to not make the call to LauFitNtuple::storeCorrMatrix (and perhaps other things) if fitStatus!=3. (Do we need it if the fit has failed anyway?)
Alternatively, LauFitNtuple::storeCorrMatrix could be modified to check the size of the covariance matrix it is given and pad the correlation matrix out with 1s and 0s. This seems more robust against future changes but also introduces unnecessary lines of code.
From reading the code, it looks like a similar (but perhaps more serious) error might occur if parameters are floated only in the first stage of the fit.