Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-10181

Generic (based on Jointcal) squash visualisation

    XMLWordPrintable

    Details

    • Type: Epic
    • Status: Done
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Epic Name:
      sqre-s17-jointcal-vis
    • Story Points:
      21
    • WBS:
      1.02C.10.02
    • Team:
      SQuaRE
    • Cycle:
      Fall 2017

      Description

      This epic covers work to visualise jointcal following DM-8477 by producing a generalised way to add new monitors to squash (eg. by developing a cookiecutter for monitor bokeh apps). This will allow further monitor visualisations to be added with minimal effort.

      For developer efficiency, this epic is blocked on DM-10178

        Attachments

          Issue Links

            Activity

            Hide
            frossie Frossie Economou added a comment -

            We decided not to pursue this work at this point since given the JupyterLab experiments we are going to look at potentially sharing or shifting bokeh visualisation to notebooks. The points in this epic were applied to DM-10387 instead.

            Show
            frossie Frossie Economou added a comment - We decided not to pursue this work at this point since given the JupyterLab experiments we are going to look at potentially sharing or shifting bokeh visualisation to notebooks. The points in this epic were applied to DM-10387 instead.
            Hide
            afausti Angelo Fausti added a comment -

            The Monitor App was extended to support multiple verification packages see e.g. https://squash-demo.lsst.codes We'll see jointcal measurements once jointcal data is flowing to SQuaSH.

            In https://sqr-009.lsst.io/ we propose two possible workflows:

            1) Developers could perform the verification measurements through the package tests. The results are then sent to SQuaSH via the stack-os-matrix job triggered by the developer when they test their development branches.

            2) Use specialized verification packages like validade_drp that execute the Science Pipeline Task of interest, each task produces its verification job with their metric measurements and the results are sent to SQuaSH after the execution of each Task.

            Show
            afausti Angelo Fausti added a comment - The Monitor App was extended to support multiple verification packages see e.g. https://squash-demo.lsst.codes We'll see jointcal measurements once jointcal data is flowing to SQuaSH. In https://sqr-009.lsst.io/ we propose two possible workflows: 1) Developers could perform the verification measurements through the package tests. The results are then sent to SQuaSH via the stack-os-matrix job triggered by the developer when they test their development branches. 2) Use specialized verification packages like validade_drp that execute the Science Pipeline Task of interest, each task produces its verification job with their metric measurements and the results are sent to SQuaSH after the execution of each Task.

              People

              Assignee:
              afausti Angelo Fausti
              Reporter:
              frossie Frossie Economou
              Watchers:
              Angelo Fausti, Frossie Economou
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Jenkins

                  No builds found.