Added unit tests requested by Quantum Motion

[mcjamieson]

Summary

Added comprehensive input validation tests for quantum measurement and time evolution operations.

Changes

operations.cpp

• Added 12 validation test sections covering measurement, projection, and PauliStrSum operations
• Tests verify proper error handling for invalid quantum registers, out-of-bounds qubits, duplicate targets, and zero targets

trotterisation.cpp

• Added complete test suite for unitary and imaginary time evolution operations
• Includes 8 validation sections testing invalid inputs (bad registers, non-Hermitian Hamiltonians, invalid Trotter parameters)
• Added 4 correctness test scenarios for imaginary time evolution: strong magnetic field, opposite magnetic field, ferromagnetic system, and antiferromagnetic system. Each verifies the algorithm converges to the expected lowest-energy configuration.

Test Results

• All 12 operations validation tests pass
• applyTrotterizedUnitaryTimeEvolution: 19 assertions
• applyTrotterizedImaginaryTimeEvolution: 262,153 assertions

[otbrown]

Thanks Maurice! I'll add reviewing this to my list.

[tom-quantummotion]

Thanks @mcjamieson!

[otbrown]

There is a PR to the PR which fixes conflicts arising from Vasco's concurrent changes to the time evolution API!

[otbrown]

Looks like I should take a closer look at the validation tests! I'll schedule it for Monday.

[otbrown]

Okay the single precision tests are failing because of the validate_expecPauliStrSumValueIsReal validation check in calcExpecPauliStrSum. The check fails with:

Expectation value: 19.2772 + i0.00159493
Epsilon: 0.001

Epsilon is already uprated from the single precision default value of 1E-5 by the REDUCTION_EPSILON_FACTOR for reduction operations -- that value is somewhat arbitrarily set.

For comparison the equivalent values at double precision are:

Expectation value: 19.2683 + i7.30146e-14
Epsilon: 1e-10

Note that the real component is also not within tolerance -- I suspect that the exponential calculation is responsible for the drift at single precision.

Arguably it doesn't make sense to be doing time evolution at single precision, but that would be a documentation issue. For the time being I'll adjust the tests to have much lower expectations of the accuracy of this result at single precision.

[otbrown]

Note that there is also a difference between the results for serial and multithreaded versions of the time evolution, probably down to the underlying numerical method used in either case.

Double precision:
  OMP_NUM_THREADS=8 (baseline):
    Expectation value: 19.2683 + i-2.49685e-16
  OMP_NUM_THREADS=1:
    Expectation value: 19.2683 + i7.30146e-14
Single precision:
  OMP_NUM_THREADS=8:
    Expectation value: 19.2689 + i2.60701e-05
  OMP_NUM_THREADS=1
    Expectation value: 19.2772 + i0.00159493

So epsilon needs to create quite a wide window...

[TysonRayJones]

Ooh the improved multithreaded accuracy is a nice demonstration of the benefit of heirarchal reductions 🎉 Changing epsilon for the tests is fine; it can even be done for that particular function only by using getValidationEpsilon() and restoring it at the end of the test case.

There are some minor issues with the tests, such as use of createQureg() which will break distribution above a certain number of nodes, rather than using prior created cached quregs. And some missing validations. Quicker for me to address these in a direct commit to this PR which I'll do presently

EDIT woops, createQureg is actually always safe because the auto-deployer will simply disable distribution when the Qureg is too small. But alas, it's nice to centralise/avoid temporary Qureg allocs and avoid the risks/noise of memory leaks when tests fail.

[ ] note to self: update "untested" warnings in doc

[otbrown]

Thanks for the patches Tyson!

Yes indeed, I've submitted a PR to Maurice's PR which uses that interface to set tolerances which will work for this set of tests, even on single-threaded single-precision runs. Should be able to get this merged once that's merged.

Overall, I think the lesson probably is "don't try to time evolve a quantum state at single-precision", although I think there probably are ways this could be improved At Some Point™️.

[otbrown]

All checks passed 🎊

There are certainly several improvements to be made, including using cached quregs (which I think should certainly be possible for the imaginary time evolutions), as well as a few options I can think of for dealing with the difference across precisions.

Rather than let perfect be the enemy of good however, my preference would be to merge this so we have some testing and then open a new issue to track improvements. Barring any objections I'll do that tomorrow evening!