libHilbert regression

[roystgnr]

I should have noticed this months ago, but I've been working on application codes that didn't trigger it:

Commit 5588d79 produces a swath of regression test failures in FIN-S

Yes, all that commit does is introduce a single #include line. My suspicion is that we're now getting a different, incompatible overload resolution on Hilbert::coordsToIndex and this is changing the ordering of some of our xdr/xda restart files. I've still no idea of exactly what the changed resolution is doing, nor why this doesn't trigger more failures in FIN-S, nor why it hasn't triggered anything in our examples or other application regression suites.

[roystgnr]

We're definitely getting a different overload resolution: the old code called

coordsToIndex( const CFixBitVec *p, int m, int n, CBigBitVec &h )

but the new code calls

coordsToIndex( const CFixBitVec *p, int m, int n, Hilbert::BitVecType &h )

Hilbert::BitVecType is just a subclass of CBigBitVec with a couple helper methods added, and they look to be interchangeable in most of the code, but setBits has a CBigBitVec specialization which AFAIK won't get called with Hilbert::BitVecType.

This looks like our extension code in hilbert.h. I'm not sure whether "one overloading gives different output from another compatible overloading" qualifies as a bug in libHilbert itself but it's probably worth pinging Chris Hamilton to ask.

Once I've got this straight I'm going to submit a PR that reverts us to the old behavior, both because the libHilbert comments include "This is terribly inefficient" on the default codepath we're hitting now, and because the number of (and importance of) FIN-S regressions created by 5588d79 exceeds the single GRINS regression we'll create by going back to the old codepath.

It's possible that MOOSE is in the same place GRINS is, with affected xdr/xda files generated since the commit. Hopefully the PR will catch that if so.