Closed ycendes closed 8 years ago
can you run the same dataset but with the problematic range only and the image cache on? Then we can actually visually see what happens.
I will indeed but fair warning, nothing of note happens visually when this occurs. Sorry I forgot to mention that earlier.
Why not? It looks like at some point the source association branches into two running catalogs. Maybe there is some clear noise visible. Op 19 feb. 2016 12:08 a.m. schreef "ycendes" notifications@github.com:
I will indeed but fair warning, nothing of note happens visually when this occurs. Sorry I forgot to mention that earlier.
— Reply to this email directly or view it on GitHub https://github.com/transientskp/tkp/issues/497#issuecomment-185943674.
Ok, I re-ran a subset of 19 images and the results from that run are here: http://banana.transientskp.org/master/vlo_cendescandidateSB003/dataset/17/
The log files for the run are here on struis: /scratch/ycendes/aartfaac/candidate/candidate-pipeline/cendes-candidate-SB003/logs/2016-02-21T11:34:02
It turns out the association example here is even crazier than I thought at first glance- in these 19 images, there are 7 running catalogs generated for this one source! (Sort by RA, I'm referring to the one w an RA around 47-48 and Dec +50.) There is also a source with two running catalogs at 56.925 68.161 in this data set if you want a second example.
From further investigation, it seems like this is a peculiar AARTFAAC source, so this is not a TraP issue.
This was probably an issue in earlier on as well, but have only really noticed it now that I'm dealing with smaller data sets. In short, the source association does not appear to work well for some sources in AARTFAAC images- as an example, the following three running catalogs are all from the same TraP run, and are all the same source in actuality:
http://banana.transientskp.org/master/vlo_cendescandidateSB003/runningcatalog/5542/ http://banana.transientskp.org/master/vlo_cendescandidateSB003/runningcatalog/5543/ http://banana.transientskp.org/master/vlo_cendescandidateSB003/runningcatalog/5544/
I've done a few things to see if this changes as a result in the job_params file, but no dice. First, currently AARTFAAC runs are using force_beam= True because this more correctly models our flux, but I'm not seeing any effects between using a forced beam or not. Second, I increased the systematic error in both directions in various increments to 3600 (the AARTFAAC image uncertainty), but did not see any real effect in the running catalogs from this either.
I'm fine running a few other tests if it helps, just give a shout.