Crate pantometry_thermal 

pantometry-thermal: heat, as a domain built on the pantometry-core kernel.

Four domains, spanning three dimensionalities and one graph. The first two sit either side of the line that matters to a scheduler:

• LumpedMass has one temperature and no internal structure. Its stability limit is its own time constant, which is seconds for a piece of glass in still air — so it takes one step per frame and costs nothing.
• Bar1D resolves a gradient on a grid, and pays the explicit diffusion limit dt < dx²/2α for it. On a millimetre grid that is about a second in N-BK7 and seven milliseconds in aluminium, and that two-orders-of-magnitude gap between two parts of the same instrument is what Schedule::Multirate exists for.

The third answers a different question. Both of the above report one body:

• ThermalNetwork is n lumped bodies joined by conductances — winding, stator, housing — and it carries the drop across each joint, which is the number a designer actually needs and the one a single lumped mass cannot give: it reports the temperature of the skin and the winding together. It also expresses a contact resistance between different materials, which Bar1D’s uniform grid cannot. A network of one node reduces to a LumpedMass bit for bit, so it inherits every check that domain already passes.

And the fourth resolves what a bar cannot:

• Solid3D is conduction in three dimensions on a cubic grid, which is what a hot spot needs: heat spreading sideways out of a spot is the whole job of a spreader plate and a fin, and a one-dimensional model has nowhere for it to go but along. It pays dx²/6α, a third of Bar1D’s limit, because the explicit limit tightens with every axis.

Where the heat comes from

Neither domain generates any. They consume HEAT from the kernel’s Exchange, and the thing that publishes it is optics: SurfaceOptics::absorptance against a SpectralPower is a definite number of watts, and those watts have to go somewhere. That is the whole coupling, and it is auditable because it goes over the bus.

What is deliberately simple

Both domains are explicit and both are linear in temperature except for the radiative term. There is no implicit solver, no mesh, no natural convection model — a convective loss is a coefficient the caller supplies, because computing one honestly means solving a fluid problem and that is a different crate. The point here is a domain that couples correctly and reports its own stability limit, not a competitive thermal solver.

Re-exports

pub use network::Node;

pub use network::SteadyState;

pub use network::ThermalNetwork;

pub use solid::Face;

pub use solid::GapPatch;

pub use solid::Solid3D;

pub use solid::STABLE_FOURIER_3D;

Modules

network

A lumped thermal network: n nodes, conductances between them, one domain.

solid

Conduction through a block, in three dimensions.

Structs

Bar1D

One-dimensional explicit heat conduction on a uniform grid.

Environment

How a body loses heat to its surroundings.

LumpedMass

A body at one temperature.

Constants

HEAT

The bus channel heat arrives on, in joules.