Possible bug in constructCalibs.py?

Dear all,

My student and I are developing an obs package for a high-cadence survey telescope we’re involved with commissioning. We’re using v12.1 of the lsstsw installation.

After a recent update to the stack, we encountered a problem with pipe_drivers/constructCalibs.py (commit: 03fb1f5). At line 652 (in DarkCombineTask), we get an error:
AttributeError: 'DecoratedImageF' object has no attribute 'getInfo'

The DecoratedImageF object comes from:
combined = CalibCombineTask.run(*args, **kwargs)
at line 651 and it looks like it will always return the same type of DecoratedImageF object (see line 118). So, it seems to us that combined.getInfo() will always return an attribute error.

We note that it works fine when we use the previous commit of constructCalibs (e9454d0).

Apologies if we’re mistaken, but just wanted to flag it just in case,


My guess is that you’re reading something in as a DecoratedImage instead of an Exposure. Can you point me to your obs package, please?

Oh, you’re mixing and matching versions. You’re using v12.1 of the LSST stack in general, and the master branch of pipe_drivers. In general, it should be understood that when you mix and match versions you’re taking your life in your hands. You need to use compatible versions. Is there a reason you can’t use the v12.1 version of pipe_drivers?

How have you installed the software? When you say “lsstsw” do you mean generically “the LSST software stack” or do you mean “installed using the lsstsw tool”. I don’t think you mean the tool. If you are using eups distrib to install the stack you could build a recent weekly.

To answer the first question, here’s the obs package: https://github.com/GOTO-OBS/obs_swasp

I build it using rebuild lsst_distrib. The last time was about 24 hours ago.

Unfortunately, we’re a bit slack in doing weekly builds, it’s something we need to get into the habit of doing.

Ah, so you’re not using v12.1. I’m starting to think this might be a genuine bug I introduced.

Ok. If you are using lsstsw rebuild then everything should be up to date. pipe_drivers is an optional dependency of lsst_distrib so it should have built as well. If it didn’t you can include it in the rebuild product list.

Apologies for the confusion. For future reference, what is the best way to refer to a version installed with lsstsw rebuild?

I don’t think there’s a foolproof way beyond reporting the output of eups list -s or sending your config/packages.pickle file.

The short-hand (but not foolproof) is to say something like “master as of 2017-01-18”.

OK. Thank you.

And thank you for your quick response on this topic. Much appreciated.

This is a bug that I introduced in DM-8913. The ticket for this bug is DM-9055. The fix is currently being reviewed before being merged, but I think rebuild -r tickets/DM-9055 should allow you to try it out.

The branch has merged, so you should be able to do a regular rebuild now and pick up the fix.

I’m sorry to have caused you this trouble. Thanks for the bug report! I’m glad to hear you’re adding a new obs package. Please stay in touch, and let us know if you run into trouble.

Excellent - thank you. We’ll rebuild over the weekend.

No problems at all. We’ve been making solid progress with ingesting, constructing calibs and processCcd, which are reproducing the output from our in-house analysis (largely based on SExtractor). We’re hoping to move on to coadding, image differencing and forced photometry, so it’s good to know we can contact you when we run into trouble.