Project

General

Profile

Actions
Copy link

Bug #323

closed

MATCHing fails in MOSAIC_TYPE LOOSE mode on some platforms

Added by Emmanuel Bertin about 8 years ago. Updated about 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Emmanuel Bertin
Start date:
05/14/2014
Due date:
05/14/2014
% Done:

100%

Estimated time:
2.00 h
Spent time:
2.00 h

Description

SCAMP user J.Kleyna reports

I'm having some problems with scamp. It work great on a Mac (OS X 10.7.5, gcc 4.2.1 LLVM build 2336.1.00), with 246 sdss-r7 stars and a small ~0.2" RMS on the appended catalog.
On x86_64 Linux Gentoo 2.6.28, it works for 90% of catalog files in a mosaic set, but 10% of files don't give a valid fit; it finds just a few astrometric stars, with a big (2") rms. The mosaic chip that fails to fit varies from exposure to exposure.
I tried SCAMP versions 2.0b6, 2.01 (release), 2.01 (SVN HEAD).
The same sex.cat and scamp.conf files were tried on both systems, and the same retrieved catalog directory was used.

Actions
Copy link
 #1

Updated by Emmanuel Bertin about 8 years ago

Jan Kleyna identified the origin of the bug in function crval_to_crpix() of mosaic.c:

I think I found the problem. In mosaic.c there is a function crval_to_crpix(wcs,wcspos) that shifts a WCS to a new slightly offset wcpos center.
This function computes an angle change to North:

angle=(dlng!=0.0 && dlat !=0.0) ? (complicated trig expression) : 0.0;

However, this trig expression gives invalid values for tiny dlng,dlat, where angle should be zero, because (I think) two big terms cancel in addition to give zero, and the cancellation is subject to numerical error. An angle that is 360.00 (ie, zero) on a Mac is 366 on Linux, and this throws the initial WCS off, so SCAMP isn't able to match stars.
I suggest as an alternative
angle=(fabs(dlng)>1e-8 && fabs(dlat)>1e-8) ? (complicated trig expression) : 0.0;

This ignores shifts smaller than 1e-8 degrees (a tiny fraction of an arcsec), while ensuring that at least 6 digits >of precision are available for the trig calculation.
This solution worked for my data set, and all my images got a good WCS on Linux, when there was a 10% failure rate >before. Perhaps one or another compiler did or did not do some clever trig reorganizations.
It's possible that similar instabilities exist elsewhere in the code.

Actions
Copy link
 #2

Updated by Emmanuel Bertin about 8 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

I propose a slightly different fix in r326 (SCAMP v2.0.2) that solves the issue with the example provided by Jan:

angle = (fabs(dlng)>1e-10) ?
    (atan2(sin(wcspos[lat]*DEG)*cos(dlng*DEG)
            - cos(wcspos[lat]*DEG)*tan(wcs->crval[lat]*DEG),
        sin(dlng*DEG))
    + atan2(sin(wcs->crval[lat]*DEG)*cos(dlng*DEG)
            - cos(wcs->crval[lat]*DEG)*tan(wcspos[lat]*DEG),
        sin(dlng*DEG)))/DEG

Actions
Copy link
 #3

Updated by Emmanuel Bertin about 8 years ago

  • Status changed from Resolved to Closed
Actions
Copy link

Also available in: Atom PDF