Basis versioning

[michael-petersen]

While reviewing code today, I remembered that bases are now tagged with versions, e.g.

EXP/include/SLGridMP2.H

Line 95 in 3bb752d

inline static const std::string Version = "1.0";

We've since changed the heuristic for SL grid setting at high l order; in principle this changes the basis result. Given that the basis could change, it seems to me that all bases inheriting from this (so Sphere and Cylinder) should probably be bumped to 1.1.

More generally I'm wondering if we have a policy in place for basis versioning?

[The9Cat]

Hm. The changes only affect the evaluation of the associated Legendre polynomials at large l. Any already constructed EmpCylSL basis would not be using these. So there is no problem using a basis constructed before the change. My intent was to change versions when a previously constructed basis would be wrong or undefined with the current code. Since that's not the case here, I'm not sure that we need a version bump for Cylinder. Although, on the flip side, we know that basis made with the change will be better...

The Sphere case is similar. Reading an old cache file will still work, right? But the basis quality will be better for a new basis constriction for large values of l.

[The9Cat]

We might want to explicit document a policy. My working policy is functional: versioning maintains consistency between updated code and previously used basis files to maintain backward compatibility for older runs, etc.

[michael-petersen]

I agree with you that we aren't breaking anything, but in principle if someone regenerated an EmpCylSL basis they would be different results, right? That is actually the main use case for high l.

[The9Cat]

Yes, your vision of basis versioning is more nuanced than my original one. So now we have two policy criteria possibilities:

1. EXP uses the version info to allow backward compatibility with previously constructed basis
2. The version should change if the basis with the same parameters as a previously constructed basis changes (hopefully, improved!)

[michael-petersen]

My main thinking on the policy is just wondering what the minor revision number means -- if we are only going to change the version when the basis is no longer backward compatible, we might just get away with an integer number.

In the nightmare scenario where we find a bug in the basis (i.e. like from HighFive), it might be easier to increment an integer number rather than exclude a pattern like (say) 1.x.x.

[The9Cat]

This is a good thought. So first integer to for compatibility issues and second integer for possibly numerical changes (as in the high-l case).

I suppose that we could issue a warning (e.g.) for the high-l issue if lmax>Lswitch and there is no minor revision or, in principle, an earlier minor version?