JuliaPhysics / JuliaPhysics/SolidStateDetectors.jl

Floating metal passives are modeled as dielectrics, not conductors

Open
#627 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Julia
Stars
178
Forks
59
Avg merge
1d 20h
Merged PRs (30d)
4

Description

Spun out of the PR #623 review (see [this thread](https://github.com/JuliaPhysics/SolidStateDetectors.jl/pull/623#discussion_r3837606124)); the PR documents the current behavior in `src/MaterialProperties/MaterialProperties.jl`, this issue tracks the underlying modeling limitation.

## Current behavior

Passive objects enter the field calculation only through their relative permittivity (and optional fixed charge density). Metal passives whose potential is *fixed* (grounded or biased holders, cups, shields modeled as contacts) are handled correctly. Metal passives that are electrically *floating* are effectively treated as dielectrics:

- Al: `ϵ_r = 10.8`, Cu: `ϵ_r = 20` — moderate values, substantial field penetration;
- Pb: `ϵ_r = 1e6` — an ad-hoc "large conductor-like" value that approximates screening numerically.

## Why that is not a conductor

An ideal floating conductor imposes two constraints that no finite `ϵ_r` reproduces:

1. the potential is **constant throughout the body** (the constant is an unknown of the problem, not an input);
2. the induced surface charge arranges itself so that the body's **total charge** matches its actual charge state (usually zero).

A high-`ϵ_r` dielectric only suppresses the internal field asymptotically, does not enforce exact equipotentiality, and always carries zero *net* induced charge locally rather than globally. Fields near floating metal structures — and anything derived from them (drift paths near holders, capacitance contributions) — are therefore approximations of uncontrolled quality, with Al/Cu defaults far from the conductor limit.

## Workarounds today

- If the part is effectively at a known potential: model it as a `Contact` with that potential (exact).
- If only screening matters: assign a large `ϵ_r` like the Pb entry (approximate; watch SOR convergence, since extreme permittivity contrasts slow it down).

## Possible proper implementation

Treat a floating conductor as a contact with an *unknown* potential and use linearity — no new solver needed:

1. Solve once with the floating electrode grounded; integrate the induced charge `q₀` on it (the induced-charge machinery from the capacitance calculation applies).
2. Solve the electrode's weighting potential; its self-capacitance `C` follows from the same integrals.
3. The floating potential is `φ_float = (Q_body − q₀)/C` (with `Q_body = 0` for a neutral part), and the physical field is the superposition of the two solutions.

For several floating bodies this generalizes to a small linear system in the mutual capacitance matrix of the floating electrodes. Validation candidate with an analytic reference: a floating spherical shell in the field of a point charge / between two held spheres (the two-spheres analytic testset provides most of the scaffolding).

## Suggested steps

1. Short-term: keep the documented note in `MaterialProperties.jl` (done in PR #623) and mention the limitation in the passives section of the docs.
2. Decide whether the Pb-style `1e6` value should be offered as an explicit opt-in (`metal: true`?) rather than a per-material accident.
3. Longer-term: implement the floating-contact boundary condition per the superposition scheme above.

Created by generative AI.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with src/MaterialProperties/MaterialProperties.jl and the passives documentation, then trace the induced-charge machinery used for capacitance calculations. Review the two-spheres analytic testset as the validation scaffold. Done means floating conductors enforce an unknown constant potential and the specified total charge, with the analytic reference validating the resulting fields.

Written by the indexing model from the issue text.

Assessment

Tech stack
julia
Domain
backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.