search

astrorama / SourceXtractorPlusPlus

SourceXtractor++, the next generation SExtractor
https://astrorama.github.io/SourceXtractorPlusPlus/
GNU Lesser General Public License v3.0
72 stars 9 forks source link

Strange error values when using the gls minimizer #345

Open mkuemmel opened 3 years ago

mkuemmel commented 3 years ago

When using the gsl minimizer. There are some cases when the error values are all NAN (blank in the pic) and sometimes the error values are all 0.0, which also makes not much sense: gslI Very occasionally only one of the error values is NAN, such as mag_err here: gslII Note that in all those objects no flags were set and the # of iterations is >1. The zip file below contains the FITS from which the screenshots were made. The image was a cutout of a large galaxy in FIELD0 of the Euclid morphology challenge (Double Sersic).

gsl_minimizer.zip

marcschefer commented 2 years ago

Did we ever look into that?

mkuemmel commented 2 years ago

Not to my knowledge.

marcschefer commented 2 years ago

Then we should for the version after this one.

mkuemmel commented 2 years ago

I can run a test to see whether this still happens.

mkuemmel commented 2 years ago

I am running now with gsl. There is tons of:

2021-12-06T14:04:09CET ModelFitting WARN : WorldToEngine ExpSigmoidConverter: world values outside of possible range 2021-12-06T14:04:09CET ModelFitting WARN : WorldToEngine ExpSigmoidConverter: world values outside of possible range 2021-12-06T14:04:10CET ModelFitting WARN : WorldToEngine ExpSigmoidConverter: world values outside of possible range 2021-12-06T14:04:10CET ModelFitting WARN : WorldToEngine ExpSigmoidConverter: world values outside of possible range

It was not like that in October when running with gsl and pyston on the version then. Maybe this is due to the meta iterations?

marcschefer commented 2 years ago

Yes, I have fixed those "value outside range" to now be warnings and not stop the fit, the parameter value is clamped to the value you specified in the configuration.

Still it means one of the parameters is going outside of range which is not ideal but is configuration-dependent.

mkuemmel commented 2 years ago

Okay, but I did not change the boundaries or so in the python configuration files. So it is not clear why they show up now.

mkuemmel commented 2 years ago

Just to give the scale of that, in the levmar runs that warning appears 2 times, in gsl, 1/3 through the processing, it appeared 41000 time (same dataset of course).

mkuemmel commented 2 years ago

I checked into this. The error values are almost all filled now. If they are not filled then fmf_flags is in almost all cases 1024, which is a general error flag for the fitting. In those case usually fmf_stop_reasons usually is 7. It tried to decipher these values, but I am not sure. If they are defined in gsl_errno.h it means sanity check failed. Looks like that this problem does not appear right now. But, I am rather worried about the warnings mentioned above: 2021-12-06T14:04:10CET ModelFitting WARN : WorldToEngine ExpSigmoidConverter: world values outside of possible range The number of those warning is higher than the number of objects. The 'normal' fmf_stop_reasons is 2 which would be 'output range error'. If this is true, this is a bigger problem that could camouflage the strange error values, simple since the fits don't finish.

How should we proceed, opening another ticket for the Warnings above?

marcschefer commented 2 years ago

I don't see the point of having a ticket for the warnings, they are working as intended.

As for what reason the GSL fit is behaving weirdly in this case, I don't know. I put this in the 0.17 milestone, as honestly I don't think we have time to investigate this for 0.16.

mkuemmel commented 2 years ago

Fine with me. levmar is behaving well, no reason to emphasize this for 0.16.