Skip to content

segments-web 2 - if a flag has multiple versions, should v. 1 of a flag be selected by default? (discussion)

Created by: robertbruntz

During a DetChar telecon in which the beta version of segments-web 2 was discussed, regarding flags with multiple versions, someone asked why v. 1 of a flag is selected by default, rather than the highest version available.

It might be good to document:

  • How should version 2 and higher of a flag be handled
  • How do users handle version 2 and higher of a flag

Scenarios for how version 2 and higher are handled can be split up based on the questions 'how are segments in the past handled?' and 'how are segments in the future handled?', where past and future are relative to the creation of the new flag version. In the past, are v. 1 segments which aren't being modified by v. 2 copied over to v. 2, or only modified (v. 2) segments published for v. 2? In the future, is v. 1 published by default and v. 2 only intermittently, or does publishing for v. 1 end and all new publishing is done to v. 2?

Some possible scenarios:

  1. Version 2 is published only for times needing modification; version 1 continues to be published. (Note that this would require versionless queries, to include both versions 1 and 2 in the results, and results are not guaranteed to be reproducible, since segments could be published into any of the past gaps in version 2 at any time, which would change the results of queries over the same time span.)
  2. Version 2 is published only for times needing modification, but version 1 is no longer published; all new segments are published to version 2. (Note that this has the exact same problem as the previous scenario, except that the uncertainty is limited to the times before version 2 was started - which probably doesn't make it that much better.)
  3. Version 2 is a duplicate of version 1, except for the times that need to be modified, which are version 2; version 1 is no longer published; all new segments are published to version 2 (until/unless a version 3 is started, etc.). (Note that this removes any ambiguity, and queries are always reproducible (as long as they're only over past times; an end time in the future will produce different results as new segments are published).)
  4. Version 1 is continuously published; version 2 is regularly (or irregularly) published as a modified version of version 1 or replacement for version 1. Example: Virgo science mode flag (V1:ITF_SCIENCE:1 or :2); from https://wiki.ligo.org/Main/O3ScienceModeFlags : "Version 1 -- ":1" -- is produced online while version 2 -- ":2" is the offline flag to be used for offline analysis. The version 2 is created irregularly about once a month and covering about an additional month each time." (View 'known' segments from detchar-cit like this: "/home/detchar/dqsegdb/query_segments.sh segments V1 ITF_SCIENCE 1 0000000000 1300000000 known" and "/home/detchar/dqsegdb/query_segments.sh segments V1 ITF_SCIENCE 2 0000000000 1300000000 known".)
  5. Other possibilities?

So it seems that the decision as to whether v. 1 should be selected by default partly depends on how users typically use v. 2+.

Also, this raises the question as to whether a 'versionless query' option should be implemented.