Participants: Rafael Alves Batista, Claire Guépin, Pengxiong Ma, Paul Minodier, Clément Prévotat, Simone Rossoni, Matías Tueros

Key Outcomes

Matias presented the DC3 simulation pipeline architecture and the current state of the GitHub repository, which contains a minimum working example of the pre-antenna simulation chain. The pipeline is structured into six sequential steps — from flux generation to electric field simulation inputs — with most steps already implemented in a basic but functional form. The team agreed to spend the current week familiarizing themselves with the repository and running the existing scripts, with task assignments to be formalized at the next Monday meeting. Claire volunteered to present the pipeline overview on behalf of the group at the Thursday meeting. A GitFlow-based development workflow using GitHub Issues and pull requests was introduced as the project's collaboration standard.

Pipeline Architecture and Design Philosophy

The DC3 pre-antenna simulation chain is designed to be modular, tool-agnostic where possible, and computationally efficient by separating particle cascade simulation from radio/electric field simulation.

Six-step pre-antenna chain:

1. Flux Generator — Produces the incoming cosmic ray flux (energy, zenith, azimuth distributions) for a given site; output is stored in an SQLite database chosen for its native Python support and ease of use.
2. Particle Shower Generator — Reads the flux database and generates inputs for an external extensive air shower (EAS) simulator (e.g., CORSIKA or ZHAireS); this step has tool-specific "flavors" and is still under development.
3. Xmax Getter — Reads the particle cascade database and extracts the Xmax position for each event, which is the critical parameter for predicting where radio signal will and will not be present. A fake/dummy Xmax getter is currently implemented using an average Xmax-vs-energy curve to allow the rest of the chain to proceed without waiting for this step.
4. Event Generator — Places simulated shower cascades onto the detector array at various core positions, predicts which antennas might trigger using a conservative pre-selection condition, and outputs a database of candidate triggered events with core positions, Xmax values, and relevant antenna positions.
5. Radio Event Generator — Reads the triggered-event database and generates input files for the electric field simulator (e.g., ZHAireS); this step is also tool-specific.
6. Electric Field Simulation — External tool execution (ZHAireS or CORSIKA-based) to produce the actual electric field traces; this step is outside the repository scope but consumes the outputs of step 5.

Key design principle — reuse of shower simulations: Rather than simulating a new particle cascade for every event, the pipeline builds a library of cascades that sample the phase space (energy, zenith, azimuth), then repeatedly places ("throws") each cascade at different positions on the array. Events that do not trigger are tracked statistically via event weights (e.g., if a cascade had to be thrown 100 times before triggering, the triggered event carries a weight of 1/100, representing the 99 non-detections).

Computational motivation: Computing the particle shower takes roughly the same CPU time as simulating a single antenna's radio response. This makes the separation of the two stages highly efficient — the shower library is computed once, and the expensive radio simulations are only run for antennas that have a realistic chance of triggering.

Current Repository Status

• Repository is hosted on Matias's personal GitHub; collaborators must send their GitHub handles to be added; migration to the GRANDPA GitHub organization is planned once the codebase reaches a usable state.
• Flux Generator: Functional but basic — fixed distributions, 250-event output by default; intended as a starting point for others to extend with more flexible sampling.
• Fake Xmax Getter: Implemented and functional; uses a rough energy-to-Xmax approximation curve to provide dummy values so downstream steps can proceed.
• Event Generator: Functional; currently operates on a flat surface (no topography, no Earth curvature); selects antennas inside a cone projected from the Xmax position; requires at least 3 antennas inside the cone for an event to be selected. Outputs include core position distributions, input flux distributions, and weighted output distributions.
• Radio Event Generator: Example script exists that reads the triggered-event database and generates ZHAireS input files.
• Particle Shower Generator (Step 2): Still under active development; not yet needed to run the rest of the chain because the fake Xmax getter substitutes for it.
• Antenna/electronics response chain: Not in scope for Matias's current work; the plan is to reuse what was developed for DC2 (voltage conversion from electric field); the responsible party for further development post-DC2 was noted as unclear.

