Different calibration when choosing GaiaSP/any and GaiaSP/UBVRI

[kkotysz]

Problems occurring when choosing different calibration methods. Same filters are matched but with different slope and zero point values. Possible variable in leakage in CPCS code. This is a critical error which completely messes up the light curves of certain targets, e.g. ASASSN-24fs for ROAD data

[wyrzykow]

I think I have almost identified the problem here. I noticed there is a different number of stars used between these two sets. Hence, the Ra-Dec filter works differently and there is more noise in the cross-match, which results in different zeropoint and sigma. I still need to find it in the code. But I'm waiting for the test server to operate, otherwise it will be hard to test any fixes.

[astromiki]

Even though there are different stars taken into account these two measurements should be very similar, unlike what we are getting now. It shows both limitations of the method and plausible errors in the approach itself. I would focus on the crossmatching/filtering part.

[wyrzykow]

Found the problem, I think. In doSurvey, there is get_cat_query_result_filter_ra_dec, where the cat_mags are being extracted from the wsdb query. For any, all filters are taken; for forced filter, only one filter is used. But for UBVRI or ugriz, we should narrow down the cat_mags to only these columns. ` #this is for any: cat_mags = res[2:n_mag + 2] cat_error_mags = res[2 + n_mag:2 + 2 * n_mag]

Survey('GaiaSP', ['u', 'g', 'r', 'i', 'z', 'U', 'B', 'V', 'R', 'I'],

    if use_filter == 'ugriz':
        n_mag = 5
        cat_mags = res[[2,4,6,8,10]]
        cat_error_mags = res[[3,5,7,9,11]]
    if use_filter == 'UBVRI':
        n_mag = 5
        cat_mags = res[[12,14,16,18,20]]
        cat_error_mags = res[[13,15,17,19,21]]`

I have removed not used filters. It will be tested when the new code appears on the test server.

[wyrzykow]

Tested, fixed. Had to follow exactly the structure of wsdb query:

#                Survey('GaiaSP', ['u', 'g', 'r', 'i', 'z', 'U', 'B', 'V', 'R', 'I'],
#        0    1        2          3           4           5           6           7
# SELECT mag, magerr, u_sdss_mag, g_sdss_mag, r_sdss_mag, i_sdss_mag, z_sdss_mag, u_jkc_mag,
#         8          9          10         11         12              13              14      
#         b_jkc_mag, v_jkc_mag, r_jkc_mag, i_jkc_mag, u_sdss_mag_err, g_sdss_mag_err, r_sdss_mag_err,
#         15              16              17             18             19             20             21
#         i_sdss_mag_err, z_sdss_mag_err, u_jkc_mag_err, b_jkc_mag_err, v_jkc_mag_err, r_jkc_mag_err, i_jkc_mag_err,
#         22         23
#         mra, mdec, ra, dec 

cat_mags = res[2:n_mag + 2] cat_error_mags = res[2 + n_mag:2 + 2 * n_mag] if use_filter == 'ugriz': n_mag = 5 cat_mags = [res[i] for i in [2,3,4,5,6]] cat_error_mags = [res[i] for i in [12,13,14,15,16]] if use_filter == 'UBVRI': n_mag = 5 cat_mags = [res[i] for i in [7, 8, 9, 10, 11]] cat_error_mags = [res[i] for i in [17,18,19,20,21]]

For ASASSN-24fs: https://bh-tom2.astrolabs.pl/dataproducts/data/223924/

wrong:

corrected:

[wyrzykow]

It worked on ASASSN-24fs examples, but still there are some issues with this for another target, Gaia19eyy. https://bh-tom2.astrolabs.pl/dataproducts/data/263360/ It freezes at IN PROGRESS.

[wyrzykow]

probably this is due to wsdb cache problem. But I leave the issue still open until I see it works for Gaia19eyy as well.

[wyrzykow]

Fixed, tested on Gaia19eyy - works! Ready to be moved from cpcs-test to prod!

[wyrzykow]

combining this issue with #185 it means we need to re-calibrate data from mid-May 2024.