BUG: Honor StopOptimization from IterationEvent in v4 optimizers

[blowekamp]

Summary

Add an immediate m_Stop check after InvokeEvent(IterationEvent()) in ExhaustiveOptimizerv4, PowellOptimizerv4, and OnePlusOneEvolutionaryOptimizerv4.

Previously these optimizers would continue advancing after an observer called StopOptimization() (or StopWalking()) during IterationEvent, making it impossible to halt from a callback.

This is the companion change to #6196 (commit cf929f2) which added the same pattern to the GradientDescentOptimizerv4 family.

Behavior Table

After this PR, all v4 optimizers that support stopping now behave consistently when StopOptimization() is called from an IterationEvent observer:

Optimizer	Stop Method	Stops Before Next Step	GetCurrentIteration() at stop
ConjugateGradientLineSearch	StopOptimization()	✓ (via #6196)	iteration where stop was called
GradientDescent	StopOptimization()	✓ (via #6196)	iteration where stop was called
GradientDescentLineSearch	StopOptimization()	✓ (via #6196)	iteration where stop was called
RegularStepGradientDescent	StopOptimization()	✓ (via #6196)	iteration where stop was called
ExhaustiveOptimizerv4	StopWalking()	✓ (this PR)	iteration where stop was called
PowellOptimizerv4	StopOptimization()	✓ (this PR)	iteration where stop was called
OnePlusOneEvolutionaryOptimizerv4	StopOptimization()	✓ (this PR)	iteration where stop was called

References

• ITK PR BUG: Fire IterationEvent before AdvanceOneStep in v4 gradient optimizers (closes #2570, supersedes #2572) #6196 — Gradient descent family fix (commit cf929f2)
• SimpleITK test exercising all stoppable optimizers: Testing/Unit/sitkImageRegistrationMethodTests.cxx — StopRegistration

[greptile-apps]

Greptile Summary

This PR ports the m_Stop-after-IterationEvent pattern (introduced for the gradient descent optimizer family in #6196) to ExhaustiveOptimizerv4, PowellOptimizerv4, and OnePlusOneEvolutionaryOptimizerv4, making it possible to halt these optimizers from an IterationEvent observer.

• PowellOptimizerv4 and OnePlusOneEvolutionaryOptimizerv4: the new stop checks are correct and consistent with how those classes fire EndEvent on all other exit paths.
• ExhaustiveOptimizerv4: the new check calls StopWalking(), but StopWalking() unconditionally fires EndEvent itself. When an observer calls StopWalking() during IterationEvent, EndEvent fires once inside the observer and then a second time from the new check — duplicating the event. The fix is to replace this->StopWalking() with a plain break.

Confidence Score: 3/5

Two of the three changed optimizers are correct, but ExhaustiveOptimizerv4 introduces a double EndEvent emission that will affect any observer registered on EndEvent when the user stops via StopWalking().

The ExhaustiveOptimizerv4 change calls StopWalking() after the observer may have already called it, causing EndEvent to fire twice. This is a present behavioural regression on the primary user-facing stop path for that optimizer and should be fixed before merging.

itkExhaustiveOptimizerv4.hxx — the new stop check needs to use a bare break instead of calling StopWalking() to avoid the duplicate EndEvent.

Important Files Changed

Filename	Overview
Modules/Numerics/Optimizersv4/include/itkExhaustiveOptimizerv4.hxx	Adds m_Stop check after IterationEvent, but calls StopWalking() (which fires EndEvent) even though an observer that called StopWalking() already fired it — resulting in a double EndEvent.
Modules/Numerics/Optimizersv4/include/itkOnePlusOneEvolutionaryOptimizerv4.hxx	Adds correct m_Stop guard after IterationEvent; breaks to the single EndEvent call at the bottom of StartOptimization, so EndEvent fires exactly once.
Modules/Numerics/Optimizersv4/include/itkPowellOptimizerv4.hxx	Adds correct m_Stop guard after IterationEvent; explicitly fires EndEvent once and returns, consistent with the other early-exit paths in StartOptimization.

Sequence Diagram

sequenceDiagram
    participant Observer
    participant ResumeWalking
    participant StopWalking

    ResumeWalking->>ResumeWalking: InvokeEvent(IterationEvent())
    Note over ResumeWalking: observer is notified
    ResumeWalking->>Observer: IterationEvent callback
    Observer->>StopWalking: "StopWalking() [sets m_Stop=true]"
    StopWalking-->>Observer: "InvokeEvent(EndEvent()) fires #1"
    Observer-->>ResumeWalking: returns

    ResumeWalking->>ResumeWalking: if (m_Stop) — true
    ResumeWalking->>StopWalking: StopWalking() [m_Stop already true]
    StopWalking-->>ResumeWalking: "InvokeEvent(EndEvent()) fires #2 (bug)"
    ResumeWalking->>ResumeWalking: break

Loading

_{Reviews (1): Last reviewed commit: "BUG: Honor StopOptimization from Iterati..." | Re-trigger Greptile}

[dzenanz]

Looks good on a glance.

[hjmjohnson]

Thank you @blowekamp . I don't see any issues.

[hjmjohnson]

ITK.Pixi / Pixi-Cxx (windows-2022) failures are un-related to this PR.
Fixes in should resolve the failure.

• COMP: Extend Pixi-Cxx post-build cleanup to MSVC artifacts (followup #6322) #6324
• ENH: Drop *.o/*.a between ctest_build and ctest_test #6322
• BUG: Spare test fixtures from dashboard post-build cleanup (#6322 regression) #6325

Additional improvements inspired by reviewing MSVC cache missins in

• COMP: Build Pixi-Cxx CI as Release to enable Windows ccache #6327

should provide additional improvements in both disk space allocation and .obj file size.