Technical Decisions and Design Choices

Azimuth sampling: The flux generator will sample uniform in azimuth; the azimuth matters because the interplay between shower direction and the geomagnetic field affects signal strength — stronger signals come from certain directional combinations.

Trigger pre-selection condition:

• The "trigger" at step 4 is not the actual hardware trigger, but a conservative pre-selection to avoid simulating antennas that will clearly not see a signal.
• The condition will be based on an electric field amplitude threshold (e.g., some number of microvolts).
• Candidate tools for fast signal estimation include quick analytical estimators (e.g., an Arsène-based code) or radiomorphing, to predict signal strength without running a full simulation.
• The condition must be conservative (not too strict) to avoid biasing the event database — it is better to simulate a few unnecessary antennas than to miss events that could contribute to science.
• Reframing from Paul: the goal is to exclude antennas that are certainly not going to trigger, not to enforce an optimal trigger threshold; this preserves sub-threshold antennas potentially useful for denoising or other analyses.

Topography handling:

• Currently all simulations run on a flat surface.
• Claire raised whether topography cuts should occur at step 2 (shower generation) or step 4 (event placement).
• Matias's preferred approach: apply a cut at step 4 — if the Xmax position is too close to or at the ground (indicating the shower hit terrain), exclude it from simulation rather than trying to propagate it further.
• Claire noted that if the cut is not expensive to apply later, it may be simpler to keep all events and cut afterward.

Array layout: The specific array to simulate (GP65, GP65 with GP13 antenna positions, GP80, or another configuration) has not yet been decided; the tools are designed to be flexible and can accommodate any layout.

Thinning level: DC2 star-shape simulations used thinning at 10⁻⁵; DC3 could improve to 10⁻⁶ for better cascade accuracy, though this trades event count for simulation quality — the team will need to decide between more events vs. better events.

ZHAireS timing/binning bug: Pengxiong flagged that the Penfei group identified a mirror bug in ZHAireS related to timing binning; Matias confirmed this is a known technical issue that can be addressed by using a sufficiently small time binning in the simulation.

DC2 Simulation Library — Issues and Implications for DC3

Pengxiong raised concerns about the reliability of the existing DC2 simulation dataset (GP300 layout, interpolation-based):

• Events with multiplicity less than 10 (fewer than 10 triggered DUs) appear almost exclusively at the margins of the GP65 denser infield, creating an apparent "hole" in the core position distribution around the denser array.
• Matias explained this is expected behavior: the infield has higher antenna density, so any given event will trigger more antennas there; events in the sparse outer array naturally have lower multiplicity.
• The deeper issue: the DC2 phase space did not include more vertical events or lower-energy events, which would populate the infield with low-multiplicity events. This was a deliberate choice at the time of DC2 to avoid simulating events that would not trigger in the sparse array.
• For DC3, Matias confirmed the pipeline can include more vertical/lower-energy events since the smarter event pre-selection will avoid wasting CPU on non-triggering configurations.
• Claire recommended developing visualization tools for core position distributions broken down by energy and zenith bins before running heavy production simulations, to catch oversampling or undersampling issues early.

