ENH:Add 3D PDF calculator support

[joeseaer]

Hi @sbillinge@dragonyanglong ,

This PR adds a CPU PDF3DCalculator implementation to libdiffpy. The calculator
produces 3D real-space PDF data on a cubic grid, exposes radial histogram data,
supports binary dense-grid export, q-window post-processing, rho0 background
scaling, and 3D covariance delta controls.

It also includes the small supporting changes needed by the calculator:
a symmetric 3x3 eigen-solver helper in R3linalg, a PDFCalculator helper for
partial PDF scale, and an ObjCryst translation-vector type compatibility fix
for builds where ObjCryst::REAL is double.

I tested the libdiffpy build locally with ObjCryst/GSL/Boost available.

[sbillinge]

I didn't see any tests. Are there tests?

Can we also try and think about if it makes sense to make shared functions for anything to avoid copy-paying code from the PDF calculator? The more we can separate into shared functions the less duplication we have to maintain in the future

[sbillinge]

Please fix date and address. I am not sure we actually need this text block any more as we do the copyright and attribution differently do maybe just delete the whole block?

[joeseaer]

Thanks Simon. I updated the PR to address these review comments.

I removed the copied legacy copyright/header blocks from the new
PDF3DCalculator.cpp and PDF3DCalculator.hpp files.

I also refactored the shared structure-factor and normalization logic so
PDF3DCalculator now reuses PDFCalculator helpers for site scattering factors,
partial PDF scale, and RDF scale instead of maintaining its own duplicate cache.
The duplicated 3D post-processing path used by get3DPDF and exportGrid3DBinary
has also been consolidated.

The 3D grid deposition, spherical q-window, and delta-shell preprocessing remain
inside PDF3DCalculator because they operate on the 3D grid representation and do
not map directly to the existing 1D PDFCalculator routines.

I verified the updated libdiffpy build locally with scons -j2.

[sbillinge]

This is great. Thanks. Please can you paste the results of running tests locally?

Also, possibly on a new branch, please could you try and merge migration-nano into this branch and see if the tests still pass.. Actually, I would rather merge your changes into that branch so that it is coded at the version of the next release

[dragonyanglong]

@joeseaer any updates on this?

[joeseaer]

Sorry for the delayed update.
I have completed the naming changes from PDF3DCalculator to ThreeDPDFCalculator, including the file names, class and constructor, includes, tests, result accessor, and serialization registration. I also verified that the old name no longer appears in the code or file names.
I expanded the C++ test coverage and ran the full test suite locally:

python3 -m SCons test
Running cxxtest tests (218 tests) ... OK!
scons: done building targets.
TEST EXIT CODE: 0

This was tested on WSL2 Ubuntu 24.04 with GCC 13.3.0, Python 3.12.3, Boost 1.83.0, GSL 2.7.1, and libobjcryst 2022.1.4.

I am now reviewing the work on migration-nano and confirming the integration details and required code changes with Rundong. Once that work is complete, I will push the integrated changes to a branch based on migration-nano and update this PR to target that branch.

[dragonyanglong]

Hi Simon @sbillinge , renaming work is finished. After you or Rundong create a migration branch, qiaohai will make a PR to that specific branch.

[dragonyanglong]

If the plan sounds good to you, please close this PR, no merging needed. We will make a new PR to the new migration branch.

[sbillinge]

Hi Simon @sbillinge , renaming work is finished. After you or Rundong create a migration branch, qiaohai will make a PR to that specific branch.

I am a little unclear on the request here. migration-nano branch exists and the nanobind work is over there. @joeseaer reference this branch so he knows about it. Please could you clarify what you need?

[sbillinge]

If the plan sounds good to you, please close this PR, no merging needed. We will make a new PR to the new migration branch.

I can update the base branch of this PR so you may not need to redo the PR, though you may want to is you build a new branch from that new base. Just let me know what you decide. I will leave it open for now

[joeseaer]

If the plan sounds good to you, please close this PR, no merging needed. We will make a new PR to the new migration branch.

I can update the base branch of this PR so you may not need to redo the PR, though you may want to is you build a new branch from that new base. Just let me know what you decide. I will leave it open for now

Thank you for clarifying. I’ll create a new feature branch from migration-nano, port the changes, and open a new PR targeting that branch.
I’ll keep #49 open until the new PR is ready, then link it here before closing #49.

[dragonyanglong]

Hi @sbillinge , migration-nano branch was created, but it was not merged yet. So it seems like it is not existing yet. @joeseaer please clarify if I was wrong.

So @sbillinge , please merge the migration-nano branch first, then we can merge this PR (or modify this PR pointing to migration-nano branch), to make life easier.

[sbillinge]

Hi @sbillinge , migration-nano branch was created, but it was not merged yet. So it seems like it is not existing yet. @joeseaer please clarify if I was wrong.

So @sbillinge , please merge the migration-nano branch first, then we can merge this PR (or modify this PR pointing to migration-nano branch), to make life easier.

Hi @dragonyanglong@joeseaer I am not clear what the issue is. I don't see anything that needs merging into the migration-nano branch so it has all the work that has been done already merged into it. Do you not see it? it should be at https://github.com/diffpy/libdiffpy/tree/migration-nano.

Please @joeseaer build a clean branch off that one and migrate your changes on this PR into that branch and make a new PR, or am I missing something?"

[joeseaer]

Hi @sbillinge , branch was created, but it was not merged yet. So it seems like it is not existing yet. @joeseaer please clarify if I was wrong.migration-nano
So @sbillinge , please merge the branch first, then we can merge this PR (or modify this PR pointing to branch), to make life easier.migration-nano``migration-nano

Hi @dragonyanglong@joeseaer I am not clear what the issue is. I don't see anything that needs merging into the branch so it has all the work that has been done already merged into it. Do you not see it? it should be at https://github.com/diffpy/libdiffpy/tree/migration-nano.`migration-nano`

Please @joeseaer build a clean branch off that one and migrate your changes on this PR into that branch and make a new PR, or am I missing something?"

Hi @sbillinge@dragonyanglong
Sorry for the confusion. The current libdiffpy library is working properly. I will create a brand new clean branch and push my code there.

PR #89 (diffpy/diffpy.srreal#89) is still undergoing migration work and currently fails to build due to outdated dependencies. Once this PR is finalized, fixed, and merged, I plan to implement and upload my nanobind bindings based on the updated Python binding framework from this PR.

[joeseaer]

This work has been ported to the migration-nano branch and is now continued in #50. I’m closing this PR in favor of the replacement PR.