Initialize useOptimizedPme so pre-evaluation PME queries do not throw bad_cast - #5486

useOptimizedPme was read before execute() ever set it. Initialized it to false.

The section below was generated with AI assistance (Devin) and checked locally before submission.

Fixes #5392.

CpuCalcNonbondedForceKernel::useOptimizedPme was only assigned inside execute(). Calling getPMEParametersInContext() before the first force or energy evaluation read an indeterminate value. When it read as nonzero, getPMEParameters() downcast an empty Kernel and threw std::bad_cast. The flag is now initialized to false in the constructor, so pre-evaluation queries return the parameters computed by initialize(). execute() reassigns the flag on every call, so the initialized value never affects the evaluation path.

Verification of the fix

Every read and write of useOptimizedPme was audited. It is written only inside execute(), first unconditionally reset to false, then set from supportsKernels for PME and LJPME. It is read in three places, inside execute() (safe, since it is set earlier in the same function) and in getPMEParameters() and getLJPMEParameters(), the pre-evaluation crash path.

The else-branches the fix makes reachable before evaluation return fields that initialize() already sets (nonbondedMethod, ewaldAlpha, gridSize, and for LJPME ewaldDispersionAlpha and dispersionGridSize), and initialize() runs at Context creation, before any public query is possible.

The constructor init list was audited against every member read between initialize() and execute(). useOptimizedPme was the only member left uninitialized. optimizedPme and optimizedDispersionPme default-construct empty and are only dereferenced under the flag. CpuCalcConstantPotentialForceKernel already handles this correctly by guarding with hasInitializedPme, which is constructor-initialized.

false is the correct initial value because execute() unconditionally reassigns the flag, so the initial value is only ever consulted by the pre-evaluation query path, where the non-optimized parameters are the right answer.

One pre-existing oddity was noticed but left alone as out of scope. getLJPMEParameters() casts optimizedDispersionPme to CalcPmeReciprocalForceKernel, not CalcDispersionPmeReciprocalForceKernel. It works because both expose getPMEParameters through a compatible interface, and the branch is unreachable until LJPME supports the optimized path.

Test

Added testPMEParametersBeforeEvaluation to tests/TestEwald.h, following the issue's reproduction pattern. It evaluates and deletes one Context, then queries parameters on a second Context before evaluation. It asserts the returned alpha and grid dimensions against NonbondedForceImpl::calcPMEParameters. Whether the test trips on the unfixed code is environment-dependent, matching the nondeterminism reported in the issue. On the fixed code it confirms the parameters are correct.

TestCpuEwald and TestReferenceEwald pass locally on this branch.