Add planar/FinFET/nanoribbon device geometry support

[reneotten]

Summary

Builds on #2 (not yet merged, hence that branch as the base here).

The natural-length electrostatics already had a geo (number-of-gates) factor — exactly how compact 1D models distinguish planar, multi-gate, and gate-all-around architectures (lambda ~ 1/sqrt(geo)) — but it was an undocumented, unvalidated raw float with no way to construct a realistic device of a given architecture.

• Added GateGeometry (SingleGate/DoubleGate/TriGate/GateAllAround) and DeviceParams::{planar, fin_fet, nanoribbon} presets with realistic body/oxide dimensions per architecture. Mirrored as negforge.Device.planar()/fin_fet()/nanoribbon() in Python.
• Validation fix: Device::new now rejects non-positive/non-finite geo, d_ch, d_ox, k_si, k_ox, a, l_ch, l_ds instead of silently producing an infinite/NaN natural length that propagates garbage through the rest of the solve — a real risk now that geo is something callers set explicitly. Added a fallible Device::try_new; the PyO3 constructor uses it and now raises a proper Python ValueError (catchable by except Exception) instead of an uncaught-by-normal-exception-handling Rust panic.
• Verified the physics, not just "doesn't crash": crates/negforge-core/tests/multigate_geometry.rs + examples/geometry_comparison.rs confirm natural-length ordering, all three architectures converging (decoupled and self-consistent), and the textbook multi-gate result — at l_ch=10nm, planar shows real short-channel-effect degradation (147 mV/decade subthreshold swing) while FinFET (86) and especially gate-all-around nanoribbon (64, close to the 59.6 mV/decade ideal limit) don't.
• Notebook gets a new section plotting potential profiles and subthreshold swing across all three architectures.
• README gets a new "Planar, FinFET and nanoribbon devices" section, plus an honest "Extending to a real 3D solver" section: the optional 3D extension was not implemented. A genuine cross-section-resolved model (mode-space NEGF, the standard approach real nanoscale-FET simulators use) is weeks-to-months of separate numerical-methods and validation work — a different piece of software, not an incremental change — and is scoped out there rather than attempted as a shallow, hard-to-trust addition. Happy to scope that as its own effort if wanted.

Test plan

• cargo test --workspace — 27 tests pass, including 6 new geometry tests and 2 new validation-panic tests
• cargo clippy --workspace --all-targets — clean
• cargo run --release --example geometry_comparison -p negforge-core — reproduces the numbers quoted in the README
• maturin develop --release rebuilds; verified the presets match Rust exactly, and invalid geometry raises ValueError (catchable by both except ValueError and except Exception)
• notebooks/negforge_demo.ipynb re-executed end-to-end with the new section, no errors

---

Generated by Claude Code

[Copilot]

Pull request overview

Adds explicit planar/FinFET/nanoribbon “multigate geometry” support to the 1D device model by formalizing the gate-count (geo) concept, providing architecture presets, and tightening parameter validation (including Python error mapping) to prevent NaN/∞ electrostatics from silently propagating.

Changes:

• Introduces GateGeometry and DeviceParams::{planar, fin_fet, nanoribbon} (plus a Rust example + tests) to model planar vs multi-gate architectures via geo.
• Makes device construction validation-fail early via Device::try_new and maps invalid-parameter errors to Python ValueError in the PyO3 binding.
• Updates README and the demo notebook with architecture comparisons and documented limitations of the 1D model.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
README.md	Documents gate-geometry presets and adds an architecture comparison + 3D-solver scope notes.
python/negforge/init.py	Adds Python Device.planar/fin_fet/nanoribbon convenience constructors.
notebooks/negforge_demo.ipynb	Adds a section plotting potential profiles and subthreshold swing across architectures.
crates/negforge-py/src/lib.rs	Switches PyO3 constructor to fallible try_new and maps invalid params to ValueError.
crates/negforge-core/tests/multigate_geometry.rs	Adds physics/robustness tests for the new presets and expected trends.
crates/negforge-core/src/lib.rs	Re-exports GateGeometry from the core crate.
crates/negforge-core/src/device.rs	Adds GateGeometry, architecture presets, and parameter validation + try_new.
crates/negforge-core/examples/geometry_comparison.rs	Adds a runnable example that prints the architecture comparison used in docs.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[reneotten]

Confirmed — cls(geo=1.0, **{"geo": 2.0}) is a TypeError at call time, so Device.planar(geo=2.0) cannot work while fin_fet(geo=3.0) and nanoribbon(geo=...) can. The docstring on fin_fet even advertises overriding geo ("Pass geo=3.0 to also gate the fin top"), which makes the inconsistency more surprising rather than less.

The fix is to make planar match its siblings:

params = {"geo": 1.0}
params.update(overrides)
return cls(**params)

Not changing it here — this is #3's branch and I'm working on #5 — flagging it as confirmed for whoever picks this up.

---

Generated by Claude Code

[reneotten]

Confirmed, and the d_e case is worse than "unbounded loop" suggests — it's a hang, not an error.

calc_current computes ((e_max - psi_0) / d_e).floor().max(0.0) as usize and then iterates 0..=n_steps. Rust's float-to-int casts saturate, so d_e = 0.0 gives inf as usize == usize::MAX and the loop runs ~1.8e19 iterations with no allocation and no panic to stop it. epsilon = 0.0 reaches the same place by a different route: epsilon.ln() is -inf, so e_max is +inf. The same pattern appears in negf_current and in the self-consistent loop's energy grid.

t <= 0 is less dramatic but still wrong: it divides by zero in the Fermi functions, giving f = 0 everywhere and a silent zero current rather than an error.

So the three additions to validate_params are worth having, with epsilon needing 0 < epsilon < 1 specifically (it is a Fermi-function tolerance, and ln of anything >= 1 puts e_max at or below e_fs, collapsing the integration window). m_eff is the fourth of its kind — it divides into t_hop.

Not changing it here (this is #3's branch), but noting for sequencing: #5 will be rebased on top of this branch, so validate_params is where its grid-size and cross-section checks will land too.

---

Generated by Claude Code