[AlexisDrogoul]

Summary

Reworks how batch experiments execute simulations so that each simulation runs on its own thread, independently of the others, and is stopped by its own until: condition. Finished simulations are collected and replaced immediately, and their runner threads terminate.

Fixes #198, #282, #325, #358, #199. Implements #418.

⚠️ Status: draft, compiled but not run. gama.api, gama.core and gama.extension.batch compile (mvn -o compile -Dmaven.build.cache.enabled=false -pl ../gama.api,../gama.core,../gama.extension.batch from gama.parent). No batch model has been executed yet and no automated tests were added. See Testing below for what must be checked before merge.

Background / root causes

Analysis of the issues and the code:

1. Two stepping models coexisted. BatchAgent stepped simulations itself (sim.step() in a loop on the experiment thread, then evaluated until), while createSimulation(.., scheduleIt = true) also registered each simulation with SimulationRunner, which owns one worker thread per simulation. So parallel: had no real effect and the batch loop was effectively sequential, with lock-step "step all, then check all" semantics ([batch] Implementing truly parallel simulation execution #418, and the cross-simulation coupling described in "until:" facet's condition isn't respected in batch experiment #198).
2. Runner threads were never stopped. SimulationRunner.remove() only dropped the map entry; the worker stayed blocked on the semaphore forever. BatchAgent.closeSimulations does not dispose the population, and the threads were non-daemon. Threads and simulations therefore accumulated for the whole batch, and could keep the JVM alive (behaviour reported in [batch] experiment doesn't kill previous simulations when instanciating new ones in some models #282, and "stuck" runs with parallel: 2 in "until:" facet's condition isn't respected in batch experiment #198).
3. Status bar used values that never changed in the parallel-all path ([batch] wrong message in the status bar when pref_parallel_simulations_all is true #325).
4. Reload of a batch experiment did not close the views of the previous experiment, including the permanent section (Reloading a batch experiment with a permanent section does not close the previous displays #199).

Changes

gama.api — SimulationRunner, ISimulationRunner, GeneralSynchronizer

• New ISimulationRunner.runAutonomously(agent, isOver, isPaused, onOver): lets an already-added simulation step freely on its own thread until isOver is true, then calls onOver (from that thread) and terminates. The simulation is removed from the synchronized-step accounting (activeCount), so it is no longer waited on by step().
• Worker threads are now a dedicated SimulationThread class:
  • daemon threads;
  • register themselves in runnables before starting and exit as soon as they are no longer registered;
  • remove() interrupts an idle (waiting) thread so it can exit instead of blocking forever on the semaphore;
  • pause handling for autonomous simulations is done inside the thread (polls isPaused every 10 ms).
• step() purges dead simulations before computing the number of permits so the experiment never waits on a simulation that can no longer release one.
• GeneralSynchronizer.acquire(..): removed printStackTrace() on InterruptedException (interrupting idle threads is now an expected, normal event; the interrupt flag is still restored).

gama.core — SimulationPopulation

• New runAutonomously(...) delegating to the runner.

gama.extension.batch — BatchAgent

• New private runSimulations(pop, concurrency, factory, remaining, collector) replaces the two near-duplicate loops in launchSimulationsInParallelWithParametersSets and launchSimulationsWithSingleParametersSet:
  • keeps up to concurrency simulations running; each runs freely and evaluates the until condition in its own scope after each of its own steps;
  • finished simulations are pushed to a queue, unscheduled, collected on the experiment thread (so result/output handling stays single-threaded), and replaced by the next one;
  • a finally block unschedules every remaining simulation, so no thread leaks even if the experiment is killed or interrupted.
• Status bar ([batch] wrong message in the status bar when pref_parallel_simulations_all is true #325) now reads: N simulations finished | R running | W waiting (using T threads). runNumber is incremented when a simulation actually starts (previously pre-incremented for the whole batch), which keeps the final "Batch over. X runs" message accurate.
• closeSimulations now also closes the simulation/experiment views when the experiment is being reloaded (getSpecies().isReloading()), so permanent displays of the old experiment are closed before the new one opens (Reloading a batch experiment with a permanent section does not close the previous displays #199). It does not do so on the normal reset between runs.

Behaviour changes to be aware of

• Simulations in a batch are no longer synchronized: they can be at different cycles at any time. simulations collect each.cycle in a permanent chart (see "until:" facet's condition isn't respected in batch experiment #198) will therefore show differing values, which is expected.
• With parallel: 1 (or one core) only one simulation runs at a time, as before, but on its own thread.
• Status bar wording changed (open for discussion — see the question raised in [batch] wrong message in the status bar when pref_parallel_simulations_all is true #325).

Testing

Not yet performed — to do before merging:

• "until:" facet's condition isn't respected in batch experiment #198 model: until: cycle = 10, repeat: 3 and the 100000-agent / permanent chart variant; each simulation ends at exactly cycle 10, independent of the slowest.
• Problem with stopping criterion in batch experiment #358 model: every simulation stops at cycle 10, no "should have stopped" messages.
• [batch] experiment doesn't kill previous simulations when instanciating new ones in some models #282 model (repeat: 100 parallel: 4) with keep_simulations true and false: old simulations don't linger, batch terminates, experiment reflex fires at the end.
• experiment a type: batch until: cycle = 10 repeat: 100 parallel: 2 keep_simulations: false (from "until:" facet's condition isn't respected in batch experiment #198): no longer gets stuck.
• parallel: 1, parallel: 2, all threads, and pref_parallel_simulations_all true/false.
• Optimization/calibration methods (e.g. Optimization in Exploration.gaml): fitness aggregation still correct (fitness collected in processFinishedSimulation / manageOutputAndCloseSimulation).
• [batch] wrong message in the status bar when pref_parallel_simulations_all is true #325: status bar content in exploration and optimization experiments.
• Reloading a batch experiment with a permanent section does not close the previous displays #199: reload exhaustive_exploration (uses permanent): old display closed and new one opened (a comment on Reloading a batch experiment with a permanent section does not close the previous displays #199 reports the display not reopening — this PR closes the old views but I have not verified the reopening).
• Pause/resume and stopping/closing a running batch (no hung threads; JVM exits).
• Headless batch run.

Risks / review focus

• Concurrency in SimulationRunner (thread wake-up via interrupt() and the waiting flag; races between remove(), runAutonomously() and thread start).
• Simulation code that was implicitly serialized by the old batch loop (shared state across simulations, non-thread-safe preferences/outputs) now truly runs concurrently when parallel > 1.
• GUI interactions from simulation threads (batch simulations have no outputs, but experiment permanent outputs read simulations from the experiment thread).

[Copilot]

🟡 Changes recommended

Worker lifecycle races and stop-condition failures can hang batches or leak threads, while thread-count APIs become inaccurate.

3 open findings

• Ensure until-evaluation failures still invoke onOver · New
• Stop autonomous workers when removed while paused · New
• Preserve registered-thread counts for autonomous simulations · New

What changed in this PR

Reworks batch execution so simulations run autonomously and stop independently.

Changes:

• Adds autonomous simulation-runner APIs and lifecycle handling.
• Replaces batch stepping loops with queued completion processing.
• Updates batch status reporting and reload view cleanup.

File	Description
BatchAgent.java	Coordinates autonomous runs and completion collection.
SimulationPopulation.java	Delegates autonomous execution to the runner.
SimulationRunner.java	Implements autonomous worker-thread behavior.
ISimulationRunner.java	Defines the autonomous execution API.
GeneralSynchronizer.java	Silences expected interruption traces.

🧠 Review effort: Balanced

---

Give feedback about Copilot approvals in this survey to enter a drawing for a $150 gift card.

[AlexisDrogoul]

@chapuisk @lesquoyb @ptaillandier @RoiArthurB I think it is really important that we tackle all the remaining issues on batch before releasing anything ... Can you try / test / improve this PR ?

[AlexisDrogoul]

I have begun to test batch models, and the fixes in this PR seem to be ok. Can someone verify this ? I havent a large range of batch models myself... I will try to produce better "regression models" for batch.