Details
-
Type:
Improvement
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: boost, Developer Infrastructure, eigen
-
Labels:None
-
Team:Architecture
Description
The current compile/link system results in numerous uninteresting warnings about "register" not being supported by C++11 when we build DM stack code. These are so numerous as to make it hard to detect useful warnings. These are caused by boost and Eigen.
Some possible solutions:
- Upgrade boost and Eigen. This would be optimal (assuming that newer versions have indeed stopped using "register"), but may be difficult. Boost, in particular, seems to require several patches to build successfully.
- Suppress the warnings by explicitly testing if the compiler accepts a flag to suppress them and use that flag if so. If we go this route we should explicitly undo it once we upgrade boost and Eigen.
- Suppress the warnings using -isystem, as per John Swinbank. Again, undo this once we upgrade boost and Eigen.
We have lived with this for a long time, but it is very unpleasant. At this point I'd like to push it up in priority and accept solutions that paper over the problem if necessary.
There is another class of warning that is less numerous but still a nuisance: warnings about using an outdated API for numpy. I am not sure where those come from, and there are few enough that I feel we can live with them if no easy solution presents itself. I suspect fixing them will require a different ticket.
DM-869 is related, but appears to focus on a different class of warnings from boost (one that I don't usually see).
Update: Ticket has been updated to just refer to Eigen as the boost upgrade was covered in DM-2384 and Eigen is the remaining source of register warnings.
Attachments
Issue Links
- is blocked by
-
DM-3800 testProcessCcd.py computes values that are too different between MacOS and linux
- Done
-
DM-3824 meas_astrom bugs exposed by new Eigen
- Done
- relates to
-
- Done
-
- Done
-
- Done
-
- Implemented
Activity
I'll state the obvious that changing all use of JacobiSVD in the stack is beyond the scope of this ticket. What I don't know is whether you are saying such an upgrade should be done before or after Eigen is upgraded.
Didn't really have a proposal in mind before, but how about this:
- Usage of JacobiSVD that's causing problems for the Eigen upgrade should be switched to use LeastSquares prior to upgrading to Eigen. I would not be surprised if this produces something closer to the new Eigen's outputs while using the old Eigen, and we should update our test code to expect those outputs accordingly. If we still see a big change when adopting new Eigen, we just switch to expecting new Eigen's outputs.
- Other usage of JacobiSVD for solving linear least squares problems should be updated to use LeastSquares on a future ticket.
I have pushed lsst_dm_stack_demo tickets/DM-3699 with new values. Note that meas_astrom tickets/DM-3824 and pipe_tasks tickets/DM-3800 are also required for us to update Eigen.
A Jenkins run fails on lsst_dm_stack_demo, but that is as expected because Jenkins always uses master of lsst_dm_stack_demo, as per DM-1399
Eigen has been updated. Problems in pipe_tasks, meas_astrom and obs_sdss demo have been fixed and merged.
It's also used in afw::math::LeastSquares (via the JacobiSVD class), so you may have to expand your search to include those if you want to catch all the uses. Note that LeastSquares does not use the solve method (it uses the decomposition to implement its own), which should be somewhat more robust (or, if Eigen has fixed the old problems in solve, more centralized). I think we should probably modify all of the uses of JacobiSVD::solve to use LeastSquares instead. The use in KernelSolution should probably stay as is, since it's using the SVD to do something else instead.