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: {quote}[<USER>https://app.slack.com/team/U2NKBSYT1] [8:44 AM|https://lsstc.slack.com/archives/GSK51QLLX/p1578663843000900] hi, following up on the short discussion on #desc starting at [https://lsstc.slack.com/archives/C2MH94JD6/p1578649810004300], my little intruding into visualizing patches shows that 7 patches have a higher sky level. There are actually 6 more if I correlate their position onscreen with the occurrence in the coaddDriver logs of the following type of failure:  {quote}  {code}36813 WARN  2019-12-23T23:47:10.652+0100 coaddDriver: ccwsge0519:36813: Caught NoResults while warping DataId(initialdata={'tract': 3828, 'filter': 'i', 'patch': '1,0'}, tag=set()): No locations for get: datasetType:skyCorr dataId:DataId(initialdata={'visit': 211533, 'detector': 113, 'filter': 'i', 'raftName': 'R24', 'detectorName': 'S12', 'tract': 3828}, tag=set())  36813 INFO  2019-12-23T23:47:10.709+0100 coaddDriver: ccwsge0519:36813: Traceback:  Traceback (most recent call last):    File "/cvmfs/sw.lsst.eu/linux-x86_64/lsst_distrib/v19.0.0/stack/miniconda3-4.7.10-4d7b902/Linux64/ctrl_pool/19.0.0/python/lsst/ctrl/pool/parallel.py", line 509, in logOperation      yield    File "/cvmfs/sw.lsst.eu/linux-x86_64/lsst_distrib/v19.0.0/stack/miniconda3-4.7.10-4d7b902/Linux64/pipe_drivers/19.0.0+2/python/lsst/pipe/drivers/coaddDriver.py", line 271, in warp      self.makeCoaddTempExp.runDataRef(patchRef, selectDataList)    File "/cvmfs/sw.lsst.eu/linux-x86_64/lsst_distrib/v19.0.0/stack/miniconda3-4.7.10-4d7b902/Linux64/pipe_base/19.0.0/python/lsst/pipe/base/timer.py", line 150, in wrapper      res = func(self, *args, **keyArgs)    File "/cvmfs/sw.lsst.eu/linux-x86_64/lsst_distrib/v19.0.0/stack/miniconda3-4.7.10-4d7b902/Linux64/pipe_tasks/19.0.0+2/python/lsst/pipe/tasks/makeCoaddTempExp.py", line 360, in runDataRef      self.applySkyCorr(calExpRef, calExp)    File "/cvmfs/sw.lsst.eu/linux-x86_64/lsst_distrib/v19.0.0/stack/miniconda3-4.7.10-4d7b902/Linux64/pipe_tasks/19.0.0+2/python/lsst/pipe/tasks/makeCoaddTempExp.py", line 567, in applySkyCorr      bg = dataRef.get("skyCorr")    File "/cvmfs/sw.lsst.eu/linux-x86_64/lsst_distrib/v19.0.0/stack/miniconda3-4.7.10-4d7b902/Linux64/daf_persistence/19.0.0/python/lsst/daf/persistence/butlerSubset.py", line 206, in get      return self.butlerSubset.butler.get(datasetType, self.dataId, **rest)    File "/cvmfs/sw.lsst.eu/linux-x86_64/lsst_distrib/v19.0.0/stack/miniconda3-4.7.10-4d7b902/Linux64/daf_persistence/19.0.0/python/lsst/daf/persistence/butler.py", line 1380, in get      raise NoResults("No locations for get:", datasetType, dataId)  lsst.daf.persistence.butlerExceptions.NoResults: No locations for get: datasetType:skyCorr dataId:DataId(initialdata={'visit': 211533, 'detector': 113, 'filter': 'i', 'raftName': 'R24', 'detectorName': 'S12', 'tract': 3828}, tag=set())  {code}  {quote}I presume that the following happens : warping proceeds until it fails with such a visit with no sky corr, in which case it stops and proceeds with the next stage. For the very obvious patches in the visualizer this failure occurs for the first visit(s) in the list of visits to be warped, while it occurs later for the 6 other patches, making them less obvious visually..... Does that match the behaviour you would expect? (edited)    (of course I know that there are failures at the visit level, though I did not check yet that they match, I am pretty ready to bet they do. Thus there may be a need to fix something in skyCorrection as well....)   <USER>12:10 PM   So you are saying that there is another error besides the fact that the sky correction failed? If the failure was in the first visit to be warped then why were there any warps at all for that patch? Maybe there needs to be a try block at [https://github.com/lsst/pipe_tasks/blob/w.2019.47/python/lsst/pipe/tasks/makeCoaddTempExp.py#L359?]   python/lsst/pipe/tasks/makeCoaddTempExp.py:359   if self.config.doApplySkyCorr:   <[https://github.com/lsst/pipe_tasks]|lsst/pipe_tasks>lsst/pipe_tasks | Added by GitHub   <USER>12:35 PM   Do the sims have backgrounds that needs to be corrected with SkyCorrTask? I would think that you’d want to build these coadds with doApplySkyCorr = False   <USER>12:36 PM   My memory is that Johann run some data with both and the sky corrected version looked better.   <USER>12:36 PM   Interesting…   <USER>12:43 PM   I am not a fan of skyCorr task. When you add the “corrections” back into the visits it introduces background offsets. The coaddition configs that you’re using assume and require that the background has been subtracted. When you introduce non-zero backgrounds and then coadd them, you get the weird effect that you’re seeing which is that the backgrounds depend on which visits are included   When we re-institute the backgroun matching, this won’t be a problem.   But I would start by looking at the backgrounds in the warps.   If they’re non-zero, the skyCorrections are causing problems.   The traceback above isn’t a problem in itself. With Gen2 we coadd all the data we have. If a visit is missing, it’s skipped. If a skycorr is missing, that visit is skipped. It does not write out a “wrong” warp (if that’s what your worried about). (edited)    new messages   <USER>12:51 PM   I think Johann is worried that a missing warp is causing the pipeline to skip the rest of the visits in the list. I didn’t think that was what would happen. Maybe there are many visits missing the skyCorr files which is why some patches have fewer warps.    <USER>12:52 PM   Ah I see, it’s not continuing on to the next visit?   We want it to continue on to the next visit unless --doRaise   <USER>1:07 PM   I’ll file a ticket to look into it  {quote}
Answer: 158.0