Transfer Learning#

underPINN supports two transfer-learning modes, both using the same warm-start API: solver.load_params(...) or solver.restore_checkpoint(...).

Parameter transfer (different ν / Re / diffusivity)#

Warm-start from a trained model when changing a physics parameter — converges 2–3× faster than training from scratch.

# Phase 1: train source model (e.g. Burgers ν=0.1)
solver_src.train(*data_src, config=cfg_src)
solver_src.save_checkpoint("outputs/source/")

# Phase 2: warm-start target from source weights, then fine-tune (e.g. ν=0.01)
solver_tgt.load_params(solver_src.params)        # or restore_checkpoint("outputs/source/")
solver_tgt.train(*data_tgt, config=cfg_tgt)      # lower lr recommended (3e-4 instead of 1e-3)

Tip

Use a lower learning rate for the fine-tuning phase (e.g. 3e-4 instead of 1e-3) to avoid destroying the warm-started weights in the first few epochs.

Temporal transfer (extended time horizon)#

Extend the trained time horizon by fine-tuning on a new interval, starting from a previously trained checkpoint.

# Phase 1: train on t ∈ [0, T_1]
solver_phase1.train(*data_t1, config=cfg_phase1)

# Phase 2: extend to t ∈ [0, T_2], T_2 > T_1, warm-start from Phase 1
solver_phase2.load_params(solver_phase1.params)
solver_phase2.train(*data_t2, config=cfg_phase2)

Both modes are demonstrated in examples/transfer/burgers_transfer.py and examples/pipe_flow/pipe_flow_unsteady_transfer.py.

Time-marching transfer (windowed, long-horizon unsteady flows)#

For problems where the time horizon is too long to train in one shot — the 3-D pulsatile pipe flow case, for instance — underPINN splits the horizon into windows:

  • Each window warm-starts from the previous window’s trained weights

  • The previous window’s end-state is chained in as the next window’s initial condition

  • Per-window checkpoints are written, and restart is tracked at the window level (not just the epoch level) — see Restart / Resume System

python -m underPINN run examples/pipe_flow/pipe_flow_pulsatile_transfer.yaml

Why window instead of training end-to-end?

Directly training a PINN across a long unsteady horizon suffers from causality violation and vanishing-gradient-like effects as the temporal domain grows. Windowed time-marching keeps each sub-problem well-posed and numerically tractable while still producing one continuous solution across the full horizon.

See also

Training System for the general transfer/warm-start mechanics, and Model Checkpointing & Inference for the ModelPredictor API used to query trained windows.