Composition Handling — Proton vs. Iron (Clément's Proposal)

Clément raised an important efficiency idea related to primary particle composition:

• The Arsène fast signal estimator takes Xmax (in g/cm²) and electromagnetic energy as inputs, with no distinction between proton and iron primaries — the difference between the two is encoded entirely in the Xmax position.
• Therefore, a simulated proton shower at a given Xmax could, in principle, be reweighted to represent an iron shower of different energy that happens to have the same Xmax.
• Matias confirmed this is correct at first order: from the perspective of current reconstruction accuracy, proton and iron showers with the same Xmax are effectively indistinguishable.
• This means a single electric field simulation could contribute statistics for both compositions by applying appropriate weights based on the probability of each primary producing that Xmax value.
• Matias noted this is a good idea with caveats — second-order effects exist but are difficult to quantify, and biases and uncertainties would need to be tracked.
• Practical implication: generating the particle cascade library (without radio) is cheap enough that running separate proton and iron libraries is feasible; the gain from Clément's approach is mainly in reusing expensive electric field simulations.

Development Workflow and Contribution Guidelines

GitFlow branching strategy:

• main branch: Contains the last known-working release; only receives patches and stable releases.
• develop branch: Integration branch for new features.
• Feature branches: Contributors branch off develop, implement one feature/issue, then submit a pull request back into develop.
• Matias will be the sole approver of pull requests initially; approval will be prioritized and used for minimum quality control (e.g., ensuring documentation is complete before merging).
• Over time, additional approvers may be added based on expertise and availability.

GitHub Issues system:

• Issues are the primary unit of work; anyone can create an issue when they identify something that needs to be done.
• Issue naming convention: prefix with the module name for organization (e.g., "Event Generator — flat surface needs curvature").
• Labels in use: enhancement, help wanted, good first issue, won't fix (for ideas to track but not act on now), bug, documentation.
• Labels and their definitions will be reviewed at the next weekly meeting.
• Milestones: Three defined milestones — First Working Example (current), First Beta (minimum viable product), Initial Release (production-ready).
• Issues should be as small as possible; large tasks should be broken into sub-issues that can each be completed in roughly one week.
• Pull requests should be linked to the issue they resolve.

Weekly cadence: Issues will be reviewed each Monday meeting — checking status, re-assigning if needed, closing obsolete issues, and deciding what to prioritize next.

Responsibility model: Matias floated the idea of assigning one person as the responsible owner of each major module, who can then coordinate sub-contributors; this will be revisited once the team has a clearer picture of capacity.

Action Items

• All contributors: Send GitHub handles to Matias via Mattermost immediately to be added as collaborators.
• All contributors: Spend the current week setting up the repository, running the existing scripts end-to-end, and understanding the full pipeline philosophy before claiming specific tasks.
• Matias: Flesh out the GitHub Issues list with a complete set of tasks needed for the first minimum working product, ready for review by next Monday.
• Matias: Develop the true ZHAireS Xmax getter (DC3-Cyrus Xmax getter) as the immediate next development priority.
• Matias: Ensure Xmax getter handles the ZHAireS timing/binning bug via appropriate time binning settings.
• Claire: Present the DC3 pipeline structure (Matias's slides + GitHub page overview) at the Thursday meeting on behalf of the group; frame it as a call for new contributors and note that task assignments will follow.
• Claire: Send Matias the GitHub handle of her intern (working on topography) to be added as a collaborator.
• All contributors: Identify and create GitHub Issues for tasks they notice while exploring the repository; assign labels and milestones as appropriate.

Next Steps and Timeline

• Next Monday: Full team meeting to review the fleshed-out issue list and assign tasks to contributors.
• Thursday: Claire presents DC3 status update to the broader group.
• Target: Begin heavy simulations by October at the latest; Rafael flagged that the project is already running behind schedule and that even with significant computational resources, the simulations will take several months.
• Simulation scope TBD: Final decision on which array layout to simulate (GP65, GP80, etc.) and whether to prioritize more events (coarser thinning) or higher-fidelity events (finer thinning) is pending.

Key Outcomes

The team aligned on a phased approach to building the DC3 simulation library: simulate the real array first using the same methodology as DC2, then develop an interpolation framework in parallel to evaluate whether future libraries can be generated more efficiently. Key technical constraints around radio simulation (antenna-position dependency), interpolation reliability, and CPU cost were thoroughly discussed. A soft deadline of October 1st was set to launch simulations, with preliminary statistical studies targeting completion by end of August.

Decisions Made

• Primary approach: Simulate the true DC3 library first ("dumb way"), consistent with DC2 methodology, before exploring interpolation shortcuts.
• Interpolation strategy: Build a star-shape library in parallel; use it to test an interpolator and compare results against the full library — if interpolation proves sufficient, future libraries can skip full simulation.
• Simulation software: Use ZHAireS (Fortran-based); radio simulation breaks generalizability because signal depends on relative position between particle tracks and antenna.
• Hadronic interaction model: Default to Sibyll (fastest); EPOS-LHC is available but significantly slower. EPOS-LHC-R (legacy) not yet implemented in ZHAireS.
• Composition: Start with proton and iron only; separate libraries per composition; fill in intermediate compositions later if CPU budget allows.
• Proton-to-iron ratio: Consider simulating ~75% protons / 25% iron (proportional to Xmax fluctuation sigma, approximately 3:1) rather than 50/50, to better sample Xmax distributions.
• Simulation launch deadline: October 1st — decisions finalized or best-guess parameters used regardless of whether all preliminary studies are complete.
• Thursday presentation: Rafael to prepare 1–2 slides summarizing discussion for Kumiko's meeting; Claire to provide comments if needed.

Technical Constraints & Architecture

Radio Simulation Coupling Problem

• Radio signal depends on the relative position between particle tracks and the antenna, making it impossible to decouple shower simulation from array geometry — unlike purely particle-physics simulations.
• Historical workaround: advance particle → compute radio contribution → repeat (two interleaved loops). A better modern approach would be to store full cascade histories (track files) and recompute radio separately for any antenna geometry — feasible now due to storage capacity, but not 15 years ago when current tools were designed.

Interpolation Reliability

• Amplitude interpolation works well; pulse shape interpolation (relevant for ML or convolution-based reconstruction) is less reliable.
• Tools available: Radiomorphing (Simon), neural-network interpolator (Arsene).
• Interpolation degrades near low signal-to-noise ratio — precisely the regime of greatest physics interest.
• Acceptable error: ~20% for amplitude-only use cases.

CPU Scaling & Array Geometry

• CPU time scales linearly with number of antennas in simulation.
• Dense grid + pruning approach (used in prior GP300 geometry optimization study with Comico and Aurelian) is viable for uniform arrays.
• Non-uniformity of GP300 array (especially the infield) breaks the core-position reuse trick: infield proximity changes the signal, and uncontained cores add further asymmetry.
• Topography (stations at different heights) further breaks array symmetry, requiring full per-station simulation.
• Conclusion: no strong reason to avoid simulating the real array given these constraints.

Library Reuse & Xmax Statistics

• A library of ~10,000–20,000 simulations covering the phase space of incoming directions can generate hundreds of thousands of events via reuse — but over-reuse causes repeated Xmax values, degrading Xmax distribution sampling.
• Xmax sampling is adequate at the full library level but becomes sparse when restricted to narrow bins in zenith, azimuth, and core position simultaneously.
• Nobody in the current analysis chain is applying event weights from the library — events are being treated as equal weight, which is incorrect and may cause large statistical errors after reweighting.

Preliminary Studies Required

Study 1 — Distribution Sampling & Reweighting Behavior

• Generate fake event populations (no full simulation) using target distributions (energy, zenith, azimuth); plot phase-space coverage and bin occupancy.
• Simulate reweighting from library distribution (e.g., 1/E spectrum, 1/cos(θ) zenith) to physical flux; assess whether statistical errors explode in any bin.
• Risk: reweighting may amplify errors dramatically in low-occupancy bins — this has not been tested before.
• Zenith range decision example: Whether to cut at 45° or 60° lower limit — need to know what fraction of events is lost.
• Energy range decision example: Lower bound around 10^16.8–10^17 eV (10^16 likely too low); upper bound TBD.

Study 2 — DC2 Library Diagnostics

• Ask Georges (who has analysis infrastructure in place) to produce Xmax sampling plots per bin from the existing DC2 library.
• Ask DC2 analysts to apply event weights and replot distributions to reveal the impact of the currently ignored weighting.

Study 3 — Interpolation Validation (Parallel Track)

• Use existing star-shape simulations to test interpolation tools now, without waiting for DC3.
• Compare interpolated library against simulated library; if match is sufficient, adopt interpolation for all future libraries.
• Potentially refine star-shape geometry (more arms, denser antennas, smaller radius) before committing to a new star-shape library.

Infrastructure Development

• Matias is building a GitHub-hosted framework to structure the simulation library generation code; started this weekend.
• Architecture: modular functions (some initially dummy/placeholder) that collaborators can fill in and test independently.
• First deliverable: script to generate fake event populations with configurable distributions, enabling phase-space coverage visualization without running full shower simulations.
• Collaborative model: open issues on GitHub; team members pick up individual issues. Rafael may involve Clement once the framework skeleton is ready.
• Claire's incoming Master 1-level student (arriving September) may contribute to testing/plotting work depending on coding proficiency; unlikely to contribute meaningfully before October.

Risks & Open Questions

• Reweighting instability: If library bins have ~10 events and reweighting assigns large weights, detection of even one event can cause large jumps in reconstructed flux — magnitude of this effect unknown until studied.
• Interpolation at low SNR: All interpolation methods are least trustworthy exactly where sensitivity studies matter most.
• Infrastructure bottleneck: If the code framework (Branch 1) is not ready in time, it delays the decision on what to simulate (Branch 2) — both are on the critical path.
• Zenith distribution reweighting: Using 1/cos(θ) sampling distribution and reweighting to uniform-in-solid-angle flux is untested in this context; behavior unknown.
• Iron statistics in narrow bins: With 3:1 proton/iron ratio, iron events per bin become very sparse at fine binning — may need asymmetric bin sizes by composition.
• EPOS-LHC-R unavailability: Cyrus does not support the post-LHC-R hadronic model; CORSIKA can run it but Cyrus cannot — deferred as lower priority.

Pending Confirmation

• Final energy range and bin boundaries for DC3 library (not yet decided).
• Final zenith angle range (45° vs. 60° lower limit under consideration).
• Whether to use a two-grid approach (separate grids for infield vs. GP300) — depends on acceptable approximation level and topography treatment.
• Exact number of simulations needed (10,000 vs. 100,000) — requires completion of Study 1.
• Whether existing star-shape simulations are sufficient for interpolation testing or a new denser star-shape library is needed first.

Action Items

• Rafael: Prepare 1–2 slides summarizing this meeting's discussion for Thursday presentation to Kumiko's group; send draft to team tonight for feedback.
• Rafael: At Thursday meeting, ask attendees familiar with DC2 library to produce Xmax-per-bin sampling plots and replot with correct event weights applied.
• Rafael: Invite interested collaborators to join the DC3 simulation working group.
• Matias: This week — flesh out preliminary GitHub framework skeleton with modular structure and placeholder functions; share with team before holidays (departing ~August 9, returning ~August 14).
• Matias: Develop fake-event generator script as first functional component of the framework.
• Claire: After returning from holidays (back July 27) — contribute to preliminary distribution studies and/or testing.
• Team: Reassess progress by end of August; if insufficient, fall back to best-guess parameters and launch simulations by October 1st regardless.

Next Meeting

Approximately 2 weeks from now — contingent on Matias having a framework skeleton ready to share. Exact date TBD given overlapping holidays (Matias away ~Aug 9–14; Claire away next 2 weeks returning Jul 27).

Key Outcomes

The meeting focused on designing a new simulation library for the GP300 cosmic ray detector, covering event generation strategy, statistical weighting, core position sampling, and computational efficiency. Key methodological decisions were reached around energy and zenith angle distributions, trigger pre-selection using signal estimators, and a simulator-agnostic pipeline architecture. Several open questions remain — including maximum core distance cutoffs, Earth curvature corrections, and required statistics per bin — to be resolved in a follow-up meeting before a cosmic ray huddle presentation.

Decisions Made

• Energy spectrum distribution: Simulate using a 1/E spectrum so that logarithmic energy bins contain equal event counts, ensuring uniform statistical precision across all energy ranges.
• Zenith angle distribution: Use the logarithm of 1/cosine(θ) rather than linear zenith binning, so each bin represents an equal fractional increment in shower footprint size (~20% per bin at 0.2 spacing). This is motivated by the rapid footprint growth at high inclinations (1/cos(60°) = 2, up to ~40–50 at extreme angles).
• Composition libraries: Run proton first, then iron, as the two extremes to bracket systematic uncertainties; a third mixed-composition library (carbon, nitrogen, oxygen proportions) is deferred as premature.
• Hadronic model: Decision deferred until after the first library run is complete.
• Pre-selection trigger criterion: Apply a conservative signal estimator pre-filter before full radio simulation — requiring at least a signal-to-noise ratio of ~2 and 3–4 antennas above threshold — to avoid wasting CPU on events that will never trigger.
• Simulator-agnostic pipeline: The library generation infrastructure will be built to produce inputs valid for both CoREAS and ZHAireS (and other simulators), with simulator-specific interfaces only at input/output boundaries.
• Flat surface approximation (interim): Use a flat surface for core position sampling for now, with corrections for Earth curvature and topography to be addressed subsequently.
• Magnetic field variation: Use a constant magnetic field across the array for the library; per-position declination variation (~1–2%) is noted but not incorporated into the library, to be handled at reconstruction time.

Simulation Methodology

Core Position Sampling & Weighting

• Events are generated by randomly sampling azimuth, zenith, and energy from the target distributions, then iteratively testing random core positions until one is found where the signal estimator predicts a trigger.
• All tested (non-simulated) core positions are recorded and stored, and the simulated event is assigned a weight of 1/N (where N = number of positions tested), preserving the ability to compute absolute efficiency.
• This approach was validated in the GP289 DC2 library: to obtain 1,000 simulated events in one zenith bin (30°–42°), approximately 165,000 core position trials were required.
• Each simulated event stores all tested core positions, enabling construction of efficiency maps across the array and computation of absolute detection efficiency.

Signal Estimator Pre-Selection

• Before running full radio simulation (the most CPU-intensive step), a fast signal estimator (e.g., Arsène's emulator or ADF) is used to determine whether a candidate event is worth simulating.
• The estimator requires knowledge of the Xmax position, so a preliminary shower library (particle cascade only, no radio) is generated first to obtain Xmax for each event.
• This two-stage approach effectively simulates a large statistical ensemble without paying full CPU cost for events that would never trigger.

Maximum Core Distance Cutoff

• Highly inclined showers can trigger from very large distances, but such events carry very low weights and contribute minimally to overall exposure.
• Proposal: define a hard distance cutoff (e.g., ~10 km from array center) beyond which events are discarded from both simulation and data analysis, explicitly limiting the acceptance region.
• This introduces a small, quantifiable underestimation of exposure, acceptable because the efficiency at the array border is very low (e.g., 1 in 10,000), contributing negligibly to total exposure.
• The appropriate cutoff distance needs to be determined from existing simulations before the new library is designed.

Existing Data for Informing Cutoffs

• Giorgio's analysis of the DC2 GP300+GP65 library shows that the farthest triggered station from the shower core reaches up to ~12 km (unweighted, across all zenith/energy).
• This provides a practical upper bound; the same plot should be reproduced with event weights and broken down by zenith angle, azimuth, and energy to define energy/zenith-dependent cutoffs.
• An emulator-based study (proposed by Nathan and Arsène) moving shower cores perpendicularly outward from the array border could also quantify the detection horizon.

Pipeline Architecture

Proposed Workflow

1. Generate shower library (particle cascade only) → obtain Xmax positions, azimuth, zenith, energy for each event (text file output).
2. Signal estimator layer (simulator-agnostic) → takes event parameters + array geometry, outputs which antenna positions have trigger potential + core position weights.
3. Simulator interface layer → reads signal estimator output, generates input files for CoREAS or ZHAireS (or any other simulator).
4. Full radio simulation → run only pre-selected events through the chosen simulator.
5. Post-processing → pass output through GrandLib, apply antenna response, run trigger.

Key Design Principle

• All intermediate steps between shower generation and simulator I/O are simulator-agnostic, enabling the same machinery to drive CoREAS, ZHAireS, or future tools without redesign.
• Xmax can optionally be drawn from a parameterization (e.g., average Xmax) rather than full shower simulation, if speed is prioritized.

Open Questions & Pending Items

• Statistics per bin: How many triggered events are needed per bin to achieve the desired efficiency precision? (e.g., 1% ± X% requires far more events than 10% ± 2%). Matias asked participants to think about this before Monday's meeting.
• Energy range and zenith range: Not yet finalized; the signal estimator pre-filter makes overly broad ranges less costly, but the quadratic scaling of ground area with distance remains a concern.
• Maximum core distance cutoff: Needs to be derived from existing simulations; methodology (weight-based containment region or fixed radius) still under discussion.
• Earth curvature and topography corrections: The surface normal direction shifts ~0.01°/km; over 200 km this becomes relevant to angular reconstruction accuracy. Core positions computed on a flat plane must eventually be mapped to the actual topographic surface; conventions for defining zenith angle (at array center vs. at core position) are unresolved.
• Star-shape interpolation as alternative: Raised as a possible alternative to per-event simulation — simulate star-shaped antenna patterns and interpolate — but introduces systematic interpolation errors whose impact on efficiency estimation is unknown.
• Storing core position attempts: Whether to store all tested positions per event, or only the weight summary, is undecided; storing positions enables efficiency maps but increases data volume.

Identified Risks

• CPU cost for highly inclined showers: The most inclined and most energetic showers take the longest to simulate; from DC2 experience, these alone require at least 2 months of compute time on the cluster.
• Efficiency bias from distance cutoff: Applying a hard core-distance limit systematically underestimates exposure; the magnitude of this bias must be quantified and documented.
• Low-energy edge cases: At minimum energy thresholds, trigger efficiency may be ~1%, meaning ~100 simulations are needed per detected event; insufficient statistics here inflate systematic uncertainties.
• Topography and curvature complexity: Flat-surface approximation introduces position errors that grow with array extent; deferred but acknowledged as necessary before final reconstruction.
• Magnetic field gradients: Declination variation across the array (~1–2%) affects the V×B direction per antenna, potentially relevant for machine learning approaches that rely on signal polarization patterns.

Action Items

• Matias: Produce a list of required functions/tasks for the pipeline by next week (Monday the 6th), reusing DC2 infrastructure where possible.
• Matias: Derive an estimate of the maximum core distance cutoff from existing DC2 simulations before new library design is finalized.
• All participants (especially Claire): Estimate how many triggered events per bin are needed to achieve target efficiency precision — bring to Monday's meeting.
• Rafael: Prepare 1–2 slides for Monday covering energy parameters, science requirements vs. simulation feasibility, and efficiency definition clarification.
• Nathan/Arsène (proposed): Run emulator study moving shower core perpendicularly outward from array border across multiple zenith/energy bins to quantify detection horizon.
• Team: Reproduce Giorgio's distance-to-farthest-station plot with event weights, broken down by zenith, azimuth, and energy.

Next Meeting

Follow-up meeting: Monday, 6 July, at 2:00 PM (1-hour block) — Rafael, Matias, Claire — to finalize parameters and slides for the cosmic ray huddle.
Cosmic ray huddle presentation: Thursday morning following the Monday meeting; items to cover include energy range, zenith range, distance cutoff, statistics requirements, and efficiency definition.