-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Only send alerts for single IFO triggers that both pass alert threshold and are found in coincidence with grb #2
Comments
There is not a trivial solution since the external trigger may become known to RAVEN after the GW trigger has been passed to Approval Processor, and Approval Processor is designed to decide whether or not to process a GW trigger when it first learns about it. |
Hi, Could we consider simply having a patch to approval processor ignore single ifo results for now and then if someone needs to intervene manually they can do so? At least then we can upload to gracedb. thanks, Chad |
Yes, that is one approach, and in fact Deep has written code to do that. I
assume that needs a quick review and then can be deployed.
Peter
…On Fri, May 19, 2017 at 11:36 AM, chadhanna ***@***.***> wrote:
Hi,
Could we consider simply having a patch to approval processor ignore
single ifo results for now and then if someone needs to intervene manually
they can do so? At least then we can upload to gracedb.
thanks,
Chad
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKdlWcEd5ymTdGLRUb1Jt-Tc9N-qmUk3ks5r7bcSgaJpZM4NDVX1>
.
|
Ok. Great. Can we move forward on this? Looks like we are about to have
a stretch of llo only time.
…On May 19, 2017 12:49 PM, "Peter Shawhan" ***@***.***> wrote:
Yes, that is one approach, and in fact Deep has written code to do that. I
assume that needs a quick review and then can be deployed.
Peter
On Fri, May 19, 2017 at 11:36 AM, chadhanna ***@***.***>
wrote:
> Hi,
>
> Could we consider simply having a patch to approval processor ignore
> single ifo results for now and then if someone needs to intervene
manually
> they can do so? At least then we can upload to gracedb.
>
> thanks,
>
> Chad
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#2#
issuecomment-302736544>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-
auth/AKdlWcEd5ymTdGLRUb1Jt-Tc9N-qmUk3ks5r7bcSgaJpZM4NDVX1>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AF78Xjl-mMGppZYwiLtbr0Obo87n3gqHks5r7cgEgaJpZM4NDVX1>
.
|
We will have to make a case to Patrick -- will one of you talk to him? The
policy up to now has been that even minor changes to the Approval Processor
code have been in the queue behind the major changes that Mina has been
working on. But I would think he would be agreeable to deploying this
simple change this week.
Peter
…On Fri, May 19, 2017 at 1:14 PM, chadhanna ***@***.***> wrote:
Ok. Great. Can we move forward on this? Looks like we are about to have
a stretch of llo only time.
On May 19, 2017 12:49 PM, "Peter Shawhan" ***@***.***>
wrote:
> Yes, that is one approach, and in fact Deep has written code to do that.
I
> assume that needs a quick review and then can be deployed.
>
> Peter
>
>
> On Fri, May 19, 2017 at 11:36 AM, chadhanna ***@***.***>
> wrote:
>
> > Hi,
> >
> > Could we consider simply having a patch to approval processor ignore
> > single ifo results for now and then if someone needs to intervene
> manually
> > they can do so? At least then we can upload to gracedb.
> >
> > thanks,
> >
> > Chad
> >
> > —
> > You are receiving this because you commented.
> > Reply to this email directly, view it on GitHub
> > <#2#
> issuecomment-302736544>,
> > or mute the thread
> > <https://github.com/notifications/unsubscribe-
> auth/AKdlWcEd5ymTdGLRUb1Jt-Tc9N-qmUk3ks5r7bcSgaJpZM4NDVX1>
> > .
> >
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#2#
issuecomment-302754587>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AF78Xjl-
mMGppZYwiLtbr0Obo87n3gqHks5r7cgEgaJpZM4NDVX1>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AKdlWajXl_PdowypOPEP19wptzfcLrgNks5r7c3_gaJpZM4NDVX1>
.
|
I will ping him
…On May 19, 2017 1:31 PM, "Peter Shawhan" ***@***.***> wrote:
We will have to make a case to Patrick -- will one of you talk to him? The
policy up to now has been that even minor changes to the Approval Processor
code have been in the queue behind the major changes that Mina has been
working on. But I would think he would be agreeable to deploying this
simple change this week.
Peter
On Fri, May 19, 2017 at 1:14 PM, chadhanna ***@***.***>
wrote:
> Ok. Great. Can we move forward on this? Looks like we are about to have
> a stretch of llo only time.
>
> On May 19, 2017 12:49 PM, "Peter Shawhan" ***@***.***>
> wrote:
>
> > Yes, that is one approach, and in fact Deep has written code to do
that.
> I
> > assume that needs a quick review and then can be deployed.
> >
> > Peter
> >
> >
> > On Fri, May 19, 2017 at 11:36 AM, chadhanna ***@***.***>
> > wrote:
> >
> > > Hi,
> > >
> > > Could we consider simply having a patch to approval processor ignore
> > > single ifo results for now and then if someone needs to intervene
> > manually
> > > they can do so? At least then we can upload to gracedb.
> > >
> > > thanks,
> > >
> > > Chad
> > >
> > > —
> > > You are receiving this because you commented.
> > > Reply to this email directly, view it on GitHub
> > > <#2#
> > issuecomment-302736544>,
> > > or mute the thread
> > > <https://github.com/notifications/unsubscribe-
> > auth/AKdlWcEd5ymTdGLRUb1Jt-Tc9N-qmUk3ks5r7bcSgaJpZM4NDVX1>
> > > .
> > >
> >
> > —
> > You are receiving this because you commented.
> > Reply to this email directly, view it on GitHub
> > <#2#
> issuecomment-302754587>,
> > or mute the thread
> > <https://github.com/notifications/unsubscribe-auth/AF78Xjl-
> mMGppZYwiLtbr0Obo87n3gqHks5r7cgEgaJpZM4NDVX1>
> > .
> >
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#2#
issuecomment-302760329>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AKdlWajXl_
PdowypOPEP19wptzfcLrgNks5r7c3_gaJpZM4NDVX1>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AF78XsIK5lhKQBgAoK-qQZWQS-ii5_BJks5r7dH7gaJpZM4NDVX1>
.
|
Deep and I talked yesterday about the status of this. The initial approach will not work. He is looking at a different, and probably more sustainable approach, which we will go over this afternoon and hopefully discuss a patch tomorrow morning. |
I was asked to open a PR about this so there's an official record somewhere. This is just a request to modify AP to only label single IFO gracedb uploads with ADVREQ if they
It looks like Raven already updates event logs with information about possible coincidences (see e.g. https://gracedb.ligo.org/events/view/T276080, under "External Coincidence"), so I believe the only change needed on the approval processor side will be differentiating between single and double IFO candidates, looking for this information from raven if a single ifo candidate, and then a conditional that describes when to apply the advreq label.
The text was updated successfully, but these errors were encountered: