udaykiran19491/user-stories-from-tawos-for-llm-fine-tuning huggingface dataset:
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "{{afwDisplay.Display().mtv()}} assumes that it can always build a {{Wcs}} from the metadata in a {{DecoratedImage}} (that may once have been true, but it no longer is) and raises an exception if it fails.    Please fix this."
Answer: 1540.0

User story: "Run jointcal with the HSC-RC2 dataset, the w_2018_36 stack, with the following config overrides:      {noformat}  config.astrometryRefObjLoader.ref_dataset_name='ps1_pv3_3pi_20170110'  config.photometryRefObjLoader.ref_dataset_name='ps1_pv3_3pi_20170110'  config.astrometryRefObjLoader.filterMap={'B': 'g', 'r2': 'r', 'N1010': 'z', 'N816': 'i', 'I': 'i', 'N387': 'g', 'i2': 'i', 'R': 'r', 'N921': 'z', 'N515': 'g', 'V': 'r'}  config.photometryRefObjLoader.filterMap={'B': 'g', 'r2': 'r', 'N1010': 'z', 'N816': 'i', 'I': 'i', 'N387': 'g', 'i2': 'i', 'R': 'r', 'N921': 'z', 'N515': 'g', 'V': 'r'}  {noformat}    In the future, the config overrides won't be needed once DM-15606 is merged. "
Answer: 12.0

User story: "Session numbers, job numbers, and ACK_IDs use the Redis sequence capability for uniqueness. When the INCR instance values are incremented, a snapshot of the DB instance is taken. This must be read back in at DMCS startup in case the Redis Server was restarted during a reboot of somesuch. The work is all done except for changing the INCR scoreboard init method to ingest backup file rather than drop the tables as most other Redis instances do (and should). And it will need to be tested."
Answer: 664387.0

User story: "To see whether it improves the outlier rejection fraction, I'm going to increase the visit polynomial order by 2 (from 5 to 7) and see if that helps. It's just CPU time: don't have to make any real modifications to the execution scripts."
Answer: 4990.0

User story: "Write a prototype obs_metadata implementation that can translate FITS standard header cards for instrument, telescope and observation date."
Answer: 5466.0

User story: "Before finalizing DM-15646, we should get feedback from the DM developers on exactly what the interface should look like."
Answer: 5309.0

User story: "Please edit with the tickets to be reviewed."
Answer: 12804.0

User story: "In sufficient detail to be able to create a mock until actual services are deployed and ready.  This is going into DMTN-094."
Answer: 91420.0

User story: "Now that we have reliable output from jointcal+validate_drp, we need to compute the final summary statistics described on the [acceptance test|https://confluence.lsstcorp.org/display/DM/JointCal+Acceptance+Tests] page. This is probably most easily added as a final step of jointcal_compare's {{summarizePerformanceRst.py}}."
Answer: 3292.0

User story: "As is in obs_lsstCam, the {{raw_visit}} table in registry.sqlite3 has the same per-file informarion as the {{raw}} table. But it should be just the visit information for optimization in obs_base.     I think this is to fix {{config.register.visit}} in obs_lsstCam config/ingest.py          "
Answer: 3969.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Reprocess the HSC RC2 dataset, as defined in DM-11345, using Stack w_2018_38. Steps include {{makeSkyMap.py}}, {{singleFrameDriver.py}}, {{mosaic.py}}, {{skyCorrection.py}}, {{coaddDriver.py}}, and {{multiBandDriver.py}}. "
Answer: 26094.0

User story: "Building upon installations started in https://jira.lsstcorp.org/browse/DM-15298 , we test the server installation and configurations using Scitokens generated with the Demo Issuer at [https://demo.scitokens.org|https://demo.scitokens.org/] . "
Answer: 44940.0

User story: "Changes in gen3 butler need few updates for execution framework. I think that piece responsible for running the task should still work (but it has not been tested recently), but post-pre-flight part needs to do some additional work:   *  make sure that output collection exists in registry   * copy/associate (if needed) all input datasets into output collection, this probably needs to be done recursively   * provenance information (Quanta) needs to be saved in registry    I probably need more realistic examples of PipelineTask to properly test it."
Answer: 45680.0

User story: "This ticket is to describe the major design and implementation choices for the alert distribution system at the present time."
Answer: 37430.0

User story: "Started using this terminology informally on DM-15424, and it really clarified the docs.  Actually renaming the class would probably help even more, but belongs on another ticket (this one).     "
Answer: 134999.0

User story: "This ticket is to create a skeleton design document for Alert Distribution as a DMTN."
Answer: 7059.0

User story: "Implementation ticket for RFC-517."
Answer: 18762.0

User story: "Whilst working on DM-15653 it became clear that test code would be significantly simplified in places if more dunder methods were implements in PropertySet and PropertyList. This would also simplify the work on obs_metadata and make that less dependent on the LSST FITS header representation in DM-15646.    For this ticket dict-like dunder methods will be added as well as others such as eq."
Answer: 8993.0

User story: "A data ID with (camera, visit, sensor) keys may be enough to uniquely identify a Dataset, but we should expand it to include physical_filter (implied by visit) and abstract_filter (implied by physical_filter), both so we can consistently populate the Dataset table and so we can use the expanded keys in templates.    Note that we will also need to expand data IDs before transferring them (e.g. via a QuantumGraph after preflight) to a limited Registry, as the limited Registry doesn't have the necessary information to expand them itself.  That implies that the expansion should include attaching the region, because PipelineTask execution may want that region and limited Registry can't attach it either."
Answer: 168737.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: A comment on DM-12004 by  [~<USER> highlighted this sentence from the DPDD (Section 1.2):  {quote}After the ISR step is completed, the pixel values and their variance are not modified any more.  {quote}  This is probably incorrect; after ISR, a single-epoch image will have been flattened according to some SED, which may be:   * a flat or other simple analytic spectrum   * something that looks like a "typical" source for that band   * our best estimate of the spectrum of the sky    It is quite likely that we will un-flatten and re-flatten to other SEDs in later steps, because the first two are what we want to do photometry while the last is what we need to use when subtracting the background.  Whether the SED we've flattened with coming out of ISR is the same as the one we end up with depends on the sequencing of different photometric calibration and background-estimation steps, and that's TBD (and ought to be below the level of detail of the DPDD).    As the above suggests, we'll also be subtracting the background from the images.  While this (like any flattening) should be completely reversible, because of the interplay between flats and backgrounds, it's not as trivially reversible as it might seem.    In short, we should find a way to reword this section of the DPDD to not make unnecessary claims about when the pipelines will do what.
Answer: 417938.0

User story: "Create kerberos entity for authorization."
Answer: 2.0

User story: "This almost certainly will  not be the final version of this pipeline task, but start the conversion process. This will show what works still needs to be done and spawn appropriate tickets for the exposed work. It will also bring the task much closer to the final version, such that at the end there will be far fewer changes to be made."
Answer: 37602.0

User story: "Provide documentation from DAX team to try running Qserv in the cloud. Make sure [~<USER> and [~<USER> are connected with Jim and Robinson to work together as resident LSST k8s expertise."
Answer: 65832.0

User story: "Install GCS client on Qserv worker nodes at PDAC, prepare and transfer the dataset to cloud after cloud storage has been setup."
Answer: 16913.0

User story: Recent changes to l1dbproto's DiaObjectLast table have caused issues within ap_association. Since ap_pipe does not not currently utilize the full features of l1dbproto it seems safer to switch this default to "baseline" instead.
Answer: 5550.0

User story: "Instructions have been provided by the Google team for testing a transfer for our data files to different storage buckets. Test transfer performance from both NCSA and IN2P3 before moving the full datasets."
Answer: 21394.0

User story: This implements the commands csv2pq (convert csv file to a parquet file) and p2qcsv (convert parquet file to a csv file) in a full featured way (i.e. using a schema with many types which can have null values). These commands can be found in the repo: "https://github.com/lsst-dm/parquet_tools".
Answer: 674459.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story:  LSE-61 requirement DMS-REQ-0274 needs to be updated to be consistent with the update made in LSE-163 (DPDD) to articulate that an LSST alert packet will include only 12 months of DIASource history and not ", all previous DIASource records corresponding to the object"
Answer: 17.0

User story: "In DM-14503 support for YAML serialization of PropertySet and PropertyList was added to daf_persistence.  To allow gen3 butler to serialize these using YAML it makes sense to move the YAML support directly into daf_base.  This would require a pyyaml dependency on daf_base but we already use yaml in many places and it's in the core python dependency list. YAML support could be optional in the sense that it is only enabled if yaml can be found."
Answer: 3389.0

User story: "Try k8s node taint/toleration feature to keep k8s from scheduling non-qserv pods on qserv master and db nodes"
Answer: 5974.0

User story: "The “Data Management Control System” sounds like a key service which, one might assume, orchestrates the whole of Data Management. I've heard various highfalutin claims about what the DMCS might do.    In fact, I understand (based on LDM-152) that it's a tightly scoped part of the ingest system. That's fine, but, in an attempt to avoid future confusion, it'd be nice if LDM-148 made this clear."
Answer: 21809.0

User story: "DM-9358 fixes the flag setting logic for PSF determination.  The flawed logic was not being caught, so a test should be added to check this in CI.  The most likely place for this may be in ci_hsc (where the presence of these flags is being checked, but not the logic of what actually gets set)."
Answer: 22154.0

User story: "From: merra-questions [[<EMAIL>|mailto:<EMAIL>]] on behalf of Augustin Guyonnet     Using two tables from MERRA-2 website ([https://disc.gsfc.nasa.gov/datasets?keywords=MERRA-2&page=1&subject=Aerosols])  1) inst3_3d_gas_Nv (M2I3NVGAS): Aerosol Mixing Ratio Analysis Increments  2) inst3_2d_gas_Nx (M2I3NXGAS): Aerosol Optical Depth Analysis       The question is the following :  How the aerosols components from the 3D table ->  BCINC  DUINC  OCINC  SSINC  SUINC   Are related to the overall aerosol optical depth ->  AODANA     The answer was given by Arlindo Da Silva ([<EMAIL>|mailto:<EMAIL>]) :  AODANA contains the aerosol optical depth analysis which is a vertically integrated quantity. Related to the AOD are the 3D aerosol mass mixing ratios, a set of 15 3-D tracers: dust (5 bins), sea-salt (5 bins), bc (2 tracers), (oc (2 tracers) and SO4 (1 tracer). Denote these MMR simply Q_s for species “s”. The analysis QA consists of an increment QINC added to a background QF  (first guess field):     QA_s = QF_s + QINC_s for each s = 1, 15    Now, AODANA is simply the vertical integral of QA multiplied by appropriate mass extinction coefficient:    AODANA = Sum_s  (QA_s * BETA_s) * delp / g  where the sum is from s=1 to s=15,    Now,      DUINC = sum_s QINC_s,   where the sum is over the dust tracers only    And so on and so forth.             "
Answer: 6379.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "As decribed [on confluence|https://confluence.lsstcorp.org/display/DM/Observational+Metadata+Data+Structures+and+Extraction] we need a set of classes and methods for taking a PropertyList, extracting the relevant information and creating an object summarizing that information in a standard form. Cameras can implement their own subclasses to override specific information, with the intent to reuse code wherever possible when a header has the same definition across multiple cameras.    We have not yet decided whether this should go into obs_base or be a standalone infrastructure package."
Answer: 50414.0

User story: "Update LDM-533 with new test cases created in JIRA"
Answer: 52.0

User story: "Write the charge for the internal LSST Science Platform Review "
Answer: 127993.0

User story: "As part of the process that ingests raw AuxTel files into the Data Backbone, also ingest them into a single Gen2 repository accessible from LSP nodes, lsst-dev, etc.     This includes working with admins as well as making any needed softlinks, etc.       (Assumes someone else maintains a Gen2 ingest code for raw AuxTel files.)"
Answer: 769278.0

User story: "This ticket covers work associated with reviewing tickets and advising with regards to numpydoc conversions. Primarily for DM-15347."
Answer: 77741.0

User story: "Original ingestion process did not save science metadata (only basic location and provenance information).    Add gathering of metadata and storing of metadata to the raw AuxTel ingestion process."
Answer: 769283.0

User story: "- Presents the main concepts of the Honeycomb tool    - Illustrates an workflow where metrics values are collected, stored in SQuaSH and sent to Honeycomb for analysis    - In particular it creates a squash-demo dataset for the SQuaSH metrics, and uses liboney to send those metrics to Honeycomb, it shows how to use the Markers API for plot annotations and the Triggers API for configuring alerts based on metric specs obtained from the SQuaSH API."
Answer: 23071.0

User story: "The measured spectrum of simulated sources that are recovered after modeling with DcrCoadds appears to be inverted from the input simulations. There appears to be a bug in either the sign of the direction of DCR in the simulations or the modeling code, or there is a bug later when assigning wavelength ranges to DCR subfilters."
Answer: 51933.0

User story: "Frequency regularization in dcrAssembleCoadd.py is designed to suppress positive/negative sidelobes around bright sources, while not zeroing-out the noise. However, the sidelobe suppression leaves some sidelobes in place that I would naively expect to be reduced. These residual sidelobes may be affecting source measurement, and the regularization should be improved."
Answer: 30260.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "The prototype DcrCoadd generation code used the same filter transmission curve as the input simulations, and was able to recover the input spectra of individual simulated sources accurately. The new stackified DcrCoadds use a simple top hat transmission curve (until DM-13668 is completed), and are not able to recover the input simulated source spectra as well. This ticket is to investigate the effect of the filter transmission on the accuracy of the recovered source spectra."
Answer: 73326.0

User story: "The variance planes of DcrCoadds have unusual-looking double lobed features near most bright sources. This ticket is to investigate the variance planes to determine the cause of the feature, and fix it if it is a bug. Additionally, investigate the impact of the variance plane on source measurement."
Answer: 80829.0

User story: This command will invoke a method where any needed diagnostic action can be placed to assure that the DMCS is ready to work after a FAULT action occurred. This could be as simple as a health check of various components, or could even call iDRAC instructions to reboot a troublesome instance. Policy on what will be needed is still being determined.    After diagnostics are performed, the system will be placed in "OFFLINE" state.
Answer: 67483.0

User story: "Prepare for and participate in the OCS Integration of Spectrograph Image Creation Components activity. Jim, Felipe, <USER>"
Answer: 3131.0

User story: "Take a stab at an implementation guide.  In it, I want to:   # Outline in general what we're trying to do.   # Go through the relevant requirements for each service we intend to provide   # Provide an outline of what parts of the IVOA standards we intend to implement, and how if there are multiple ways to accomplish it.   # Write a simple few paragraph idea of how we should design it   # Pictures of the architecture, dataflow, and callflow.   # Note tricky points like user load, auth, etc.   # Some ideas on testing"
Answer: 331603.0

User story: "In the current version of DM-15396, I'm specifying a particular image in the dockerfile:    FROM lsstsqre/centos:7-stack-lsst_distrib-w_2018_33    This means use the 33rd week's weekly build for lsst stack.  Really we want to follow the latest weekly build though, and build on top of whatever is the latest successful weekly stack build.    In docker, you can do this with a latest tag, which will follow the latest one.  I suggested we have a latest_weekly tag for the stack to help this out to Frossie and Josh, and they agreed they could help me out with that.    Once we have a good tag to follow, we should fix this ticket and change the FROM line to the new tag.  We should be fine with this particular weekly for a while anyway.  Right now we're blocked until we get that."
Answer: 321499.0

User story: "Use the current (2018-08-31) version of Jointcal on the latest version of the HSC PDR1 reprocessing."
Answer: 20185.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: {{IS NULL}} in {{SUBMIT SELECT COUNT(*) FROM wise_00.allwise_p3as_mep WHERE spt_ind IS NULL;}}  causes the following error message:  > ERROR 4110 (Proxy): Query processing error: QI=?: Failed to instantiate query: ParseException:enterIsNullPredicate not supported.   # improve the error message so it's clear to the user that the query could not be handled/processed, add the specific unsupported portion of the query if possible (in this case a message like "IS NULL is not supported by qserv at this time" would be very helpful.   # the parser needs to be extended to support IS NULL   # add an integration test for IS NULL
Answer: 146774.0

User story: antlr4 has it's own exceptions (see its [Exceptions.h|[https://github.com/antlr/antlr4/blob/master/runtime/Cpp/runtime/src/Exceptions.h]).] Qserv needs to catch these and return a sensible "parse failed" error message to the user. The text of the exception should be logged, but seems to be not very useful to the user.    An example query to reproduce this issue is {{SUBMIT SELECT COUNT(*) FROM wise_00.allwise_p3as_mep WHERE spt_ind = NULL);}}
Answer: 146782.0

User story: Currently in the {{lsst.daf.butler.Config}} class you use {{.}} as the separator: {{config["a.b.c"]}}. This clashes with component names like {{calexp.wcs}} which means that it is impossible to have a dataset type name as a key in a configuration file. Even if {{Config}} was fixed to check for both a dict for key {{calexp}} and a value for key {{calexp.wcs}} there is ambiguity associated with the former dict having a key {{wcs}}. Rather than try to deal with that ambiguity this ticket will change the delimiter to some other character, probably {{:}}. During the ticket I will investigate minimizing explicit use of the delimiter in code to make it easier to see where the delimiter is being used.
Answer: 10021.0

User story: "In DM-15517 w_2018_34 run, the single frame processing logs have   {noformat}  Cannot import lsst.meas.extensions.photometryKron: disabling Kron measurements  Cannot import lsst.meas.extensions.convolved (No module named 'lsst.meas.extensions.convolved'): disabling convolved flux measurements  Cannot import lsst.meas.extensions.photometryKron: disabling Kron measurements  {noformat}  and no Kron mags were generated.    Redo DM-15517; ensure {{meas_extensions_convolved}} and other {{meas_extnsions_*}} included in {{lsst_distrib}} are set up. "
Answer: 14632.0

User story: "Possibly a micro-broker demonstration of how to run a swarm on AWS."
Answer: 35918.0

User story: "Make sure that the lsst-dm/alert_stream package contains an overview document describing the current state of the mini broker, together with detailed documentation on how to start, stop, run, test, etc all of the code within it; include details of how to deploy on AWS.    This could be Sphinx documentation, but for now just text files in the alert_stream repository would be ok."
Answer: 45905.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "I need the ability to create basic k8s resource types such as {{deploy}}, {{rc}}, {{ns}}, {{po}}, etc."
Answer: 782137.0

User story: "Add reference catalog defaults to at least obs_subaru to facilitate running jointcal on the HSC biweeklies.     [~<USER>  I assigned it to you, but I can just as easily do it if one of you sends me the command to run jointcal on the RC2 dataset so I can test that the configs make it do what we expect.  "
Answer: 41888.0

User story: "Run pipe_analysis scripts   # visitAnalysis   # coaddAnalysis   # colorAnalysis   # compareVisitAnalysis   # compareCoaddAnalysis    and validate_drp   # matchedVisitMetrics.py   # validateDrp.py   # reportPerformance.py    Upload the validate_drp metrics (json files) to SQuaSH:   # dispatch_verify.py    with the w_2018_36 RC2 outputs from DM-15603"
Answer: 19962.0

User story: "Reprocess the HSC RC2 dataset, as defined in DM-11345, using Stack w_2018_36. Steps include {{makeSkyMap.py}}, {{singleFrameDriver.py}}, {{mosaic.py}}, {{skyCorrection.py}}, {{coaddDriver.py}}, and {{multiBandDriver.py}}. "
Answer: 25833.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "After have access to Tucson machine, install client software, and test ingestion into a test Data Backbone.    Access to Tucson machine covered in [IHS-1301|https://jira.lsstcorp.org/browse/IHS-1301]"
Answer: 69467.0

User story: "Determine whether it is worth fitting more complex models (e.g. Sersic, general exponential+deVaucouleurs) using parametric fits to COSMOS galaxies (DM-15354) - where the bulge component is more likely to be spatially resolved - convolved by the HSC-I PSF and at HSC resolution.    COSMOS-HST images are useful for their better spatial resolution in order to test whether galaxies with resolved bulges in HST have meaningful structural parameters when fit at HSC resolution. Also, the HSC images are deeper than 10-year LSST and are useful as a sanity check, i.e. the degraded HST images should look like the HSC-I (+HSC-Z).    Jupyter notebook here: https://github.com/lsst-dm/modelling_research/blob/master/jupyternotebooks/cosmos_hst_analysis.ipynb"
Answer: 258118.0

User story: "Document goals and configuration specifics for kubernetes network separation enforcement."
Answer: 11831.0

User story: "Create and test ingress/egress network policy configurations to address access and security concerns."
Answer: 6.0

User story: "The pertinent copyright paragraph needs to be SED'd into the DM image ingest and distribution python and C++ files."
Answer: 681799.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: Building daf_persistence on {{tiger2-sumire}} fails as follows:    {code}  $ exec scl enable devtoolset-6 bash                                                                                                            $ bash newinstall.sh      [elided]    $ . loadLSST.bash   $ eups distrib install -t w_2018_34 daf_persistence       [elided]      [ 34/34 ]  daf_persistence 16.0-3-g3806c63+6 ...     ***** error: from /scratch/<USER>stack_master/stack/miniconda3-4.5.4-fcd27eb/EupsBuildDir/Linux64/daf_persistence-16.0-3-g3806c63+6/build.log:  Coverage.py warning: No data was collected. (no-data-collected)  Global pytest run completed successfully  Failed test output:  tests/Persistence_3    Running 1 test case...    *** No errors detected  tests/PropertySet_2    Running 1 test case...    *** No errors detected  The following tests failed:  /scratch/<USER>stack_master/stack/miniconda3-4.5.4-fcd27eb/EupsBuildDir/Linux64/daf_persistence-16.0-3-g3806c63+6/daf_persistence-16.0-3-g3806c63+6/tests/.tests/Persistence_3.  failed  /scratch/<USER>stack_master/stack/miniconda3-4.5.4-fcd27eb/EupsBuildDir/Linux64/daf_persistence-16.0-3-g3806c63+6/daf_persistence-16.0-3-g3806c63+6/tests/.tests/PropertySet_2.  failed  2 tests failed  scons: *** [checkTestStatus] Error 1  scons: building terminated because of errors.  + exit -4  eups distrib: Failed to build daf_persistence-16.0-3-g3806c63+6.eupspkg: Command:          source "/scratch/<USER>stack_master/eups/2.1.4/bin/setups.sh"; export EUPS_PATH="/scratch/<USER>stack_master/stack/miniconda3-4.5.4-fcd27eb"; (/scratch/<USER>sta  ck_master/stack/miniconda3-4.5.4-fcd27eb/EupsBuildDir/Linux64/daf_persistence-16.0-3-g3806c63+6/build.sh) >> /scratch/<USER>stack_master/stack/miniconda3-4.5.4-fcd27eb/EupsBui  ldDir/Linux64/daf_persistence-16.0-3-g3806c63+6/build.log 2>&1 4>/scratch/<USER>stack_master/stack/miniconda3-4.5.4-fcd27eb/EupsBuildDir/Linux64/daf_persistence-16.0-3-g3806c6  3+6/build.msg   exited with code 252  {code}    This means that the shared stack on Tiger is not currently being updated.
Answer: 78346.0

User story: "In order to begin evaluating the importance of variable PSFs for calculating DcrCoadds we should first test with simulated data. The existing simulator (StarFast) is capable of doing this, but needs to be modified so it can more easily use different PSFs for different observations. This ticket is to make those modifications, and generate a test data set with variable PSFs."
Answer: 131452.0

User story: "The simulated images being used to test the DCR algorithm work well for image differencing but are giving odd results when run through DcrMultiBand. This could be due to the lack of calibration. This ticket is to create new reference catalogs using the new(ish) HTM indexed file format, and reprocess the simulated data including calibration."
Answer: 9740.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Now that we're using the l1dbproto as the PPDB, there's no need for our home-grown SQLite database. Take it out, remove the interface layer, and use the l1dbproto API directly."
Answer: 133820.0

User story: "As a result of DM-15553, we will now require {{cffi}} in order to build GalSim in the stack.  This should be added to the list of required conda packages in lsstsw."
Answer: 12.0

User story: "[~<USER> drafted DMTN-092 following discussions on AP-PPDP interfaces at LSST2018. Read it, see how happy you are with it, and flag any potential issues."
Answer: 1601.0

User story: "Become familiar with the gen3 butler, to understand how to support use cases for OODS."
Answer: 224381.0

User story: "Notebook specific dashboard for monitoring infrastructure "
Answer: 63240.0

User story: "Support deployment and development for Alert distribution system"
Answer: 92149.0

User story: "Add limits and restrictions to the pod deployment within the cluster"
Answer: 77642.0

User story: "We need to test ingress and egress access to the cluster and within the pods in the cluster and ways to control and limit."
Answer: 5.0

User story: "The target location for an assembled and formatted image file is currently specified within the L1 system config file, as a directory path. This ticket is for the addition of a way to automate the target directory. The L1 system config file will still include a path to the archive location, but the software will append the day-month-year string to the path.    This is an initial and probably temporary measure, but as Patrick and Robert take test images with the ATS camera, they need some way to easily distinguish which images were taken on which day. Eventually, the archive will work hand in hand with the Data Backbone; and this may require a change when it arrives."
Answer: 10691.0

User story: "The DM internal messaging system uses rabbitmq. The procedure below is for testing the DM internal messaging system.    1) Add several dozen new dummy queues to the message broker    2) Also add the capability of each message consuming component to receive a message type 'PASS' and ignore the message after receiving it. This handler method may have a timer in it to simulate processing - less than a second...    3) Build a simple (40 line) message publisher that that starts several threads and has each thread publish 'PASS' messages from a scripted list of queues - directed at the new dummy queues as well as the components themselves.    4) Determine the rate at which the system slows with a gradual increase in message traffic and plot the rate."
Answer: 683155.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "The check services script in the start_up dir currently dumps systemctl details to the screen. This means that there are _active_ AND _running_ states listed for each of the 7 services. This may be daunting or confusing for an end-user. While this capability is needed at times, it should require a `-v` for verbose switch on the command line of the script. The non-switch default running of the script should simply list each DM service and state whether it is running or not.         The script should also call redis-cli and determine what OCS command state the system is currently in, and print that to the screen by default as well - whether the -v switch is used or not."
Answer: 10349.0

User story: "Update LDM-503 with the new document tree and ATM test approach"
Answer: 24128.0

User story: "In the past commit for DM-15392, I set up the k8s files to start the DAX webservices at the /api endpoint.    In testing future changes, it would be helpful to have another version of the DAX services ready for developers to mess with, changes to be pre-released, etc.  I propose /dev then the same URL.    Do the k8s plumbing for this, and I think one environment will be enough for now."
Answer: 18511.0

User story: "Various updates are needed in the comparison scripts.  Namely, some plotting limits and missing comparison plots as well as fixing the task runner such that the output rerun directory can be specified by the *\-\-rerun inDir:outDir* method which is currently broken due to the implementation of the *\-\-rerun2 in2Dir* (i.e. the comparison directory)."
Answer: 78926.0

User story: "Mapped current systems to services, requested feedback from all users on what needs of the system they are wanting to see over the next year. Identified what services are coming online over FFY19. Reviewed what warranties and licenses will expire over the next year, and have began to budget the needs to prepare the write up for the acquisition strategy. Reviewed the usage from the monitoring reports to determine if any systems were becoming overloaded "
Answer: 3.0

User story: "Section 3.3 says:  {quote}The described alert processing design relies on the “living” Level 1 database that contains the objects and sources detected on difference images. [...] As these get updated and added to, their updated contents becomes visible (query-able) immediately.  {quote}  This is inaccurate, as the database baseline requires users to access a replicated version of the PPDB, and the timescale for that replication is not yet decided. DMS-REQ-0004 requires that the nightly products be accessible in less than {{L1PublicT}}, which is currently 24 hours.     I think it is generally expected we can replicate the database much faster than once per day, but I don't believe there's a solid number we can provide.     "
Answer: 4515.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "The DM dev guide documentation on distributing third-party packages with EUPS should include announcing on (community.lsst.org's DM Notifications) any major-version upgrades or other breaking changes to third-party package versions.    For third-party packages with headers we build against, this should include a note that source packages should be cleaned and recompiled after the upgrade, because SCons will not automatically detect changes in third-party headers."
Answer: 27.0

User story: "This is a spin-off from DM-15500: I needed to move some code out of Mask.cc; in order to do that, I needed to refactor it a bit, and from there it snowballed into a near rewrite of one corner of Mask's implementation, including adding a mutex to guard access to global state.  Since that brings it pretty far from DM-15500's original goal, it makes sense to make that a separate review and merge.    The end result is intended to be entirely backwards compatible with the old Mask API and behavior, and that takes some other cleanup work off the table.  But I think the result is still a much safer and easier-to-understand implementation."
Answer: 15088.0

User story: "Currently the getters for formatters and templates use a name string to determine which formatter/template to use. It would be better to match the CompositesMap interface and allow DatasetType to be given."
Answer: 1501.0

User story: EUPS binary/tarball builds on osx were disabled many weeks ago due to strange problems with eups https downloads from {{eups.lsst.codes}} hanging.  Since that time, the sqre osx environment has been "white-listed" with the NOAO traffic mangler – it needs to be determined if this has resolved the problem and if not, the root cause needs to be identified.
Answer: 15888.0

User story: "Security vetting for the new hardware in the L1 Test Stand system."
Answer: 131247.0

User story: "Update the version of GalSim distributed with the stack to 2.0.  This will involve adding the software dependencies {{Coord}} and {{cffi}} to the stack."
Answer: 5793.0

User story: "The rmq-setup.sh script will need to be amended, a 'send telemetry' message added to Forwarder, and the necessary addition to the ats device component."
Answer: 80439.0

User story: "SSIA."
Answer: 685802.0

User story: "Add to DMTN-088 the definition of the environment where the HSC biweekly reprocessing is done."
Answer: 490369.0

User story: "More data is better for FGCM. Test FGCM on all HSC data taken to date (S18A data release).    Work here includes making the case to NAOJ for running FGCM; Updating the star-extraction script to work with hscPipe; iterating with NAOJ (Furusawa-san) to get the scripts working; and running the calibrations."
Answer: 44593.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Currently, {{ExposureCatalog}} supports old {{Calib}} calibration objects.  However, for use with {{jointcal}} or {{fgcmcal}} these need to support new {{PhotoCalib}} calibration objects.  This will also allow multiple {{PhotoCalib}} objects to be bundled into one persistence file (per visit, for example, the number of required inodes would be reduced by a factor of 100 for HSC data for {{fgcmcal}} outputs)."
Answer: 318588.0

User story: "Prevent the Forwarder from tanking if something is amiss when forwarding.    NOTE: This ticket does +not+ check the FITS cards against an inclusion list or such. It merely catches problems that upset FITSIO."
Answer: 14743.0

User story: "If/when an image ID is sent to DM that cannot be retrieved from the DAQ, the Forwarder should not lock up, but rather catch the exception and send an error code an ddescription of the failure; then *continue running.*"
Answer: 484419.0

User story: "Patrick and Robert need feedback from the system while testing that informs them of any non-fatal problems that the system encounters while running. They also should know when an image is successfully archived; which this channel will also provide."
Answer: 80799.0

User story: "Build and test a small python service that will be maintained on the ATS DAQ machine so that the Forwarder is checked for health and restarted if necessary. This is needed because the Forwarder is currently running on the DAQ machine, which has 2 or 3 different users on the machine - and occasionally the machine must be rebooted. Eventually, the ATS Forwarder(s) will be able to run on the same machine as the other ATS DM components where is can be part of the overall service dependency system for the DM ATS machine, but this option will not be available until early 2019.    Rather than service'ize the Forwarder itself, this method is preferred as it can be checked remotely by the DMCS machine when the system is brought up.    Probably only 40 lines long, this will be fast to build by re-using our rabbit publisher and consumer, but testing will take a few hours."
Answer: 686087.0

User story: "Detector is the name already heavily used throughout afw.cameraGeom in particular, and we should adopt that terminology in Gen3 rather than trying to change the existing codebase."
Answer: 86428.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: In discussions with [~<USER>, we decided that it would be best for multiple mutually-inconsistent associations of exposures (snaps) into visits should be permitted in the same Gen3 data repository.  We cannot assume that we will be able to do that association in advance and not want to revisit it in later reprocessing.    On the database side, I think we'd need to add a field to the visit table indicating which of several named systems the visit belongs to, while ensuring that visit IDs are unique across all systems.  We'd select exactly one system via configuration to be used by any butler client, though we'd need to think about when we'd have to be able to refer to other systems instead of relying on that selection (e.g. when interacting with datasets produced on some other system).  We'll also need to move the {{exposure.visit}} field into a separate join table.    The way information about visits will be transmitted from the LSST hardware is via a "GROUP" header card; to make use of that, we should:   * propagate that through ObservationInfo into the exposure table during raw ingest;   * remove visit definition (and all of the stuff dealing with visit regions) from raw ingest;   * add a new task to be run after ingest that creates visits (with regions, where appropriate) from groups of exposures with the same GROUP value.  That would involve generating visit IDs and names from GROUP via some algorithm.    For instruments that want visits to be 1-1 with exposures, we'll just define GROUP accordingly.  If we ever want to define a set of visits that isn't strictly derived from GROUP, we can write an alternate version of the task that populates the same tables via some other means.
Answer: 867618.0

User story: "It requires the installation of MySQL 5.7 for JSON support and Redis for caching the background tasks. Celery doesn't matter for the tests though.    Update API test client accordingly.          "
Answer: 3916.0

User story: "DM-15104 introduced some undefined variable names into MultibandDriver.py. Because there are no automated checks in in place for pipe_drivers (no unit tests or Travis) these were missed.    {{--reuse deblendCoaddSources}} will not work:  https://github.com/lsst/pipe_drivers/blob/master/python/lsst/pipe/drivers/multiBandDriver.py#L419"
Answer: 19974.0

User story: "It would be useful to be able to define a hierarchy of StorageClasses in Python so that checks isinstance() checks can work and we can define related storage classes across different configuration files (currently YAML reference syntax only works within the single file)."
Answer: 5643.0

User story: "Inheritance of `getTargetList` would be simplified if it were a `classmethod` instead of a `staticmethod`. This ticket is to write a trial implementation to see if a change is feasible in a short amount of time. If it takes too long, I will stick with my existing workarounds in `pipe_tasks.dcrMultiBand.py`."
Answer: 4361.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Prior to the new DeblendCoaddSourcesTask, the MeasureMergedCoaddSourcesTask set a config parameter on the (single band) deblender to make sure all peaks were propagated through from in detection catalog. This is needed to make sure that multiband catalogs had a consistent number and ordering of sources.    This config parameter was not propagated into the new DeblendCoaddSourcesTask, and should be set there.    The story points were set to reflect the time it would take to trace down the failure mode in processing that spawned this ticket."
Answer: 4096.0

User story: "Following a discussion in DM-15189, we need to be able to turn off default file name templating in local datastore configurations. A default is provided in the base configuration but there is currently no way to turn this off without putting in a dummy string that will cause a confusing error message."
Answer: 742.0

User story: "Initial plan is to do this with afw::table::io, as I think it'll be easiest and I think we'll need it eventually even if we implement some other format first (so we can put Detectors with back-links into Exposures).  YAML and pickle are the other options.    This is needed for Gen3 obs integration."
Answer: 82387.0

User story: Some builds are failing on macOS in test_polynomials. It seems that the test is unstable in that it sometimes passes and sometimes fails.    Example failure:    {code}  Failed test output:  tests/test_polynomials    Running 9 test cases...  a=0.2272165537183282, b=0.2272165537183142, diff=1.398881011027697e-14 > 1.009044198056236e-14  tests/test_polynomials.cc:398: error: in "simplified2d": check compare(a1, b1, 100*DEFAULT_RTOL) has failed  a=-0.01667616780189118, b=-0.01667616780189041, diff=7.771561172376096e-16 > 7.405706182468739e-16  tests/test_polynomials.cc:398: error: in "simplified2d": check compare(a1, b1, 100*DEFAULT_RTOL) has failed  a=0.0221159430012603, b=0.02211594300126229, diff=1.998401444325282e-15 > 9.821451652519151e-16  tests/test_polynomials.cc:398: error: in "simplified2d": check compare(a1, b1, 100*DEFAULT_RTOL) has failed  a=0.0221159430012598, b=0.02211594300126181, diff=2.012279232133096e-15 > 4.910725826259466e-16  tests/test_polynomials.cc:402: error: in "simplified2d": check compare(a1, b1, 50*DEFAULT_RTOL) has failed  a=-0.02074950336545145, b=-0.02074950336544967, diff=1.77635683940025e-15 > 9.214630554344155e-16  tests/test_polynomials.cc:398: error: in "simplified2d": check compare(a1, b1, 100*DEFAULT_RTOL) has failed  a=-0.0207495033654517, b=-0.02074950336545071, diff=9.853229343548264e-16 > 4.60731527717222e-16  tests/test_polynomials.cc:402: error: in "simplified2d": check compare(a1, b1, 50*DEFAULT_RTOL) has failed    *** 6 failures are detected in the test module "polynomials"  {code}    Master does seem to build fine some of the time. Running the test gives a different answer each time so there seems to be a repeatability issue.
Answer: 87.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Run jointcal with the HSC-RC2 dataset, the w_2018_34 stack, and the default jointcal config."
Answer: 10019.0

User story: "Run pipe_analysis scripts   # visitAnalysis   # coaddAnalysis   # colorAnalysis   # compareVisitAnalysis   # compareCoaddAnalysis    and validate_drp   # matchedVisitMetrics.py   # validateDrp.py   # reportPerformance.py    Upload the validate_drp metrics (json files) to SQuaSH:   # dispatch_verify.py    with the w_2018_34 RC2 outputs from DM-15517"
Answer: 9843.0

User story: "Run pipe_analysis scripts   # visitAnalysis   # coaddAnalysis   # colorAnalysis   # compareVisitAnalysis   # compareCoaddAnalysis    and validate_drp   # matchedVisitMetrics.py   # validateDrp.py   # reportPerformance.py    Upload the validate_drp metrics (json files) to SQuaSH:   # dispatch_verify.py    with the w_2018_32 RC2 outputs from DM-15184"
Answer: 25870.0

User story: "Reprocess the HSC RC2 dataset, as defined in DM-11345, using Stack w_2018_34. Steps include {{makeSkyMap.py}}, {{singleFrameDriver.py}}, {{mosaic.py}}, {{skyCorrection.py}}, {{coaddDriver.py}}, and {{multiBandDriver.py}}. "
Answer: 9940.0

User story: "Add the configuration necessary to turn on flake8 linting and travis CI to {{ctrl_pool}}.  This will require fixing any linting errors."
Answer: 10126.0

User story: "Add fake sources into the calexps to be used for testing and QA purposes. Initially use a basic catalogue of input sources."
Answer: 414249.0

User story: Base still use pex loggin in file:    python/lsst/base/packages.py         in line 162.    Default logging shall be used instead and  "warning" shall be used instead of warn in line 163.
Answer: 2518.0

User story: "TL;DR - Merlin messed up and merged early (there were reasons at the time), so this ticket is to apply the changes necessary here to deal with the changes to {{cp_pipe}} from review comments."
Answer: 72007.0

User story: "Based on the results of DM-15507, an evaluation of the PFS data model, and discussions with gurus as necessary, define a data structure which will hold the output from the AuxTel 1D extraction pipeline."
Answer: 1139829.0

User story: "Draft a flowchart showing inputs, outputs, processing stages, etc to serve as the basis for iterating on its eventual design."
Answer: 275050.0

User story: "Per our meeting of 2018-08-22, please provide a draft version of the plans for atmospheric characterization based on on AuxTel + other data.    We expect to discuss the at the Calibration Products meeting of 2018-09-10. At that time, a polished report is not required — a draft which serves as the basis for future discussion and work is fine."
Answer: 152993.0

User story: "Investigate transfer of data from SLAC test stand repositories for general DM use through services at LDF."
Answer: 642527.0