Details
-
Type:
RFC
-
Status: Implemented
-
Resolution: Done
-
Component/s: DM
-
Labels:None
Description
Gbdes is a package for WCS-fitting (https://github.com/gbernstein/gbdes, https://iopscience.iop.org/article/10.1088/1538-3873/aa6c55/pdf). It was developed by Gary Bernstein for DECam. The main codebase is in C++. This will be used in a pipeline task that aims to be a drop-in replacement for jointcal (DM-31226), though we plan to use it in other configurations as well.
Tests on HSC data have shown that gbdes produces results equivalent to jointcal when the same astrometric models are used. However, gbdes provides a significant speed-up over jointcal. In contrast to jointcal, it can fit the proper motions of stars, and has more flexibility with regard to the types and combinations of astrometric models.
Following lots of discussion with Gary Bernstein and members of the DM team, I have added a Python wrapper using pybind11 and a new cmake build system. We opted to use a cmake build so that the package can still be used easily outside this organization. We decided to keep these additions on a fork that will be part of the LSST organization on GitHub if this RFC is approved (currently at https://github.com/cmsaunders/gbdes/tree/gaiadr2). This path was taken because it was decided that it would be simpler for DM to maintain the code going forward, and Gary does not anticipate making upstream changes.
Attachments
Issue Links
Activity
I think that Jim Bosch and I originally decided that standing up drp_tasks was probably preferable, but that in lieu of doing that (which I didn't want to do at the time), pipe_tasks seemed like the best place. Maybe standing up drp_tasks and putting the gbdes task in it is something I could work on now, definitely with some guidance from Jim or others. Alternatively, Eli Rykoff's suggestion of following the fgcm/fgcmcal model seems very doable.
Recommending on behalf of CCB. Clare Saunders, I'm happy to help you set up drp_tasks; let's just get that done, because it'll be useful for other things.
I think the fact that we veered into discussing the details of where the task would go says a lot about how undisputed your RFC was:
My 2-cents on where the task code goes:
- I try to put task code as low as it can go and still have all its dependencies.
- I do like the pattern we have of third party code with the fork living in one package and the wrappers living in another (e.g. scarlet/meas_extensions_scarlet, fgcm/fgcmcal)
- I think the fact that someone else put a CI test in a package instead of a unit test is not a pattern that you should copy and not reason to make your wrapper package as high as glue/plumbing packages.
I am not going to object to whatever you think is best
Thanks for the input everyone. Jim Bosch, let's talk in the next few days about how to proceed.
Right now pipe_tasks is the grab-bag where all the python-only tasks live, but maybe isn't the best choice.
A possible parallel is fgcm/fgcmcal which has the fork of fgcm (third-party code) in one repo, and fgcmcal where all the tasks and tests which depend on obs packages live. This might be easier than the jointcal model with the mix of c++/task/test code just because if our fork contains a significant amount of extras that aren't upstream it almost ceases to be a "fork" anymore.