GSoC 2026: Reduced order modelling with neural operators - Suyash Patil

## About Me

- **Name:** Suyash Patil
- **University:** IIIT Gwalior, Pre-final year B.Tech CSE
- **GitHub:** [github.com/Sypher845]
- **Email:** [suyashpatil845@gmail.com]

I'm a third year CS student at IIIT Gwalior. Right now I'm an LFX Mentee at CNCF Harbor, writing production Golang code for the Harbor-CLI project. I've done a numerical methods course, gone through the Gridap.jl tutorials, and read through the NeuralOperators.jl and GridapROMs.jl docs before writing this.

## The Problem

Solving PDEs with FEM gets expensive fast, especially when you need to solve the same problem hundreds of times with different parameters, like in optimization or real-time applications.

GridapROMs.jl already handles this with linear ROMs (POD, RB methods). These work well for simple problems but struggle when the solution changes in a complex, nonlinear way with the parameters, they need a very large
basis to stay accurate, which kills the speed benefit.

Neural operators are a better fit here. Instead of building a linear subspace, they directly learn the mapping from parameters to solutions. The idea is to build a framework that connects Gridap's FEM solver to NeuralOperators.jl so the trained model can act as a fast surrogate.

## Approach

### The main challenge

Gridap stores solutions as `CellField` objects on meshes that can be unstructured. FNO (one of the main neural operator architectures) works with FFT, so it needs data on a regular grid. These two don't match directly, that's the main thing to solve.

The plan is to handle both cases:

- **Regular/structured meshes → FNO.** Pull DOF values out of the `CellField`, reshape into the tensor format FNO expects, train, and map predictions back to a `CellField`.

- **Unstructured meshes → DeepONet.** The branch net takes the PDE parameter, the trunk net takes the spatial coordinates from the mesh directly. This fits naturally with how Gridap stores mesh coordinates.

Either way, the output is always a `CellField`, so it works with the rest of Gridap's tools without any extra steps.

### Data generation
```julia
sampler = ParameterSampler(μ_range, n_samples)
snapshots = generate_snapshots(fe_problem, sampler)
```

The user just passes in their Gridap problem. The framework runs the FEM solver across the parameter range and collects the snapshots. Nothing Gridap-specific leaks out.

### Training
```julia
dataset = GridapOperatorDataset(snapshots, architecture=:FNO)
model = FourierNeuralOperator(chs=(1,64,64,1), modes=(16,16), σ=gelu)
# train with standard Lux.jl + Optimisers.jl
```
---
*AI assistance was used for drafting and structuring this issue.*

`GridapOperatorDataset` handles converting `CellField` data into whatever format the chosen architecture needs normalization, train/test split, the works.

### Using the surrogate
```julia
u_ROM = evaluate_surrogate(trained_model, μ_new, triangulation)
# returns a CellField
```

Since it returns a `CellField`, you can plug it straight into Gridap's postprocessing and visualization pipeline.

### Testing it

I'll validate on two problems:

- **Darcy flow**: structured mesh, well studied in the FNO paper so
there are published numbers to compare against.
- **Parametric heat equation** : unsteady, tests the DeepONet path.

Main metrics: L² error vs the full FEM solve, and how much faster the surrogate is.

---
*AI assistance was used for drafting and structuring this issue.*