Bharatiya Antariksh Hackathon 2026 — Electron Flux Forecasting
BHARATIYA ANTARIKSH HACKATHON 2026
Forecasting Energetic Particle Radiation
Environment for ISRO's Geostationary Satellites
Team Action Plan & Reference Document
How to use this document
This document explains the problem in plain language, breaks it into sub-problems, lists the exact
datasets you need with download instructions, lays out a realistic day-by-day build plan, recommends
a tech stack, and suggests differentiators that are feasible within the hackathon timeline.
Share this with every teammate before the build starts so everyone has the same mental model of
the problem.
Page 1
Bharatiya Antariksh Hackathon 2026 — Electron Flux Forecasting
1. The Problem
Right now, ISRO can only observe this danger after the fact. The goal of this problem statement
is to build a forecasting system: look at current solar wind conditions and predict how high the
electron flux at geostationary orbit will get, 30–45 minutes, 6 hours, and 12 hours into the future
— giving satellite operators a warning window to take protective action.
Sub-problems to solve
• A. Reading the data: the raw electron flux and solar wind data is archived in CDF
(Common Data Format), a binary scientific format — not CSV. You need a working
pipeline that opens these files and extracts the right variables.
• B. Cleaning the data: real satellite data has gaps, instrument noise, and spikes. These
need to be detected and corrected without destroying real physical signal (a genuine flux
spike during a solar storm must never be ‘cleaned away’).
• C. Identifying the right solar wind drivers: not every variable in the dataset matters
equally. This needs to be confirmed with correlation and lag analysis, not assumed.
• D. Building a model that respects time: this is a multi-horizon time-series forecast
(30–45 min, 6h, 12h), and the model needs to account for the physical lag between a
solar wind disturbance and its effect on the belt.
• E. Validating independently: training on GOES data (US longitude) is not enough —
ISRO wants to see the model checked against GRASP/GSAT data measured from
India's own longitude.
• F. Making it usable: a model sitting in a notebook is not a complete deliverable. ISRO's
own slide shows a real-time-style dashboard as the expected outcome.
Page 2
Bharatiya Antariksh Hackathon 2026 — Electron Flux Forecasting
2. Datasets Required — Sources & Exact Retrieval Method
2.1 Electron flux (the prediction target) — GOES satellites
Source: NCEI / NGDC GOES-R archive (modern series) and the full GOES archive index (full
history).
Important update vs. the hackathon slides
GOES-19 became the operational “GOES-East” satellite on 7 April 2025, replacing GOES-16. If your
11-year window runs roughly 2015–2026, you will be stitching together data from at least three
instrument generations: GOES-13/15 (older EPEAD sensor), GOES-16/17/18 (SEISS / MPS-HI
sensor), and GOES-19 (current). Calibration differences between these generations are real and
worth mentioning explicitly in your presentation — it shows you understood the dataset, not just
downloaded it.
• Variable to extract: the >2 MeV integral electron flux channel — this is the same
measurement NOAA SWPC itself uses to issue “Electron Event” alerts.
• Cadence: 5-minute averaged data is a good balance of detail vs. file size; avoid raw 1-
second data unless specifically needed.
• Shortcut: the same GOES electron flux series is also mirrored on CDAWeb in
harmonized form, so you can use one download workflow (CDAWeb) for both electron
flux and solar wind data instead of two.
2.2 Solar wind drivers — CDAWeb's OMNI dataset
Source: [Link]
Do not download raw ACE / Wind / DSCOVR files separately — NASA already merges
everything into one pre-cleaned, time-shifted dataset called OMNI. Three resolution tiers are
available:
Dataset name Cadence Best use
OMNI2_H0_MRG1HR 1 hour Main training data — matches the cadence used in
most published LSTM/Transformer radiation-belt
studies
OMNI_HRO2_5MIN 5 min Higher resolution, useful for the 30–45 min
nowcast model
OMNI_HRO2_1MIN 1 min Highest resolution, for fine-grained nowcasting
specifically
Each of these already includes solar wind speed (Vsw), IMF Bz/By/Bx/|B|, proton density (Np),
temperature, and the Kp/Dst/AE/AU/AL geomagnetic indices — already time-shifted to Earth's
bow shock, so no manual L1-to-Earth propagation delay calculation is needed.
• Download method: search the dataset name on CDAWeb → select date range →
choose CSV/ASCII (easiest for pandas) or CDF → download.
• API option (recommended): CDAWeb exposes a HAPI API endpoint at
[Link]/hapi — use the Python hapiclient package to pull data directly in
Page 3
Bharatiya Antariksh Hackathon 2026 — Electron Flux Forecasting
a script. This turns your data pipeline into reproducible code instead of a manual
download chore, which is a nice plus in a demo.
2.3 Validation data — ISRO's own GRASP / GSAT payload
Source: [Link] (PRADAN portal)
1. Register/login first — PRADAN does not allow anonymous downloads.
2. Search for the GRASP instrument under GSAT-19.
3. Select the electron flux data product, and pick your date range (about 1–2 years of data
are available).
4. Use the Bulk Download option for multiple files, or download individually.
How to use this dataset
Use GRASP only for validation, never for training. After training your model on GOES data (US
longitude), compare its predictions against GRASP measurements (Indian longitude) for the same
time periods. This cross-check is exactly what the hackathon slide's “Validation using ISRO Satellite
data” box is asking for, and is one of the explicit evaluation criteria.
Page 4
Bharatiya Antariksh Hackathon 2026 — Electron Flux Forecasting
3. Realistic, Hackathon-Doable Build Process
The goal is not a state-of-the-art model — it's a complete, correct, well-explained pipeline with
honest validation. Judges are domain scientists; they reward demonstrated understanding over
raw model complexity.
1. Data and understanding
• Get a working CDF reader (Python's cdflib) running on both GOES and OMNI sample
files.
• Reproduce the kind of multi-panel plot shown on the mentors' own slide — electron flux,
IMF B, IMF Bz, Vsw, Nsw, SYM-H on a shared time axis. This single plot is worth doing
carefully since it mirrors exactly what the mentors presented.
• Run a lagged cross-correlation between solar wind speed / Bz and electron flux to
empirically justify which lag windows feed the model — this directly demonstrates the
“understanding of solar wind and radiation belt basics” evaluation criterion.
2. Cleaning
• Flag and interpolate short data gaps.
• Use a rolling median / MAD-based filter to catch obvious sensor spikes — cross-check
against Dst/Kp to avoid removing real storm-driven spikes.
• Resample everything onto one common time grid (hourly is the safest, most defensible
choice given OMNI's native structure).
3. Modeling
• Start with a simple, fast baseline first: a persistence model (“tomorrow = today”) and a
gradient-boosted/linear regression on lagged features. This gives you a number to beat
— “our LSTM beats persistence by X%” is far more convincing to scientists than a bare
accuracy figure.
• Build one LSTM or GRU model with a sliding window of past Vsw / Bz / density / flux,
predicting all three horizons (30–45 min, 6h, 12h) directly as a multi-output regression —
simpler and more robust than three separate models or a recursive forecast.
4. Validation
• Hold out the last chunk of the time series chronologically — never randomly shuffle time-
series data; this is a mistake that would visibly undercut credibility with domain
scientists.
• Report standard forecasting metrics (RMSE, MAE) and a few storm-event case studies.
• Cross-check predictions against GRASP data from Indian longitude for at least 2–3
known events.
5. Packaging & demo
• Build a simple real-time-style dashboard (see Section 4).
Page 5
Bharatiya Antariksh Hackathon 2026 — Electron Flux Forecasting
• Prepare a narrative that connects the science background (Van Allen belts, “killer
electrons”, solar wind drivers) to your pipeline, so the demo reads as ‘we understood the
physics, then built for it,’ not ‘we threw an LSTM at a CSV.’
4. Recommended Technologies, Tools & Models
Stage Recommended tool(s) Notes
CDF reading cdflib (Python) Pure-Python, no NASA CDF C-library
dependency — easiest to install in a hackathon
environment
Data pull (API) hapiclient Pulls OMNI data programmatically via CDAWeb's
HAPI API — makes the pipeline reproducible
code, not manual downloads
Data wrangling pandas, numpy Time alignment, resampling, merging GOES +
OMNI + GRASP series
Cleaning scipy + a custom rolling- Writing the spike detector yourselves (even
median/MAD spike detector simply) is better received than an opaque library
call
Baseline models scikit-learn (Gradient Boosting / Establishes the number your deep model needs
Random Forest) to beat
Forecasting model PyTorch or TensorFlow/Keras — A Temporal Convolutional Network (TCN) is a
LSTM, GRU, or a TCN strong, less commonly used option — often trains
faster than LSTM and stands out without being
risky
Visualization Plotly / Matplotlib For the multi-panel exploratory plots and
accuracy charts
Dashboard Streamlit Fastest way to build a live, interactive “Space
Weather Dashboard” resembling the slide's
mockup
Experiment A simple comparison table, or Concrete evidence of model optimization, not just
tracking MLflow if time allows one final number
Avoid jumping straight to a full Transformer architecture unless there is time to tune it properly
— an undertrained Transformer that underperforms a well-tuned LSTM baseline looks worse in
front of judges than a simpler, well-validated model.
Page 6
Bharatiya Antariksh Hackathon 2026 — Electron Flux Forecasting
5. Ideas to Stand Out (Feasible, Not Just Flashy)
Storm-conditioned evaluation
Report model accuracy specifically during known geomagnetic storm periods (easy to identify
via Dst/Kp spikes in OMNI), not just average-case accuracy. Scientists care far more about
whether the model catches the dangerous spikes than about average RMSE — this directly
targets what the problem statement actually cares about: satellite risk.
Uncertainty-aware forecasting
Instead of a single predicted number, output a prediction interval — even a simple ensemble of
a few models or quantile regression works. A dashboard showing “predicted flux: X, with Y%
probability of exceeding the alert threshold” reads as far more operationally mature than a bare
point forecast, without much extra engineering.
Physical sanity-check layer
Flag cases where the model's prediction violates known physics (e.g. predicting a flux drop right
as Bz turns sharply southward). This is a lightweight way to demonstrate domain understanding,
not just mathematical fit.
Cross-longitude generalization as a headline result
Explicitly present the GOES-trained-vs-GRASP-validated comparison as a finding (“our model,
trained purely on US-longitude data, generalizes to Indian longitude with X% degradation”)
rather than a checkbox. This is literally what the slide's Expected Outcomes section asks for,
and most teams are likely to treat it as an afterthought rather than a result worth presenting.
Page 7
Bharatiya Antariksh Hackathon 2026 — Electron Flux Forecasting
6. Reusable Prompt Summary
The block below is a self-contained summary of the problem statement, written so it can be
pasted into a new AI conversation as context (e.g. when asking for help on a specific sub-task
like the CDF reader or the LSTM architecture).
PROBLEM STATEMENT (Bharatiya Antariksh Hackathon 2026, ISRO/SPL-VSSC):
"Forecasting Energetic Particle Radiation Environment for ISRO's Geostationary
Satellites"
GOAL: Build an algorithm that reads, processes, visualizes, and forecasts
energetic (>2 MeV) electron
flux at geostationary orbit, with forecast horizons of 30-45 minutes, 6 hours, and
12 hours ahead.
WHY IT MATTERS: Relativistic "killer electrons" in Earth's outer Van Allen belt
can damage ISRO's
GEO satellites (GSAT/INSAT) via deep-dielectric charging. Forecasting flux gives
operators a warning
window.
INPUTS:
- Electron flux (target variable): GOES satellite >2 MeV integral electron flux,
CDF format, ~11 years
of data. Source: NGDC ([Link]/stp/satellite/[Link]), also mirrored
on CDAWeb. Note:
GOES-19 became operational GOES-East in April 2025, replacing GOES-16 -- data
spans multiple
instrument generations (GOES-13/15 EPEAD, GOES-16/17/18 SEISS, GOES-19).
- Solar wind drivers: solar wind speed (Vsw), IMF Bz/By/Bx, proton density (Nsw),
~11 years.
Source: CDAWeb OMNI dataset ([Link]) -- use OMNI2_H0_MRG1HR
(hourly) or
OMNI_HRO2_5MIN / OMNI_HRO2_1MIN for higher resolution. Already time-shifted to
bow shock; includes
Kp/Dst/AE indices. Accessible via HAPI API with the hapiclient Python package.
- Validation data: ISRO's GRASP payload on GSAT-19, electron flux at Indian
longitude, ~1-2 years.
Source: PRADAN portal ([Link]/grasp), requires registration.
PIPELINE (per the mentors' own slide): Read & Visualize (CDF parsing) ->
Preprocess (remove spikes,
interpolate gaps) -> Feature Select (solar wind variables, correlation analysis) -
> Train AI/ML
(LSTM/Transformer/TCN, time-series forecast) -> Validate & Test (30-45 min, 6h,
12h forecasts,
cross-validated against GRASP).
EVALUATION CRITERIA: domain understanding of solar wind/radiation belts;
correctness of data
reading/visualization; AI/ML model identification and optimization; prediction
Page 8
Bharatiya Antariksh Hackathon 2026 — Electron Flux Forecasting
accuracy at GEO.
CONSTRAINTS: hackathon timeline (~2-3 days), student team, must produce a working
demo with
visualization, not just a model in a notebook.
Document prepared from the Bharatiya Antariksh Hackathon 2026 — Problem Statement Session 2 briefing.
Page 9