Based on tests it appears that everything except the "elements" vector is round tripping correctly.

The pybind11 CoaddBoundedFieldElement wrapper should wrap operator== and operator!= but does not. If I wrap that I see that the elements are not round tripping exactly. Beyond that it gets a bit weird: in Python each component of the first element compares equal, but in C++ the field and wcs do not (I have not compared later elements). That is very surprising: usually if one forgets to wrap operator== then Python will fail to compare equal because it falls back to something like is, even if C++ compares equal. I don't recall ever seeing the opposite occur.

In order to compare the elements I had to add an accessor to CoaddBoundedField to return the elements, and I added accessors for the other components as well, e.g. coaddWcs. If Jim Bosch has no objection I'd like to make these accessors part of the public API, in order to support debugging issues such as these.

I have no objection to leaving those accessors permanent. The symptoms do sound pretty unusual.

It's possible that CoaddBoundedFieldElement::operator== is a red herring - note that it compares many of its elements using pointer equality, which means that two instances will never compare equal if one has been round-tripped through serialization.

Unfortunately, it also looks very difficult to implement it more robustly without also implementing equality for SkyWcs and Polygon, and unfortunately it needs to be implemented to satisfy the BoundedField interface. Perhaps BoundedField shouldn't have operator==?

Equality already exists for SkyWcs though it not perfect (if SkyWcs::operator== is true then they are equal, but the opposite is not guaranteed; nonetheless an unpersisted SkyWcs will match the original). How practical is it to add Polygon:operator==?

Using pointer equality in C++ and object operator== in Python might well explain why I see equality in Python but not C++.

In any case equality is probably a red herring, as you say. The failure to persist shows up as a numerical difference.

The basic problem appears to be that SkyWcs persistence is not exact. Note that assertWcsAlmostEqualOverBBox does not allow 0 as the max error, so it cannot test equality. Fix that and fix the persistence test in afw test_skyWcs.py to use it.

I have attached a script that uses astshim and shows small differences between a celestial WCS FrameSet and its un-persisted copy. I also tried editing AST to persist floats with 19 digits instead of 17 and it made no difference. I have sent the script to David Berry in hopes that he can fix AST. When I run the script I see the following:

delta= [[  0.00000000e+00   7.95807864e-13   0.00000000e+00]

 [  0.00000000e+00  -6.82121026e-13   0.00000000e+00]]

Traceback (most recent call last):

  File "temp.py", line 51, in <module>

    assert np.array_equal(pixRoundTrip, pixRoundTrip2), "inverse transform is different"

AssertionError: inverse transform is different

The basic problem was that AST was not saving the inverse coefficients for MatrixMap and there were subtle numerical differences when they were computed when un-persisting. David Berry fixed that in starlink_ast.

I didn't see this earlier because I had mis-written assertWcsAlmostEqual... to require positive maximum error instead of allowing 0. I fixed that and changed two tests in afw and test_coaddBoundedField in meas_algorithms to use an error of 0.

In addition I added accessors to CoaddBoundedField in order to make debugging problems such as this simpler. I also modified operator== for CoaddBoundedField and CoaddBoundedFieldElement to test value equality, not pointer equality (provided neither pointer is null) and wrapped CoaddBoundedField::operator== with pybind11.

Please make sure you are comfortable with my changes to CoaddBoundedField in meas_algorithms. I hope you will find the changes in afw innocuous. There is no need to review the starlink_ast changes, though I made a pull request in case you want to look at them.

Looks good.  One small comment on the PR.

Thank you for the quick and helpful review. I implemented your suggested change to ptrEquals