Solar Guard transforms real geomagnetic observations and open geospatial infrastructure data into a location-specific assessment of where a geomagnetic event could matter most, why, and how certain the assessment is.
Live Application:
[DEPLOYMENT_LINK_TO_BE_ADDED]
Backend API:
[BACKEND_DEPLOYMENT_LINK_TO_BE_ADDED]
Frontend Repository:
[FRONTEND_REPOSITORY_LINK_TO_BE_ADDED]
Backend Repository:
[BACKEND_REPOSITORY_LINK_TO_BE_ADDED]
Demo Video:
[DEMO_VIDEO_LINK_TO_BE_ADDED]
Solar Guard is a space-weather decision-support system focused on the infrastructure consequences of geomagnetic storms.
Existing scientific and operational systems already provide:
- solar observations
- CME detection
- solar-wind measurements
- geomagnetic indices
- space-weather forecasts
- geoelectric-field modeling
- GIC modeling frameworks
Solar Guard does not attempt to replace those systems.
Instead, it addresses a different question:
Given a geomagnetic event, where could it matter most across a region's power infrastructure, why, and how certain is that assessment?
The current MVP focuses on Egypt.
The system combines:
- Real ground-magnetic observations from Tamanrasset, Algeria.
- A spatially varying global Earth-conductivity model.
- Frequency-domain magnetotelluric calculations.
- A modeled horizontal geoelectric field over Egypt.
- OpenStreetMap transmission infrastructure.
- Numerical integration of the geoelectric field along transmission corridors.
- Infrastructure exposure ranking.
- Substation exposure indicators.
- Qualitative uncertainty information.
- A React-based command-center frontend.
The final system connects the scientific model to a practical infrastructure-oriented interface.
Solar Guard is designed around four questions:
What geomagnetic and space-weather conditions are present?
Which geographic regions and mapped transmission corridors have the largest modeled exposure?
What physical and infrastructure characteristics contribute to that exposure?
Which parts of the assessment depend on proxies, models, incomplete infrastructure data, or unavailable electrical-network information?
Solar Guard is not another solar-storm dashboard.
A conventional space-weather dashboard may tell an operator:
"A strong geomagnetic storm is occurring."
Solar Guard attempts to continue the chain:
SPACE WEATHER
↓
EARTH RESPONSE
↓
GEOELECTRIC FIELD
↓
POWER INFRASTRUCTURE
↓
MODELED EXPOSURE
↓
PRIORITY RANKING
↓
EXPLANATION + UNCERTAINTY
The additional value is therefore the combination of:
Space Weather
+
Earth Conductivity
+
Geoelectric Modeling
+
Geospatial Infrastructure
+
Exposure Analysis
+
Uncertainty
=
Location-Specific Decision Support
The system does not claim to predict equipment failure.
It identifies where the modeled electromagnetic exposure is greatest within the available infrastructure dataset.
Solar Guard currently implements two levels of the broader space-weather infrastructure problem.
Solar Guard estimates the horizontal geoelectric field:
Ex(x, y, t)
Ey(x, y, t)
|E(x, y, t)|
across an Egypt-wide spatial grid.
These quantities represent the modeled horizontal electric field generated by the geomagnetic disturbance interacting with the modeled Earth conductivity structure.
For each mapped transmission corridor, Solar Guard evaluates:
V_L(t) = ∫L E(r,t) · dl
Numerically, this is implemented as:
V_L ≈ Σ(E · dl)
where:
Eis the modeled horizontal geoelectric field.dlis the local transmission-line segment vector.V_Lis the modeled induced line voltage in volts.
This is the primary physical exposure quantity used by Solar Guard.
Actual geomagnetically induced current requires an electrical network model.
A complete GIC calculation would require information such as:
Transmission-line resistance
Network topology
Transformer configuration
Transformer grounding impedance
Transformer electrical characteristics
Network admittance
Electrical connectivity
The open infrastructure dataset used by the MVP does not provide these parameters reliably.
Therefore Solar Guard deliberately stops at:
Geoelectric Field
↓
Induced Line Voltage
↓
Infrastructure Exposure
↓
Priority Ranking
rather than claiming:
Geoelectric Field
↓
GIC Current
↓
Transformer Heating
↓
Equipment Failure
This boundary is intentional.
Solar Guard calculates:
- modeled geoelectric field
- signed
Ex - signed
Ey - field magnitude
- transmission-line induced voltage exposure
- infrastructure exposure ranking
- qualitative uncertainty
Solar Guard does not calculate:
- actual GIC current
- transformer current
- transformer heating
- transformer damage
- transformer failure probability
- grid-collapse probability
- utility-grade electrical topology
- grounding resistance
- transmission-line resistance where unavailable
- transformer winding configuration where unavailable
Therefore the correct interpretation is:
Solar Guard estimates modeled electromagnetic exposure across mapped power infrastructure. It does not predict equipment failure.
The complete physical chain implemented by Solar Guard is:
Ground Magnetic Observation
↓
Magnetic Signal Processing
↓
FFT
↓
Frequency-Domain Magnetic Field
↓
1-D Magnetotelluric Impedance
↓
E(f) = Z(f)B(f) / μ₀
↓
IFFT
↓
Signed Time-Domain Ex / Ey
↓
Egypt Spatial Grid
↓
Transmission-Line Geometry
↓
E · dl Projection
↓
Numerical Line Integration
↓
Modeled Induced Line Voltage
↓
Exposure Ranking
The current MVP uses Tamanrasset Observatory in Algeria as the magnetic forcing source.
IAGA code: TAM
Latitude: 22.792° N
Longitude: 5.530° E
Sampling: 1 minute
Components: X / Y / Z / F
Period: 10–12 May 2024
Records: 4,320
Format: IAGA-2002
Source file:
data/tam20240510dmin.min
TAM provides a reproducible ground-magnetic dataset for the selected storm period.
Egypt-specific magnetic observatories were investigated, including:
- Misallat (MLT)
- Abu Simbel (ABS)
- Alexandria Magnetometer and Telluric Station (AMTS)
A verified publicly downloadable dataset covering the required May 10–12, 2024 period was not available for the Egyptian stations used during the MVP development.
TAM was therefore selected as the reproducible magnetic forcing dataset.
TAM is located in Algeria, not Egypt.
It is therefore used as a regional low-latitude magnetic forcing proxy.
Solar Guard must not describe the TAM observations as measured Egyptian geomagnetic conditions.
The correct wording is:
Tamanrasset (TAM), Algeria ground magnetic forcing used as a regional low-latitude proxy for the Egypt model.
This limitation is explicitly exposed in the system's uncertainty information.
Solar Guard uses the global conductivity model:
data/MODEL-VER-5.mat
The model contains spatially varying conductivity information.
Important arrays include:
LATGRID
LONGRID
MODEL
ZGRID
The validated model dimensions are:
Depth layers: 1000
Longitude positions: 1440
Latitude positions: 720
The validated mapping is:
LATGRID[0, :] → latitude axis
LONGRID[:, 0] → longitude axis
MODEL[depth, lon, lat]
This mapping was cross-checked against the raw MATLAB file.
For each Solar Guard Egypt grid point:
- Locate the nearest conductivity-model cell.
- Extract the corresponding depth profile.
- Validate the profile.
- Apply the profile to the 1-D MT calculation.
Each generated profile contains:
1000 layers
Positive conductivity
Finite values
MODEL-VER-5.mat is approximately 239 MB.
It is intentionally excluded from Git tracking because GitHub's standard file-size limit is 100 MB.
The file is therefore expected to exist locally or be provided through the project's data distribution process.
The repository should not contain a Git-tracked copy of this large file.
Solar Guard generates a regular grid covering the Egypt modeling region.
Latitude:
22°N → 32°N
Longitude:
25°E → 37°E
Spacing:
0.5°
Total:
525 points
The grid is used to generate the spatial geoelectric-field product.
Each point contains modeled field information including:
Latitude
Longitude
Peak E
Peak Ex
Peak Ey
The signed components are preserved.
This is important because the direction of the electric field determines how strongly a transmission line couples to it.
The magnetic time series is transformed into the frequency domain.
Conceptually:
B(t)
↓
FFT
↓
B(f)
The frequency-domain magnetic signal is combined with the Earth-response impedance.
The relationship is:
E(f) = Z(f) B(f) / μ₀
where:
B(f)is the frequency-domain magnetic field.Z(f)is the magnetotelluric impedance.μ₀is the magnetic permeability of free space.E(f)is the frequency-domain electric field.
The resulting field is converted back to the time domain using an inverse FFT.
The backend calculates frequency-dependent Earth response using the conductivity profile associated with each location.
The 1-D MT solver was validated against synthetic cases.
Validation includes:
- frequency behavior
- zero-frequency handling
- finite outputs
- absence of NaN/Infinity
- expected impedance relationships
The implementation also handles DFT frequencies correctly across the Nyquist boundary.
Positive-frequency impedance values are mirrored using the appropriate complex conjugation for the negative-frequency bins.
This preserves the Hermitian structure required for a physically real time-domain signal.
A critical validation issue was identified and corrected during development.
The original implementation used:
Math.hypot(real, imaginary)
to extract the time-domain field.
That operation destroys the sign of the real signal.
For infrastructure exposure, this is physically important because:
E · dl
depends on direction.
The implementation was corrected to use the real component of the IFFT output:
real(IFFT(E))
after ensuring the frequency-domain impedance is properly mirrored.
As a result, the Egypt grid now preserves signed:
Ex
Ey
rather than only their magnitudes.
Solar Guard uses OpenStreetMap power infrastructure.
The MVP processes:
2,051 transmission lines
703 substations
The infrastructure dataset can contain:
- geometry
- line length
- voltage information
- asset identifiers
- substation locations
- other available OSM metadata
The data is treated as open-source infrastructure mapping rather than an authoritative utility network.
This is the central infrastructure calculation.
For each transmission line, the backend:
- Reads the line geometry.
- Samples the geometry.
- Interpolates the geoelectric field along the line.
- Determines the local line direction.
- Projects the electric field onto that direction.
- Integrates the projected field along the line.
The physical relationship is:
V_L = ∫L E · dl
The numerical implementation is approximately:
V_L ≈ Σ(E_parallel,i × Δl_i)
where:
E_parallel = E · l_hat
and:
l_hat = local line-direction unit vector
The result has units:
(V/km) × km = V
Long transmission corridors cannot be represented accurately by evaluating the field only at their midpoint.
Solar Guard samples each line using segments no larger than approximately:
25 km
The implementation uses:
Math.ceil(segmentLength / 25)
to determine the required subdivision.
This allows the modeled electric field to vary spatially along the transmission corridor.
The electric field is directional.
A transmission line aligned with the local electric field can experience stronger coupling than a line oriented perpendicular to it.
Conceptually:
E parallel to line
↓
large E · dl
↓
larger induced voltage
whereas:
E perpendicular to line
↓
small E · dl
↓
small induced voltage
This is why Solar Guard retains signed Ex and Ey instead of reducing everything to scalar field magnitude.
Line length is naturally included in:
V_L = ∫ E · dl
A longer conductor can accumulate a larger potential difference when the field remains coherently oriented along it.
Length is therefore part of the physical line-integral calculation.
It is not introduced as an arbitrary ranking multiplier.
For each transmission line, Solar Guard can expose metrics including:
Peak induced voltage
Peak local E-field
Peak parallel E-field
Line length
Orientation/alignment
Voltage class
Exposure class
Priority
Confidence
Data quality
The primary physical ranking variable is:
Peak |V_L|
Solar Guard intentionally separates two concepts.
How large is the modeled electromagnetic exposure?
Primary quantity:
Peak |V_L|
How relevant is the exposed infrastructure for decision support?
Context may include:
Exposure magnitude
Asset type
Voltage class
Infrastructure metadata
Spatial relationships
Data completeness
These are not combined into an arbitrary scientific risk equation.
The system does not use a formula such as:
Risk =
0.4 × E
+ 0.3 × Voltage
+ 0.2 × Length
+ ...
because such weights would not have a validated scientific basis for this application.
The backend can classify assets relative to the generated event distribution.
Examples include:
TOP_1_PERCENT
TOP_5_PERCENT
TOP_10_PERCENT
MODERATE
LOW
These are relative ranking categories.
For example:
TOP_1_PERCENT
means:
The asset belongs to the highest-exposure portion of the modeled scenario.
It does not mean:
1% probability of failure.
The current MVP does not contain verified utility electrical topology.
Therefore Solar Guard does not claim that a mapped transmission line is electrically connected to a specific substation merely because the geometries are nearby.
Instead, substations use a spatial association approach based on nearby mapped infrastructure.
The system explicitly identifies this as:
Spatial association, not verified electrical topology.
Substation indicators include:
Maximum nearby line exposure
Number of nearby mapped lines
Maximum local modeled E
Voltage/context information
Data completeness
Voltage level is useful infrastructure metadata.
It is not used as a GIC calculation multiplier.
Solar Guard does not assume:
500 kV = more GIC
220 kV = less GIC
or:
500 kV = 5 × GIC
Actual GIC depends on the electrical network.
Voltage class is therefore used to describe infrastructure context and support prioritization, not to determine the physical electromagnetic forcing.
Solar Guard uses qualitative component-level uncertainty.
It does not manufacture numerical probabilities.
Current categories include:
Magnetic forcing: MEDIUM
Earth response: MEDIUM
Infrastructure: MEDIUM
Electrical topology: UNAVAILABLE
These labels describe limitations in the underlying model and data.
They are not statistical confidence intervals.
They should not be interpreted as:
73% confidence
87% confidence
unless a calibrated uncertainty model is introduced in the future.
TAM is located in Algeria and is used as a regional proxy.
TAM
↓
Regional magnetic forcing
↓
Egypt
This introduces geographic uncertainty.
The conductivity structure is modeled rather than measured continuously throughout Egypt.
The global conductivity model is therefore an approximation of the real local Earth response.
OpenStreetMap is incomplete relative to utility-grade infrastructure databases.
Missing or outdated infrastructure can affect the exposure map.
Actual electrical connectivity, grounding, line resistance and transformer characteristics are unavailable.
Therefore:
Actual GIC confidence:
UNAVAILABLE
rather than a fabricated probability.
The system exposes data-quality information where possible.
Infrastructure confidence is affected by factors such as:
Geometry completeness
Voltage metadata availability
Infrastructure source
Spatial coverage
A missing voltage value is not automatically interpreted as low voltage.
It is treated as missing information.
A future extension can evaluate whether infrastructure remains highly ranked under multiple scientifically justified scenarios.
For example:
Scenario A → Rank 3
Scenario B → Rank 5
Scenario C → Rank 4
This could support a statement such as:
Priority stability: HIGH
provided the scenarios are scientifically justified.
Solar Guard does not create arbitrary scenarios simply to manufacture confidence percentages.
┌────────────────────┐
│ TAM Magnetic │
│ Data │
└──────────┬─────────┘
│
▼
┌────────────────────┐
│ Data Ingestion & │
│ Normalization │
└──────────┬─────────┘
│
▼
┌────────────────────┐
│ FFT / Frequency │
│ Domain │
└──────────┬─────────┘
│
▼
┌────────────────────┐
│ Conductivity / │
│ 1-D MT Model │
└──────────┬─────────┘
│
▼
┌────────────────────┐
│ Geoelectric │
│ Field Ex / Ey │
└──────────┬─────────┘
│
▼
┌────────────────────┐
│ Egypt Spatial │
│ Grid │
└──────────┬─────────┘
│
▼
┌────────────────────┐
│ OSM Infrastructure │
└──────────┬─────────┘
│
▼
┌────────────────────┐
│ E · dl Line │
│ Integration │
└──────────┬─────────┘
│
▼
┌────────────────────┐
│ Exposure / Priority│
│ Ranking │
└──────────┬─────────┘
│
▼
┌────────────────────┐
│ REST API │
└──────────┬─────────┘
│
▼
┌────────────────────┐
│ Solar Guard │
│ Frontend │
└────────────────────┘
The backend contains the scientific and API implementation.
Important areas include:
Server/
├── src/
│ ├── routes/
│ │ └── geoelectric.routes.ts
│ │
│ ├── services/
│ │ ├── geoelectric/
│ │ │ ├── GeoelectricCalculator.ts
│ │ │ └── OneDimensionalMTService.ts
│ │ │
│ │ ├── exposure/
│ │ │ └── InfrastructureExposureService.ts
│ │ │
│ │ └── ground-model/
│ │ └── ConductivityModelService.ts
│ │
│ └── ...
│
├── scripts/
│ ├── run_full_pipeline.js
│ ├── run_egypt_grid.js
│ ├── run_infrastructure_exposure.js
│ ├── run_mt_tests.js
│ ├── run_synthetic_test.js
│ └── test_infrastructure_exposure.js
│
├── data/
│ ├── tam20240510dmin.min
│ ├── conductivity_tam_column.json
│ ├── egypt_conductivity_grid.json
│ ├── egypt_geoelectric_grid.json
│ └── egypt_infrastructure_exposure.json
│
└── package.json
The exact structure may evolve as implementation changes.
The backend exposes the scientific results through REST endpoints.
GET /api/healthUsed by the frontend to determine whether the backend and database are available.
Example response:
{
"status": "ok",
"database": "connected",
"version": "0.1.0"
}GET /api/geoelectric/calculate?stormId=<STORM_ID>Provides the modeled geoelectric calculation for the selected forcing scenario.
The response can contain:
Station
Record count
Timestamps
Ex
Ey
E magnitude
Peak statistics
Model metadata
Magnetic forcing metadata
The frontend should summarize this information rather than rendering thousands of raw samples unnecessarily.
GET /api/geoelectric/egypt-gridReturns the Egypt spatial geoelectric-field product.
Current grid:
525 points
Important quantities:
lat
lon
peakE_V_per_km
peakEx_V_per_km
peakEy_V_per_km
GET /api/geoelectric/infrastructure-exposureReturns the complete infrastructure exposure dataset.
Current dataset:
2,051 transmission lines
703 substations
GET /api/geoelectric/infrastructure-exposure?assetType=line&limit=20Returns the highest-ranked transmission lines.
GET /api/geoelectric/infrastructure-exposure?assetType=substation&limit=20Returns the highest-ranked substation exposure indicators.
GET /api/space-weather/currentThe frontend uses this endpoint for available current space-weather information, including available:
Solar-wind speed
Bz
Density
Kp
Dst
Sym-H
Active CMEs
Space-weather alerts
Values are sourced by the backend and are not fabricated by the frontend.
The backend is the scientific source of truth.
The frontend must not independently recalculate exposure.
The backend performs:
E-field interpolation
↓
Line segmentation
↓
E · dl projection
↓
Numerical integration
↓
Peak exposure
↓
Ranking
The frontend consumes and visualizes the resulting values.
This prevents inconsistent scientific results between the backend and frontend.
The frontend is the command-center and decision-support layer of Solar Guard.
Technology:
React
TypeScript
Vite
Leaflet
Its purpose is not to perform the scientific calculations.
Its purpose is to make the backend's scientific results understandable and actionable.
SOLAR GUARD BACKEND
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
Geoelectric Exposure Space Weather
API API API
│ │ │
└──────────────┼──────────────┘
▼
Frontend API Layer
│
▼
Dashboard Context
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
EgyptRiskMap PriorityRanking AssessmentPanel
│ │ │
└─────────────────┼─────────────────┘
▼
Decision Support UI
Centralizes backend-derived dashboard state.
It loads:
- geoelectric grid
- transmission exposure
- substation exposure
- geoelectric calculation information
- selected infrastructure asset
- loading states
- error states
The primary geographic visualization.
It displays:
- Egypt
- modeled geoelectric grid
- transmission lines
- substations
- exposure information
- selected infrastructure
The map uses real backend data rather than demonstration infrastructure.
Displays the highest-ranked infrastructure according to the backend.
Typical information includes:
Rank
Asset
Peak induced voltage
Voltage class
Line length
Exposure class
Priority
Confidence
The frontend does not create another scientific ranking formula.
Displays details for the selected infrastructure asset.
Peak induced voltage
Peak E-field
Peak parallel E-field
Line length
Orientation / alignment
Asset type
Voltage class
Infrastructure metadata
Spatial association information
Exposure class
Priority
Confidence
Magnetic forcing
Earth response
Infrastructure
Electrical topology
The interface communicates that the result represents:
Modeled electromagnetic infrastructure exposure, not a prediction of GIC current or equipment failure.
The panel consumes real backend space-weather data.
It can display:
Solar wind speed
Bz
Density
Kp
Dst
Sym-H
Active CME information
Space-weather alerts
The frontend does not generate random telemetry.
Unavailable backend values are not replaced with fake values.
The frontend uses:
GET /api/healthto display actual backend status.
It can communicate:
Backend availability
Database connectivity
Service status
Version
Static fake indicators such as:
LIVE
CONNECTED
NOMINAL
are not treated as authoritative system state.
The current backend does not provide a scientifically implemented simulation engine.
Therefore the frontend does not fabricate simulation results.
The current simulation controls are disabled or clearly marked unavailable where the backend returns:
501 NOT_IMPLEMENTED
A future simulation implementation can be added when a scientifically defined backend scenario model exists.
Solar Guard has no hardware component.
The project architecture is:
Data
↓
Scientific Processing
↓
Geoelectric Model
↓
Infrastructure Exposure
↓
Priority Ranking
↓
REST API
↓
Frontend
There is no:
ESP32
Arduino
Relay
LED hardware demonstration
in the current system.
A typical user interaction is:
Backend API
↓
API service layer
↓
DashboardContext
↓
Frontend state
↓
┌───────────────┬────────────────┬─────────────────┐
│ │ │ │
▼ ▼ ▼ ▼
Map Ranking Assessment Space Weather
│ │ │ │
└───────────────┴────────────────┴─────────────────┘
↓
Decision Support
When a user selects a transmission corridor:
User selects asset
↓
Frontend selection state
↓
Map highlights asset
↓
AssessmentPanel updates
↓
Exposure + priority + confidence displayed
The underlying scientific calculation remains unchanged.
A typical Solar Guard session is:
The command-center interface loads.
The frontend checks backend health.
The user can inspect available:
Solar wind
Bz
Density
Kp
Dst
Sym-H
CME information
Alerts
The user sees:
Modeled geoelectric field
Transmission infrastructure
Substations
Exposure information
The user reviews infrastructure with the highest modeled exposure.
Selecting an infrastructure asset displays:
Peak induced voltage
Peak E-field
Line length
Orientation
Voltage
Exposure
Priority
Confidence
Uncertainties
The system explains:
WHERE
WHY
HOW LARGE
HOW CERTAIN
WHAT IS MISSING
A representative line may be displayed conceptually as:
Asset
Transmission Corridor
Physical Exposure
Peak induced voltage: 45.56 V
Peak E-field: ...
Peak parallel E: ...
Line length: ...
Infrastructure
Voltage: 220 kV
Asset type: Transmission line
Assessment
Exposure: TOP_1_PERCENT
Priority: HIGH
Confidence: MEDIUM
Why
• Strong modeled E-field
• Strong field/line coupling
• Long transmission corridor
Uncertainties
• TAM regional magnetic proxy
• Global conductivity model
• OpenStreetMap completeness
• Electrical topology unavailable
Interpretation
Modeled geomagnetic infrastructure exposure.
Not a prediction of GIC current or equipment failure.
The current validated MVP produces:
Egypt geoelectric grid:
525 points
Transmission lines:
2,051
Substations:
703
Failed transmission-line calculations:
0
Failed substation calculations:
0
Representative exposure statistics from the validated scenario include:
Maximum modeled line exposure:
≈45.56 V
Mean absolute line exposure:
≈1.0083 V
Median absolute line exposure:
≈0.1105 V
These values describe the modeled scenario.
They are not failure predictions.
Representative results from the current generated dataset include:
way/263365109 220 kV ≈45.56 V
way/213209222 220 kV ≈35.53 V
way/524099262 500 kV ≈32.26 V
way/448834353 220 kV ≈29.03 V
way/923817894 500 kV ≈28.85 V
way/93699956 500 kV ≈28.74 V
way/865347525 220 kV ≈26.20 V
These values represent modeled induced-voltage exposure.
They do not mean:
Transformer failure
GIC current
Equipment damage
Grid collapse
The induced-voltage calculation is physically connected to the geoelectric field.
The relationship is:
Earth response
↓
Geoelectric field
↓
Projection onto conductor
↓
Line-integrated voltage
This is fundamentally different from an arbitrary score.
The system does not claim:
Risk = 0.7
without a physical interpretation.
Instead it reports a measurable modeled quantity:
Peak induced line voltage
and then separately provides infrastructure context and uncertainty.
Actual GIC data would be useful for validating or calibrating a full electrical-network model.
However, the MVP's objective is different.
Solar Guard asks:
Where does the modeled geomagnetic disturbance create the greatest infrastructure exposure?
The available data supports:
Ground magnetic forcing
↓
Geoelectric field
↓
Induced line voltage
↓
Infrastructure exposure
It does not support:
GIC current
↓
Transformer heating
↓
Failure probability
without additional utility-specific electrical parameters.
Therefore adding a fabricated GIC model would reduce scientific credibility rather than improve the MVP.
This transmission corridor has the highest modeled induced-voltage exposure under the selected storm scenario.
The corridor experiences strong modeled field coupling because of its location and orientation.
The asset is classified as high-voltage in the available infrastructure data.
The result is based on TAM regional magnetic forcing, a global conductivity model, and OpenStreetMap infrastructure.
This asset is among the highest modeled exposure assets in the scenario.
This transformer will fail.
This line will experience 100 A GIC.
This asset has a 70% probability of failure.
Egypt's grid will collapse.
500 kV lines experience five times more GIC.
The current data does not support these statements.
The backend scientific pipeline has undergone targeted validation.
npm run build
Status:
PASS
Synthetic testing verifies:
FFT/IFFT reconstruction
and the relationship between the magnetic and electric-field frequency-domain quantities.
The reconstruction was verified to high numerical precision.
The 1-D MT solver was tested for:
Expected sqrt(f) behavior
Zero-frequency behavior
Finite output
No NaN/Infinity
Synthetic line tests verify:
Parallel field → expected voltage
Perpendicular field → approximately zero voltage
Multi-segment line → correct integrated voltage
Units → correct
The complete geoelectric pipeline was validated.
Representative result:
Peak modeled |E| ≈ 0.1583 V/km
with signed Ex/Ey and physically consistent IFFT output.
Validation:
525 / 525 points successful
0 failures
No NaN
No Infinity
Signed Ex/Ey preserved
Validation:
2,051 lines
0 failures
703 substations
0 failures
All exposure values finite
The conductivity mapping was cross-checked against the raw MATLAB model.
Verified:
LATGRID[0,:] → latitude
LONGRID[:,0] → longitude
MODEL[depth,lon,lat]
Each generated Egypt profile contains:
1000 layers
Positive conductivity
Finite values
The current TAM dataset contains:
4,320 records
1-minute sampling
May 10–12, 2024
IAGA-2002 format
The integrated frontend has been validated through:
TypeScript compilation
Vite production build
Backend connectivity
API consumption
Egypt grid loading
Infrastructure loading
Priority ranking
Asset selection
Assessment updates
Space-weather loading
Backend health status
Production frontend build:
TypeScript:
PASS
Vite:
PASS
The frontend consumes the real backend data rather than relying on mock infrastructure data.
The following endpoints have been verified:
GET /api/health
GET /api/geoelectric/calculate
GET /api/geoelectric/egypt-grid
GET /api/geoelectric/infrastructure-exposure
GET /api/geoelectric/infrastructure-exposure?assetType=line&limit=5
GET /api/geoelectric/infrastructure-exposure?assetType=substation&limit=5
GET /api/space-weather/current
The frontend consumes the relevant endpoints directly through its API layer.
Solar Guard is an MVP.
The major limitations are:
TAM is located in Algeria.
It is not an Egyptian magnetic observatory.
The Earth response is based on a global conductivity model rather than a complete Egypt-specific 3-D conductivity inversion.
OpenStreetMap does not represent the complete utility-grade Egyptian transmission network.
The system does not have complete verified electrical connectivity.
Substation associations are spatial, not electrical.
Actual GIC is not calculated.
Transformer heating, saturation, damage and failure are not calculated.
The current Egypt spatial grid product represents spatial peak-field information rather than a synchronized full time series at every grid point.
Therefore the infrastructure product should be interpreted as a:
Modeled peak spatial exposure scenario.
A full scientifically implemented scenario simulation engine is not currently part of the backend.
The large conductivity model is not tracked in Git.
Sensitive or environment-specific configuration should be stored using environment variables rather than committed secrets.
Do not commit:
.env
API keys
Database credentials
Private infrastructure datasets
Large generated binaries
The frontend should communicate with the configured backend URL rather than embedding credentials in client-side code.
Recommended environment:
Node.js
npm
Git
The exact supported Node version should follow the project's current package configuration.
git clone [BACKEND_REPOSITORY_LINK_TO_BE_ADDED]
cd Solar-GuardIf the project is organized with separate frontend and backend repositories:
git clone [BACKEND_REPOSITORY_LINK_TO_BE_ADDED]
git clone [FRONTEND_REPOSITORY_LINK_TO_BE_ADDED]Move into the backend directory:
cd ServerInstall dependencies:
npm installCreate the required environment configuration if the project provides an .env.example:
copy .env.example .envor on macOS/Linux:
cp .env.example .envConfigure the required database/API variables according to the project's environment configuration.
Do not commit the .env file.
The scientific MVP requires the relevant data artifacts.
At minimum, the modeling pipeline uses:
data/tam20240510dmin.min
data/MODEL-VER-5.mat
Generated products include:
data/conductivity_tam_column.json
data/egypt_conductivity_grid.json
data/egypt_geoelectric_grid.json
data/egypt_infrastructure_exposure.json
The 239 MB conductivity model is intentionally not committed to Git.
Run:
npm run buildExpected result:
TypeScript compilation succeeds
Use the development/start command defined in the backend package.json.
For example, if the project exposes a development script:
npm run devThe exact command should always be taken from the current package.json.
Once running, verify:
http://localhost:<BACKEND_PORT>/api/health
Move into the frontend directory:
cd ClientInstall dependencies:
npm installConfigure the backend API URL using the frontend's environment configuration.
Example placeholder:
VITE_API_URL=[BACKEND_LOCAL_OR_DEPLOYED_URL]
The exact variable name should follow the frontend project's current configuration.
Start the development server using the script defined in the frontend package.json.
For example:
npm run devThe frontend is typically available at:
http://localhost:5173
The backend must be running at the configured API URL.
For a complete local demonstration:
cd Server
npm install
npm run devcd Client
npm install
npm run devThen open:
http://localhost:5173
The frontend should connect to the backend and load:
Health
Space weather
Egypt geoelectric grid
Transmission infrastructure
Substations
Exposure ranking
cd Server
npm install
npm run buildcd Client
npm install
npm run buildThe resulting frontend build is generated in:
Client/dist/
The backend deployment should expose the API routes required by the frontend.
The final deployment architecture is:
INTERNET
│
┌──────────┴──────────┐
│ │
▼ ▼
FRONTEND HOST BACKEND HOST
│ │
│ ▼
│ Scientific Pipeline
│ │
│ ▼
│ REST API
│ │
└──────────────►──────┘
Deployment URLs will be added here:
Live Frontend:
[DEPLOYMENT_LINK_TO_BE_ADDED]
Backend API:
[BACKEND_DEPLOYMENT_LINK_TO_BE_ADDED]
API Health:
[BACKEND_HEALTH_URL_TO_BE_ADDED]
API Documentation:
[API_DOCUMENTATION_LINK_TO_BE_ADDED]
Before deployment:
[ ] Backend builds successfully
[ ] Frontend builds successfully
[ ] Environment variables configured
[ ] Backend API publicly reachable
[ ] CORS configured correctly
[ ] Frontend points to deployed backend
[ ] /api/health returns successfully
[ ] /api/space-weather/current returns successfully
[ ] /api/geoelectric/egypt-grid returns successfully
[ ] /api/geoelectric/infrastructure-exposure returns successfully
[ ] Map loads
[ ] Transmission lines load
[ ] Substations load
[ ] Priority ranking loads
[ ] Assessment panel works
[ ] No fake scientific data appears
[ ] No secrets committed
The backend can return:
525 geoelectric points
2,051 transmission lines
703 substations
The frontend therefore avoids repeatedly requesting these datasets unnecessarily.
Large scenario datasets should generally be loaded once and stored in application state.
Asset selection should update the selected asset rather than reloading the entire infrastructure dataset.
Memoization should be used where it provides an actual performance benefit.
The frontend handles:
Backend unavailable
HTTP errors
Malformed responses
Empty datasets
Missing optional fields
Loading states
Unavailable simulation
The frontend should not silently fall back to fabricated scientific data.
Examples of acceptable states:
Backend unavailable
Exposure data could not be loaded.
Space-weather data unavailable.
Simulation unavailable.
The frontend must preserve the difference between:
Ex
Ey
|E|
It must not silently convert directional fields into magnitudes.
Likewise, it must distinguish:
Exposure
Priority
Confidence
These are not interchangeable.
The frontend uses a technical command-center aesthetic.
The interface prioritizes:
- map-centered visualization
- dense but readable information
- technical telemetry
- clear hierarchy
- dark engineering visual language
- restrained animation
- strong critical/elevated/nominal states
- professional typography
- scientific transparency
The visual design exists to communicate the backend's results rather than distract from them.
When opening Solar Guard, a user should quickly understand:
WHAT IS HAPPENING?
↓
SPACE-WEATHER CONDITIONS
WHERE COULD IT MATTER?
↓
EGYPT GEOELECTRIC FIELD + INFRASTRUCTURE
WHY?
↓
FIELD + LOCATION + ORIENTATION + LENGTH
HOW CERTAIN?
↓
MODEL / DATA UNCERTAINTY
WHAT WAS NOT CALCULATED?
↓
ACTUAL GIC + FAILURE
Consider a transmission corridor.
TAM records the geomagnetic disturbance.
The backend processes the magnetic time series.
FFT transforms the magnetic signal into frequency space.
The 1-D MT solver determines the frequency-dependent Earth response.
The conductivity profile associated with an Egypt grid cell is applied.
The frequency-domain electric field is calculated.
IFFT converts the field back into the time domain.
The signed Ex/Ey field is generated.
The Egypt geoelectric grid is produced.
A transmission corridor is sampled into local segments.
The electric field is interpolated at those locations.
The field is projected onto the line direction.
The projected field is integrated along the corridor.
The resulting modeled induced voltage is obtained.
The corridor is compared with other mapped infrastructure.
The backend assigns exposure/priority information.
The API exposes the result.
The frontend displays:
WHERE
WHY
HOW LARGE
HOW CERTAIN
WHAT IS MISSING
This is the complete Solar Guard workflow.
The complete current MVP consists of:
1. Obtain real magnetic observations
2. Process magnetic data
3. Calculate frequency-domain response
4. Apply spatial Earth conductivity
5. Generate geoelectric field over Egypt
6. Map transmission infrastructure
7. Integrate modeled E-field along transmission lines
8. Rank infrastructure by induced-voltage exposure
9. Associate exposure with mapped substations
10. Expose results through REST APIs
11. Provide uncertainty and limitations
12. Connect results to the command-center frontend
Solar Guard does not replace:
- NOAA space-weather forecasting
- NASA solar observations
- INTERMAGNET observations
- detailed utility GIC models
- utility operational systems
- transformer engineering analysis
- national grid control systems
Instead, it builds a location-specific infrastructure-exposure layer on top of scientific space-weather information.
The strongest aspect of Solar Guard is not a claim that it predicts failures.
Its strength is that every layer has a defined interpretation:
Magnetic data
↓
Measured geomagnetic forcing
Conductivity model
↓
Earth-response approximation
Geoelectric field
↓
Modeled environmental hazard
Line integral
↓
Modeled conductor exposure
Infrastructure metadata
↓
Context for prioritization
Uncertainty
↓
Transparency about limitations
The system therefore avoids converting incomplete data into false precision.
Solar Guard follows one central rule:
Calculate what the available data can physically support, and explicitly stop where the required information is unavailable.
This is why the system reports modeled induced voltage instead of inventing GIC current.
It is also why the system reports qualitative uncertainty instead of fabricated confidence percentages.
Solar Guard takes real geomagnetic observations and a spatial Earth-conductivity model to estimate the horizontal geoelectric field across Egypt. We then combine that field with open transmission-infrastructure data and integrate the electric field along each transmission corridor to estimate modeled storm-induced line voltage. We rank infrastructure by that physical exposure and explicitly show uncertainty. We stop before calculating actual GIC or transformer failure because that would require detailed electrical-network and grounding parameters that we do not have.
The backend starts with one-minute TAM ground-magnetic observations from May 10–12, 2024. The magnetic signal is transformed into the frequency domain, combined with a spatially varying 1-D magnetotelluric impedance derived from a global conductivity model, and converted back to signed time-domain Ex and Ey fields. We generate this response over a 0.5-degree Egypt grid containing 525 points. We then process 2,051 OpenStreetMap transmission corridors and numerically evaluate the line integral
V_L = ∫ E · dl. The resulting modeled induced voltage provides a physically meaningful infrastructure-exposure metric. We deliberately do not infer GIC current or failure probability because the electrical network parameters required for that level of modeling are unavailable.
| Area | Status |
|---|---|
| Magnetic data ingestion | Validated |
| Magnetic preprocessing | Validated |
| FFT/IFFT pipeline | Validated |
| 1-D MT solver | Validated |
| Conductivity mapping | Validated |
| Egypt geoelectric grid | Validated |
| Infrastructure mapping | Validated |
| Transmission-line integration | Validated |
| Exposure ranking | Implemented and validated |
| Substation spatial association | Implemented |
| Uncertainty representation | Implemented |
| REST API | Implemented |
| Frontend integration | Implemented |
| Command-center UI | Implemented |
| Actual GIC calculation | Not implemented |
| Transformer failure prediction | Not implemented |
| Hardware | Not part of project |
| Scientific simulation engine | Not currently implemented |
Possible future development areas include:
Replace the TAM regional proxy with appropriately validated Egyptian or multi-station magnetic observations.
Use higher-resolution regional or 3-D conductivity information.
If reliable utility data becomes available, extend the system toward:
Line resistance
Network topology
Transformer grounding
Transformer configuration
Network admittance
and then calculate actual GIC.
Support multiple scientifically justified geomagnetic scenarios and compare ranking stability.
Integrate authoritative utility data where legally and technically available.
These are future extensions rather than requirements for the current MVP.
The combined project can be organized approximately as:
Solar Guard/
│
├── Client/
│ ├── src/
│ ├── public/
│ ├── package.json
│ └── ...
│
├── Server/
│ ├── src/
│ │ ├── routes/
│ │ ├── services/
│ │ └── ...
│ │
│ ├── scripts/
│ ├── data/
│ ├── package.json
│ └── ...
│
├── README.md
└── .gitignore
The frontend and backend may also be maintained as separate repositories depending on deployment and team workflow.
The conductivity model:
MODEL-VER-5.mat
is approximately 239 MB.
GitHub's normal repository file-size limit makes committing it directly inappropriate.
Therefore:
data/MODEL-VER-5.mat
should remain ignored by Git.
Generated large artifacts should also be reviewed before committing.
Before pushing:
git status
git diff --statCheck that no unintended large files are staged.
The project is designed so that the scientific pipeline can be reproduced from:
Magnetic forcing data
+
Conductivity model
+
Infrastructure data
+
Source code
The generated products can then be regenerated through the project's existing scripts.
Representative pipeline scripts include:
node scripts/run_full_pipeline.js
node scripts/run_egypt_grid.js
node scripts/run_infrastructure_exposure.js
node scripts/run_mt_tests.js
node scripts/run_synthetic_test.js
node scripts/test_infrastructure_exposure.jsThe exact script list should follow the current backend repository.
Check:
Backend server running
Correct API URL
CORS configuration
Environment variables
Browser network tab
Then test:
GET /api/health
Check:
GET /api/geoelectric/egypt-grid
GET /api/geoelectric/infrastructure-exposure
Ensure the backend returned valid JSON and the frontend API URL is correct.
Check:
GET /api/geoelectric/infrastructure-exposure?assetType=line&limit=20
Check:
GET /api/space-weather/current
The interface should display an unavailable state rather than fabricate values.
Ensure:
data/MODEL-VER-5.mat
exists locally and matches the expected model version.
Solar Guard follows these principles:
Do not claim more than the data supports.
Prefer physically interpretable quantities such as:
E
Ex
Ey
V_L
over unexplained numerical risk scores.
Show why a result is uncertain.
The backend calculates.
The frontend visualizes.
Clearly identify data sources and limitations.
Do not invent:
failure probabilities
GIC currents
confidence percentages
electrical connectivity
Keep the data-processing pipeline deterministic and testable.
Solar Guard is an:
Open-data, location-specific space-weather infrastructure exposure assessment system.
Its fundamental transformation is:
Geomagnetic Disturbance
↓
Modeled Geoelectric Field
↓
Infrastructure Exposure
↓
Priority Ranking
↓
Decision Support
The central engineering quantity is:
V_L = ∫L E · dl
The central product question is:
Where could this space-weather event matter most, why, and how certain are we?
That is the role of Solar Guard.
Ahmed Sami Backend & Full-Stack Developer
Contributed to Solar Guard through backend development, scientific data processing, geoelectric-field modeling, infrastructure exposure analysis, and API integration.
Focused on building reliable software at the intersection of data, engineering, and space-weather science.