It turns out that turning of the junk suppression in coadd assembly is not the full solution (see LL panel of figure). On further investigation, the junk suppression temporary local background subtraction also needs to be defaulted to False in processCcd. This is because the safe clipping algorithm reverts to the footprints from single frame processing for very large footprints. Turning it off in processCcd does indeed result in the desired safe clipping behavior (see LR panel & compare with HSC run in UL panel.

Hey Lauren MacArthur — any chance we're going to get this in before the end of the cycle? It seems like the work has been done.

Ah, yes. I stalled on this when I realized I need to update some expected values for unittests and, presumably, the demo. I'll try to get to this today (and may bother you to get the updated OSX demo expected files...)

Would you mind giving this a review? I have updated the demo Linux expected files (having setup the latest weekly w_2016_49 on tiger here at Princeton)...would you also be able to update the Darwin ones using this ticket branch for pipe_tasks?

Jenkins is running: https://ci.lsst.codes/job/stack-os-matrix/label=centos-7,python=py2/18651/console (but will certainly fail the demo, which I forgot to skip!)

As expected, Jenkins failed at the demo (but passed all of lsst_sims lsst_distrib ci_hsc).

Code changes look fine: no objections.

Your commit message for the work in lsst_dm_stack_demo claims you are updating DarwinX86, but in fact you are updating Linux64. Oops. I'll push updated DarwinX86 results in a moment.

Have you checked that the updated test values in testProcessCcd.py are valid for both Python 2 and Python 3? The current values/tolerance were set so that the test passes on both, despite there being a discrepancy (which there shouldn't be; see DM-8017 for details). I'm worried that your updated numbers might only work on Py2.

(Actually, I'll just squash my DarwinX86 changes into your Linux64 changes, so no need for you to worry about the commit message.)

How do I do the python3 test? I tried running Jenkins having selected py3, but it bombed at oorb: https://ci.lsst.codes/job/stack-os-matrix/label=centos-7,python=py3/18652/console

I also just tried using python3 tests/testProcessCcd.py on tiger, but it bombed with

ImportError: No module named 'numpy'

How do I do the python3 test?

Hah. You ask all the difficult questions.

I believe the only way to do this is to build the stack using lsstsw. I think it's probably easier for me to do that than you (I have all the machinery set up), so let me give it a go and I'll let you know.

Actually, Yusra AlSayyad just gave me the tip that Jenkins should build with py3 if I just include lsst_apps in the product list and skip the demo...trying now.

https://ci.lsst.codes/job/stack-os-matrix/label=centos-7,python=py3/18691/console

Just got past pipe_tasks (on my branch), so I think we should be good to go (I'll let it finish before merging though).

The downside of that is that you can't use it to check if the demo passes on both Py2 & Py3.

However, it looks as if the demo hasn't actually been considered as part of the Py3 porting process, so chances are nobody currently knows if it passes on Py3.

Given that, I guess just checking that lsst_apps works through Jenkins is fine. Good thinking, Yusra.

Can't check the demo regardless...it won't pull a branch!

Right: to check the demo you'd need to build against Python 3 yourself. I think we maybe ought to do that, except that I bet the demo will just fail to run with Py 3 so it's not worth the effort.

Ah, yes, I suppose that would be the way to go as of now. Just to be sure, are you advising that I don't bother checking the demo against py3?

I satisfied myself that nobody has actually run the demo with Py3. Therefore, I think not bothering to check against it is fine.

The problem is we can't run the demo on Jenkins because running the demo has been conflated with running lsst_ci.

Merged to master.