Revise TAP algorithm to give higher priority to pre-peak events

[rachel3834]

Based on observations in OMEGA-II so far, TAP appears to be very conservative in choosing events to observe that are prior to the event peak. This seems to be due to the higher uncertainty on the calculated priority value, since this is a factor in the selection.

So I have revised the TAP priority functions TAP_priority.check_planet_priority and TAP_priority.check_long_priority to have a looser criterion on the priority uncertainty as a ratio of the priority itself.

Please monitor this change in progress (deploying now) and consider revisions.

[mpgh]

criterion3 (mag_baseline-mag_now>2) is preventing us from requesting observations based on varying survey quality. For an unblended event, lensing zone would be more around 0.3.

[KKruszynska]

I am reviewing how restrictive each criterion is for planetary events. I pre-selected the events by choosing the ones that are alive, are classified as microlensing and that are outside of the HCZ. This left 108 events.

The least restrictive criteria are:

• criterium 2 (planet priority / planet priority error) It leaves 59 events out of 108 for the strict one ( priority / priority_error > 3.) and 77 for the loosened one (priority - priority_error > 0.). Before the peak, only 3 events pass both strict and loose criteria.
• criterium 4 (baseline magnitude < 19.) It leaves 78 events out of 108.

Criterium 1 (priority > 10.) is fairly restrictive - only 8 events out of 108 events pass it. Criterium 3 (amplitude > 2 mag) is the most restrictive: only one event passes it (Gaia23cri).

Unfortunately loosening criterium 3 would produce only 2 events with the loosened criterium 2... We need to investigate more.

[KKruszynska]

This is a similar investigation of the long-priority criteria. There are five criteria:

• criterium 1: priority > 10; This is straightforward, it leaves 34 out of 108 pre-selected events.
• criterium 2: long priority / long priority error > 3 (strict) or long priority - long priority error > 0. (loose) The strict criterium leaves 52 out of 108 events, the loose one leaves 78 out of 108.
• criterium 3: quality of t_E, strict: t_E / t_E_error > 3. or t_E - t_E_error > 0. The strict criterium leaves 64 out of 108 events, the loose one leaves 87 out of 108.
• criterium 4: current_mag < 17.5 mag, this leaves 36 events out of 108
• criterium 5: reduced_chi2 < 20, least restrictive (to kick-out non-microlensing events); this leaves 105 events out of 108.

If we would use all criteria in their strict form (strict crit 2 and strict crit 3) we are left with 3 events that should be followed-up. If we loosen criteria 2 and 3, we are left with 12 events. Here is the list of the events:

OGLE-2024-DG-0011
OGLE-2024-BLG-0324
OGLE-2024-BLG-0280
OGLE-2024-DG-0001
OGLE-2024-BLG-0076
OGLE-2024-BLG-0014
OGLE-2024-GD-0006
OGLE-2024-BLG-0013
Gaia23dau
OGLE-2023-GD-0011
Gaia23cri
OGLE-2023-BLG-1267

[mpgh]

In the past we have considered the "price tag" of each event, i.e. how many hours 1m observing time were requested and how it compares with the total time allocation and the expected time-allocation per day modulo some downtime factor. This would be even more of an enhancement, but would ensure that we are requesting more if time permits and not drop events when enough time is available.

[KKruszynska]

I loosened the following criteria:

• planet priority:
  • criterium 4: (mag_now - mag_baseline > 2.) changed to (mag_now - mag_baseline > 0.3)
• long priority:
  • criterium 3: (t_E / t_E error > 3.) changed to (t_E / t_E error > 1.)

I ran into some issues with run_TAP, I will resume working on it asap.

[KKruszynska]

I fixed the run_TAP issue (it was issue number #154). Now I am trying to understand why it's not promoting OGLE-2024-DG-0011 event though is should meet long_priority check criteria.

[KKruszynska]

I loosened criterion 2 in both check_planet_priority and check_long_priority. Some of the events that are at baseline and are incorrectly marked as "Alive". I will return the pre-peak and post-peak priority check and add an amplitude criterium to long events.

[KKruszynska]

Okay, I made the following changes:

• in check_planet_priority:
  • criterion 2 pre-peak requires priority to just be larger than error, post-peak priority/error> 2;
  • criterion 3: now depends on the current magnitude, if the event is brighter than 17.5, the current amplitude threshold is 0.3 mag, if it's dimmer, the current threshold is 2 mag.
• in check_long_priority:
  • criterion 2 pre-peak requires priority to just be larger than error, post-peak priority/error> 2;
  • new criterion (criterion6): current amplitude larger than 0.3. I hope this helps mitigate the issues I noticed today after deploying the loosened criteria to MOP prod. I will monitor run_TAPs behaviour over the weekend.