| Comments |
| 9/17/2013 4:43:43 PM |
Bob Denny |
|
| 9/17/2013 3:55:48 PM |
Bob Denny |
|
| 9/17/2013 3:52:31 PM |
Bob Denny |
Oops, needed same B1.0 logic for southern stars in the usnonet catalog logic. |
| 9/16/2013 2:01:05 PM |
Bob Denny |
B1 problem fixed. Now only R1 required, filtering by R1, no B1/V is OK. Flux from R1. |
| 9/16/2013 1:25:30 PM |
Bob Denny |
Still open in 2013, but I read back over the Comm Center thread (huge!) and found that, apart from a tracing bug, the problem related to a corrupted UCAC3 catalog that John had!
Now to fix the B1.0 problem reported by Paulo. This one is simple. It's filtering on the asynthesized V mag, which requires both B1 and R1 mags to compute. I will filter on R1 mag only and allow stars that have no B1 mag to pass throuogh, just with no B1 or suynthesized V mag in "Magnitude" (which will now be R not synth'd V). |
| 7/13/2011 2:55:21 PM |
Bob Denny |
|
| 7/12/2011 2:18:35 PM |
Bob Denny |
Brute-force test completed, where UCAC3 stars were looked up at intervals of 0.25 deg dec and 0.0125 hrs RA from -90 to 90 dec and 0-24 ra, a total of 1,038,962 points. Only two places with 0 stars found in a 20 x 20 arcmin field: RA=16.47 hrs DE=23.75 deg and RA=4.60 hrs Dec=26.25 deg |
| 7/12/2011 2:11:58 PM |
Bob Denny |
Email received from Paulo:
Hi Bob,
I noticed that the number of USNO B1 stars per field retrieved by PinPoint
(assuming a fixed field size, e.g., 1.5 deg x 1.5 deg, and a fixed limiting
magnitude, e.g., 16) drops sharply south of dec ~ -33 deg. This led to difficulties
to solve some fields at dec ~ -34 deg with USNO B1, which solved easily with
USNO A2.
Using the USNO B1 query at Vizier, I saw that the number of USNO B1 stars
which have the first B magnitude between 1 and 16 (there are many stars with
first B magnitude equal to 0.0, which are not valid magnitudes, so I excluded
them) per field drops sharply south of dec ~ -33 deg, for any R.A. But the number
of USNO B1 stars which have the first R magnitude between 1 and 16 is much
greater than the corresponding number of the first B magnitude, and the
number of stars with first R magnitude between 1 and 16 per field does not
decrease at dec ~ -33 deg.
So USNO B1 has plenty of stars south of dec ~ -33 deg but PinPoint is retrieving
only a small fraction of them. The only explanation I could propose for this
is to assume that PinPoint essentially selects the stars which have valid first B
magnitudes brighter than the limiting magnitude specified by the user. Is this
correct or reasonably correct?
The selection by PinPoint of a small fraction of the catalog stars seems to be
causing an effect similar to using USNO SA2 instead of USNO A2, for fields south
of dec ~ -33 deg. The pattern of the reference stars becomes difficult or
impossible for PinPoint to recognize, often leading to bad or failed plate solutions.
So USNO B1 becomes problematic to use south of dec ~ -33 deg. Since there are
plenty of stars in the catalog south of dec -33 deg, it seems to me that a change
in the magnitude criterion which PinPoint uses for retrieving stars from USNO B1
could be made to include the stars with valid R magnitudes, so that the artificial
drop in star density south of dec ~ -33 deg would disappear. Then USNO B1 would be
a good catalog for use all over the sky, which is what one expects of it.
Best,
Paulo
|
| 7/12/2011 11:01:09 AM |
Bob Denny |
The other attachment (only 1 per post) |
| 7/12/2011 10:59:05 AM |
Bob Denny |
Two new attachments: test scripts. A brute force test of the engine with UCAC3 over -90 to 90 in 0.25 steps, and 0.2h to 24h in 0.2h steps revealed only one 20x20 arc-min field with no stars at RA=4.6h DE=26.25d. |
| 7/12/2011 8:07:08 AM |
Bob Denny |
|
| 7/11/2011 6:14:53 PM |
Bob Denny |
This was a stupid bug in the desperation debug tracing. Users will never see this, but it's fixed. |
| 7/11/2011 2:02:18 PM |
Bob Denny |
John's test program makes PinPoint act sick. Scripting the same thing, or doing it from my own C# prog, seems no problem. This could get ugly. |
| 7/11/2011 1:52:28 PM |
Bob Denny |
In order to match stars with CDS (etc.) searches, I have mapped the catalog J, K, and "UCAC Aperture" magnitudes through the PinPoint Blue, Ultraviolet, and Infrared magnitude properties (previously unused). This is a hack! Eventually, additional magnitude properties should be added to the PinPoint API. See link to PINPOINT-665. |
| 7/11/2011 12:36:09 PM |
Bob Denny |
Looking like a real pain to find and fix. Heisenbug with catalog tracing too! Increased estimate to 24 hours. |
| 5/26/2011 4:44:01 PM |
Bob Denny |
Larry owings has also seen this. |
| 5/13/2011 5:19:11 AM |
Bob Denny |
Here's another probable issue relating to the same thing. David Higgins notes a hiuge change in the number of cat stars for a tiny change in coordinates. Unless there's an open cluster nearby, this looks really fishy. |
| 5/11/2011 12:03:59 PM |
Bob Denny |
Attaching a complete repro scenario package. In his note he says:
When you run it, after getting through the setup messages there should
be a message reporting poor star coverage after about 30s, then the
app exits some 60s later, neither of which should happen.
If you switch the catalog type to B1.0 (plate.Catalog = 8) then after
about 2 mins runtime pinpoint returns the "The specified resource name
cannot be found in the image file." exception.
|
| 3/11/2011 2:07:21 PM |
Bob Denny |
Attaching the test program used by John to discover this. |
| 2/20/2011 7:37:18 PM |
Bob Denny |
Berg says it affects A2.0 as well! Elevating this to high priority. |
