Bump version number to 7.9.0 and merge recent bug fixes from `main` [WIP] #140

The9Cat · 2025-05-05T15:38:51Z

This is a WIP for ongoing development in the devel branch. This allows CI to run at the very least.

…rflow while computing basis elements with large harmonic orders

…ized Legendre evaluation

michael-petersen

Great feature additions! I've run a small suite of local tests, nothing unexpected. Just a couple flagged things to decide on before bumping the version, but we're ready for this sooner rather than later.

michael-petersen · 2025-07-22T12:01:39Z

exputil/EmpCylSL.cc

Do we want to actually remove this workaround in 7.9?

Good question. I'd split the question into two questions:

When should we ditch all of the backward compatibility (if ever)?

What should be the default behavior on a cache version change generally?

On the first: it might be too soon to remove old (pre-HDF5) cache support, but this should be done at some point. More generally, there is so much code here to support and I already feel like I have knowledge atrophy. So I'm in favor of beginning to trim out old stuff, when possible. The allow_old_cache is definitely a temporary kludge to work around the Eigen bug. I will argue that I should bumped the version number when I changed the code for the new Eigen API, although to be fair to myself, I had no idea that there would be a bug. Then, we would not have needed allow_old_cache. I will tentatively propose that we bump the version number now, add the appropriate version checking logic. I suppose we can suffer with allow_old_cache a bit longer.

On the second, there are two obvious options:

Trigger a rebuild, which is the current workaround

Throw an exception to force the user to delete the old cache
I go both ways on this. On the one hand, it is a cache so overwriting seems logical. On the other hand, if the cache has historical value, the user should be forced to decide, which favors option 2.

michael-petersen · 2025-07-22T12:14:00Z

expui/BiorthBasis.cc

  }


+  std::vector<double> CBDisk::getAccel(double x, double y, double z)


Just wondering: do we want to add CBDisk in the end?

I can go either way on that. FlatDisk is a superset through its helper class EmpCyl2d which provides the CB basis. So one could get back CB by providing the CB density as the empirical target. Keeping CBDisk means another thing to maintain. But CBDisk is simple, easier to use, and good sanity check for a two-d expansion generally, and makes contact with a well-known example from the literature. So see a few more ticks in the keep than eliminate column. It's close.

michael-petersen · 2025-07-22T12:15:08Z

src/SphericalBasis.cc

  "rmin",
  "rmax",
  "self_consistent",
+  "FIX_L0",


It occurs to me to flag this up for addition to docs.

Yes!

And this raises another general issue: we now have a compendium of parameter keys for most important exp classes. We probably should spend a few days trying to document each and every key.

As of now, we are automatically importing our C++ documentation with Doxygen/CMake/Sphinx/Breathe linkage. This seems to be the current practice (after some quick googling) for most developers. Pretty ugly, tbh.

Right now, I'm hand importing the doxygen-generated xml into the sphinx tree. I suspect that we could automate this by putting the sphinx documentation into the main EXP tree and configuring readthedocs to access a subdirectory which was populated by CMake with the xml. I'm sure I could figure out how to do all of this, but it would be great to lean on someone that already has the expertise...