DQR link in the RRT view should be linked to DQR 5-minutes tier URL

While we are discussing this link, would there be a way to make it less hardcoded / more configurable / editable? On playground, the link is currently constructed the same way than on production, whereas the DQR runs on replayed events from the MDC, meaning that the DQR output URL is different from the equivalent one if the S-event were coming from O4a production.

For instance: on the page https://gracedb-playground.ligo.org/superevents/S230907nt/view, the DQR link suggested by GraceDB is https://ldas-jobs.ligo.caltech.edu/~dqr/o4dqr/online/events/202309/S230907nt, whereas the right one is https://ldas-jobs.ligo.caltech.edu/~dqr/o4dqr-test/replay/events/202309/S230907nt: "o4dqr" replaced by "o4dqr-test" and "online" by "replay". Things would be even more confusing in the case a S-event ID would exist both on production and playground: the playground DQR link would work but... point to an existing but completely independent production DQR!

The DQR which runs obviously knows what the right URL for its outputs is. Taking the same playground S-event as example, there is the log message

Log Comment Data Quality Report launched at CIT, see URL https://ldas-jobs.ligo.caltech.edu/~dqr/o4dqr-test/replay/events/202309/S230907nt Submitted by DQR Task on September 7, 2023 14:42:39 UTC

Would it be possible to have one such message trigger the display of the right URL in the

| DQR | [Data Quality Report] |

row of the Rapid Response Information table in GraceDB?

would there be a way to make it less hardcoded / more configurable / editable?

It is possible, but in the absence of a simple mapping to DQR results from non-production GraceDB tiers, I'm reluctant to put in hooks and exceptions to support playground activities.

IMO the RRT information table is there to support follow-up for production triggers, not to make playground investigations more convenient. If you disagree, please make the case and put these comments in a separate issue.

I'll make another issue if I see a way forward for it.

