This is great. I wonder, should we syncrhonise the naming of this with how it appears in the Python API (i.e., ThreedPDFCalculator, or something like thiat?)

Thanks Simon. I agree that the naming should be consistent between libdiffpy and the Python API. Based on our earlier discussion, ThreeDPDFCalculator seems to be the clearest choice, and Long also supported this naming. I’ve updated the C++ class and the corresponding Python API to use ThreeDPDFCalculator consistently.

please can you paste here the results of running the tests as we don't ahve them running in CI atm.

please can you paste here the results of running the tests as we don't ahve them running in CI atm.

Thanks Simon. I reran the tests locally from clean checkouts and have included the commands and raw console output below.

Current PR on main

The complete test suite passes with ObjCryst disabled:

$ python3 -m SCons test enable_objcryst=no
scons: Reading SConscript files ...
Checking for Boost version >= 1.56.0... (cached) yes
Checking for C++ library boost_serialization... (cached) yes
scons: done reading SConscript files.
scons: Building targets ...
/tmp/libdiffpy-pr52-validation-20261018/main-pr/build/fast-x86_64/tests/alltests
Running cxxtest tests (180 tests)....................................................................................................................................................................................OK!
scons: done building targets.
TEST EXIT CODE: 0

The current main branch has an existing ObjCryst type compatibility issue in ObjCrystStructureAdapter.cpp. This issue is unrelated to the ThreeDPDFCalculator implementation and has already been fixed on migration-nano in commit 8f08fe9495d939231644f6ec0865f11baae5c056, where the translation-vector pointer type was changed from const float* to const REAL*.

PR commits applied to migration-nano

I applied this PR's commits 654ea5b and ebd6a9c onto the current migration-nano head, b3955ae. Both commits applied cleanly without conflicts.

The full test suite, including ObjCryst support, passes:

$ python3 -m SCons test
scons: Reading SConscript files ...
Checking for Boost version >= 1.56.0... (cached) yes
Checking for C++ library boost_serialization... (cached) yes
Checking for C++ library ObjCryst... (cached) yes
scons: done reading SConscript files.
scons: Building targets ...
/tmp/libdiffpy-pr52-validation-20261018/migration-run3/build/fast-x86_64/tests/alltests
Running cxxtest tests (209 tests).................................................................................................................................................................................................................OK!
scons: done building targets.
TEST EXIT CODE: 0

I also ran the dedicated ThreeDPDFCalculator tests:

$ python3 -m SCons test tests=ThreeDPDF
scons: Reading SConscript files ...
Checking for Boost version >= 1.56.0... (cached) yes
Checking for C++ library boost_serialization... (cached) yes
Checking for C++ library ObjCryst... (cached) yes
scons: done reading SConscript files.
scons: Building targets ...
/tmp/libdiffpy-pr52-validation-20261018/migration-run3/build/fast-x86_64/tests/alltests
Running cxxtest tests (2 tests)..OK!
scons: done building targets.
TEST EXIT CODE: 0

I also noticed that this PR currently targets libdiffpy/main, while the nanobind-based diffpy.srreal/main build pins libdiffpy commit b191c66df059aa1e4f96260b9df483454f32e084, which comes from the migration-nano branch.

At present, migration-nano has not yet been merged back into main. It contains the C++23 migration, the switch from Boost smart pointers to std::shared_ptr, the SCons compatibility updates, and the ObjCryst REAL type fix needed by the current nanobind-based diffpy.srreal build.

@sbillinge Would you prefer me to:

1. rebase this PR onto migration-nano and change its base branch to migration-nano; or
2. keep this PR targeting main, after migration-nano has first been merged into main?

@SYMSCAE, since you worked on the C++23/nanobind migration, do you have a preference on which integration path would be safest?

I also noticed that this PR currently targets libdiffpy/main, while the nanobind-based diffpy.srreal/main build pins libdiffpy commit b191c66df059aa1e4f96260b9df483454f32e084, which comes from the migration-nano branch.

At present, migration-nano has not yet been merged back into main. It contains the C++23 migration, the switch from Boost smart pointers to std::shared_ptr, the SCons compatibility updates, and the ObjCryst REAL type fix needed by the current nanobind-based diffpy.srreal build.

@sbillinge Would you prefer me to:

1. rebase this PR onto `migration-nano` and change its base branch to `migration-nano`; or

2. keep this PR targeting `main`, after `migration-nano` has first been merged into `main`?

@SYMSCAE, since you worked on the C++23/nanobind migration, do you have a preference on which integration path would be safest?

Hi @joeseaer, I would prefer the second way. Since we're not vendoring libdiffpy and @sbillinge has decided to quickly ship a beta/rc release (so that ci in srreal side will be fully functional), he might merge the migration branch shortly and release from there. In terms of safety, I don't see obvious abi changes and I suggest we can test them altogether within the pre-release.

Could someone give me a plan which would be the order of operations? I think first is a libdiffpy release that is waiting for the skpkg work to be done before it goes in. Then merging migration-nano into main on srreal? Honestly I thought I had already done that but apparently not. Then a release of srreal? Then merge the threedpdf work? An enumerated list of steps would be super useful because this got a bit complicated

Could someone give me a plan which would be the order of operations? I think first is a libdiffpy release that is waiting for the skpkg work to be done before it goes in. Then merging migration-nano into main on srreal? Honestly I thought I had already done that but apparently not. Then a release of srreal? Then merge the threedpdf work? An enumerated list of steps would be super useful because this got a bit complicated

• skpkg libdiffpy (Caden and I will handle this next Tuesday)
• merge migration-nano into main (this can happen before skpkg if you'd like to make timeline clean)
• pre-release libdiffpy
• merge 3dpdf into main(this can happen before pre-release if this is the scope of 1.5.0
• pre-release (once the ci pass) & test diffpy.srreal
• official release

Please see if this makes sense.