Minor bug fixes and updates

[The9Cat]

This branch is a devel with a bunch of minor updates and feature enhancements as follows:

• Updates to Eigen support for API tweaks to esp. Ref mapping in version 3.4
• Fixes for HDF5 API changes
• Improvements to CMake platform and compiler support in the top-level CMakeLists.txt and in specific package support for some of the specific libraries (e.g. exputil, expui and src).
• Added git detection to top-level CMakeLists.txt
• Made the my_err debugging variable static in fpetrap.h, mostly to prevent multiple stack allocations which makes the address sanitizer noisy.
• Fixed a bug in the CUDA detection that decides whether to get particle data from the GPU device in ExternalCollection
• Provide an initial value modified=0 in Component. Previously, this value could be uninitialized on instantiation.
• Fixes and enhancements to the FlatDisk implementation that includes Zang disk support. This fixes errors in the implementation that is currently in main. The main blunder is a normalization error that crept in with the FlatDisk class a while back.
• Standalone VTK file support that allows *.vtr files to be written without dependence on the VTK package. While I've tried to keep EXP consistent with a system VTK install, it's increasingly hard to get it right.
• A new FieldGenerator spherical histogram routine called histo1dlog that has a logarithmic radial spacing. Motivated by measuring halo profiles
• The new draft pseudo force support controlled by the nEJaccel parameter. The default is the original behavior.

[The9Cat]

• Compiles with Clang (18.1 tested on Linux)

[michael-petersen]

All good updates, and no apparent breaking changes. Everything compiles, so I'm willing to say this is ready for a merge to main so that we can branch back off from it. As usual, documentation is going to be the most annoying to-do from this.

[michael-petersen]

I should say that while I did leave a few questions throughout that would be useful to answer, that doesn't stop me thinking this is ready for merge.

[The9Cat]

We can mull over what makes the most sense for the CBDisk before merging. I can go either way. Mostly my thinking goes: this is one of the historical, published bases, so a BFE package seems like it should have it available. Ditto on CBSphere. On the other hand, I don't think it's very useful for modern research so perhaps it's not worth having more code to maintain. And to be fair, we've dumped the 3d Clutton-Brock basis.

[michael-petersen]

Just caught a couple more AddAcc->AddAccExt changes.

On CBDisk, I'm torn. I agree that as a BFE code, it's a bit sully not to have the classic sets available. At the same time, we are in principle offering equivalent (or better) products through the standard EXP solutions. This is certainly true in the spherical cases, where the tabulated results are more stable than recursions, but as you point out, the solution off the disc may be worse in the 2d case when using a Hankel transform.

To me, it comes down to which principle we want to follow: is it providing the best numerical solution regardless of method, or is it producing the EXP-like solutions (i.e. numerical tables)? This choice (if we make one) might also help the doc writing for suggestions of when to use methods.

[The9Cat]

Good points.

My current POV is that we should ax stuff that we believe shouldn't be used either because the method isn't up to the task or it will lead to confusion.

CBDisk is a particularly ambiguous case. One can get very close to the CBBasis provided by the recursion relations by using FlatDisk with a density from the Plummer-like base pair. It's not identical because it uses EOF not an exact (Hankel) transform. Of course, the goal of FlatDisk is provide the vertical forces as well (from the EOF basis using a numerical Hankel transform). So it sort of supercedes CBDisk. Also, CBDisk has not been widely used by any of us so perhaps that's a strike against it. That said, I used it recent for numerical comparison but I can't imagine choosing it for a real simulation project. And I didn't really simulate anything with it...

[The9Cat]

Here's a suggestion apropos CBDisk: implement a preprocesor flag that optionally compiles and exposes the Clutton-Brock disk. This could be CMake variable (e.g. ENABLE_CBDISK) or maybe that's too visible for a possibly temporary feature?

[michael-petersen]

I think it makes sense to merge this back into main ahead of other PRs, once you are happy that PseudoAccel work is at a reasonable resting place, @The9Cat ?

[The9Cat]

Okay, I'll merge it to main and then take a look at the upstream change in #103.

PseudoAccel is definitely a WIP feature but complete for now. It compiles and runs. The CENTER acceleration looks quite reasonable for model that is not itself a satellite. The AXIS rotational acceleration might be a bit sensitive, but it needs to be tested with a large run to be sure. Both may need tuning and fancier smoothing for real applications; we will see. For nEJaccel: 0, the original behavior should obtain, so I think this addition should be safe enough for now.