If the production URL baseline for DQR (I mean the string https://ldas-jobs.ligo.caltech.edu/~dqr/o4dqr/online/events) is hardcoded somewhere in GraceDB, I would disable the display of the Data Quality Report link in non-production instances of GraceDB as this URL would be almost certainly wrong, and in some cases misleading.
You did not comment on whether the DQR itself could send a comment (a command) to GraceDB to tell it which URL to display. That would work for all GraceDB and DQR instances, avoiding any hardcoded string.

You did not comment on whether the DQR itself could send a comment (a command) to GraceDB to tell it which URL to display. That would work for all GraceDB and DQR instances, avoiding any hardcoded string.

That is possible, but is a low-priority item given limited development cycles. If you feel that feature will substantially reduce RRT response time, then please make the case in the new issue, elevate it, and assign it to another RRT member familiar with GraceDB development (@sushant.sharma-chaudhary?).

@nicolas.arnaud Is anyone looking at DQR of events in playground? I see Alex already took care of the production side of things in his MR. I absolutely necessary I can take a look on creating conditional for different URLs between production and playground

I would think so @sushant.sharma-chaudhary . The MDC is a good place to test changes to the DQR -- at least that's what we are doing on the Virgo side. More globally, I would say that one should try to avoid providing a link that is known to be (very) likely wrong.

And, as I wrote above, the best way to solve this once and for all should be not to hard-code any path like in line https://git.ligo.org/computing/gracedb/server/-/blob/c489033ea4678d9203a47348c137d7996da9d81c/gracedb/superevents/templatetags/rrt_info.py#L11, but rather to rely on the DQR itself to tell GraceDB what the right URL is for the DQR. Take any event for which the DQR_REQUEST label was applied -- for instance https://gracedb.ligo.org/superevents/S231001aq/view. You'll find a log message like

Log Comment Data Quality Report launched at CIT, see URL https://ldas-jobs.ligo.caltech.edu/~dqr/o4dqr/online/events/202310/S231001aq Submitted by DQR Task on October 1, 2023 14:07:36 UTC

with the right URL. If GraceDB were able to get it from that message, that would be optimal as the link would always be the correct one. Though, I have no idea of the development that would be needed on GraceDB to make that happen.

@nicolas.arnaud if the URL is in the log message, and you're navigating to the superevent page anyway (which you would to see the RRT table), what's preventing you from following the link from the log message to investigate MDC events? Is it that using the RRT table for your playground investigations would be easier?

Me nothing as I'm a lead developer of the DQR, know that there is a potential problem and know that there should be log messages in the Data Quality section of the Log Messages. But what about others? The Rapid Response Information table is certainly read much more than the log messages sections...

And what would happen if for some reason the URL for the actual DQR changes? Would we need a new GraceDB release to get the right URL again?

Last question: is the function https://git.ligo.org/computing/gracedb/server/-/blob/c489033ea4678d9203a47348c137d7996da9d81c/gracedb/superevents/templatetags/rrt_info.py#L55-62 run each time a GraceDB S-event is loaded? What will happen if the fragment o4dqr becomes o5dqr for O5? Will the DQR links for O4 S-events still work (still display o4dqr) or will they include o5dqr?

the function gets run each time that the page is loaded, so if the fragment changes, then the link will change

So that means that, with the current implementation, we cannot have both the O4 and O5 DQR links working at the same time, as the fragments will certainly be different. This may not be a quick fix and require some development / more time, but the goal should be to find a solution more durable.

but the goal should be to find a solution more durable

I don't disagree, but I can't make this a development priority at the moment. The bulk of RRT development took place ahead of the run; since everything seems to be running smoothly, I need to focus on other development tasks and O4 maintenance and operations. If you feel that future-proofing for O5 should take priority, please elevate the issue or delegate it to another RRT/Detchar member.

I can certainly fork the package, edit gracedb/superevents/templatetags/rrt_info.py, update the code and then open a merge request, but I would not know how to first test the changes on my own, so that you don't have to debug the code. Would that nevertheless be acceptable for you?

Sounds good. As you're developing, you should bear in mind that:

you should have a way to fetch the specific log message that you want to get the URL from. this will be probably be from a log tag.
if there are multiple log messages with the same tag, then you should find a way to distinguish between the log messages, or modify DQR to apply a unique tag to to the specific log message that you want
there's a field on the log object called comment, which you should find a way to parse (regex?) to extract the url to pass to the RRT table

At least initially, I was thinking of something more modest, based on the fact that O4 should cover 2023 (S-event ID: S23something), 2024 (S24something) and possibly a tad of 2025 (S25something), while O5 would be later in terms of years.

But: do you have a working example of the following in the GraceDB code?

you should have a way to fetch the specific log message that you want to get the URL from. this will be probably be from a log tag.

And, is there a way in the code to know what GraceDB instance is currently running? Production / playground / test / etc.

At least initially, I was thinking of something more modest, based on the fact that O4 should cover 2023 (S-event ID: S23something), 2024 (S24something) and possibly a tad of 2025 (S25something), while O5 would be later in terms of years.

yep, it already parses the current year from the superevent id.

But: do you have a working example of the following in the GraceDB code?

Check out these lines.

And, is there a way in the code to know what GraceDB instance is currently running? Production / playground / test / etc.

Yes, the TIER variable is keyed to the name of the currently running instance, ex:

In [1]: from django.conf import settings

In [2]: settings.TIER
Out[2]: 'playground'

mentioned in commit 248ae5c1

mentioned in merge request !170 (merged)

mentioned in commit c489033e

mentioned in commit 94d26f23

Reviving that old discussion adding @derek.davis to the loop...

The DQR field of the superevent Rapid Response Team table is filled in the block https://git.ligo.org/computing/gracedb/server/-/blob/master/gracedb/templates/superevents/rrt_info_table.html?ref_type=heads#L123-128, while the get_dqr_status function is defined in https://git.ligo.org/computing/gracedb/server/-/blob/master/gracedb/superevents/templatetags/rrt_info.py?ref_type=heads#L55-62:

def get_dqr_status(sevent):

    # Is the DQR reqest label present?
    if sevent.labels.filter(name='DQR_REQUEST'):
       return mark_safe(dqr_link_format.format(yearmonth=sevent.created.strftime("%Y%m"),
           sid=sevent.superevent_id))
    else:
        return mark_safe("<span style='font-family: monospace;'>DQR_REQUEST</span> label not applied")

If the DQR_REQUEST label is not present it displays "DQR_REQUEST label not applied". That statement is right, but maybe DQRs have run anyway.
On the contrary, if the DQR_REQUEST label is present, it uses the hardcoded dqr_link_format = "<a href='https://ldas-jobs.ligo.caltech.edu/~dqr/o4dqr/online/events/{yearmonth}/{sid}/5_min_tier_index.html' target='_blank'>[Data Quality Report]</a>" (https://git.ligo.org/computing/gracedb/server/-/blob/master/gracedb/superevents/templatetags/rrt_info.py?ref_type=heads#L11) to try to guess what the CIT DQR URL should be. That guess may be right or wrong, depending on factors external to GraceDB -- mainly whether the URL fragment o4dqr/online is correct.

Yet, the correct DQR information is usually provided to GraceDB independently, via a comment in Log Messages / Data Quality:

Log Comment
Data Quality Report launched at CIT, see URL https://ldas-jobs.ligo.caltech.edu/~dqr/o4dqr/online/events/202401/S240107b
Submitted by DQR Task on January 7, 2024 01:37:55 UTC

Couldn't the action making that comment be expanded -- or its output be parsed in GraceDB --, so that the right URL (that only the DQR knows for certain) gets saved in a GraceDB variable which is read by get_dqr_status when called? That function would then work like that:

If the right URL GraceDB variable is present or has a content different from its init value, it is displayed in the DQR field of the superevent Rapid Response Team table.
Otherwise, get_dqr_status proceeds as currently implemented.

It sounds like a good idea to do it right once and forget forever. Even if there will be no RRT as we know in O5, displaying correct DQR URL on GraceDB is going to be useful. In addition, IF people want to run DQR on gracedb test or playground events (it's not totally unthinkable), showing a bogus URL that looks like a DQR for a production event will be a source of confusion.

@alexander.pace and @derek.davis , priority aside, is this something you're willing to consider? Should @nicolas.arnaud make a new issue?

@keita.kawabe

good idea to do it right once and forget forever

I find that very rarely are things consistent across observation runs, much less URLs for independent groups' analyses. But that's fine, making tweaks for new workflows is expected.

priority aside, is this something you're willing to consider? Should @nicolas.arnaud make a new issue?

I think it's fine to leave this issue open for discussion. But I can't promise that given limited person-power, development to make DQR's access to playground and test results more convenient is going to take a priority.

I understand your point. Let's keep this open for now, then. Thank you very much @alexander.pace.

DQR link in the RRT view should be linked to DQR 5-minutes tier URL

Child items ...

Activity