The flow model, and where it is valid
The pressure/flow relationship is the rectangular-duct Hagen–Poiseuille
approximation given in the h.r.3.3 PDK's own component documentation for this
part (pdk/docs/Rectangular Channel.docx, “Component
model”), which in turn cites Bruus:
R_hyd = 12 · η · l / ( w · h³ · (1 − 0.63 · h / w) ) Q = ΔP / R_hyd
Validity condition: h ≤ w. The series approximation the
0.63 term comes from is written for a duct whose height is the shorter side. If
you enter a channel taller than it is wide the tool still reports a number, but it
computes it on the same duct with the two cross-section dimensions exchanged and
says so in the readout — and that geometry separately fails the PDK's
documented h < w rule.
Where the ends are tapered, each taper is counted slice by slice with the same formula. With roof ports, each port's hole through the roof is counted too, as a duct of the port's shape: a round port as a round tube of the same area, R = 8 · η · L / (π · r⁴), and a square port by the exact series for a square duct, R = 12 · η · L / (0.4217 · a⁴). That part is approximate: the holes are short, and entrance effects are not modelled. Where the ports carry slip-on posts, each post's bore is counted as a round tube as well.
Everything the calculator prints is a laminar estimate for a straight channel, not a guarantee. It assumes fully developed, steady, incompressible, single-phase Newtonian flow, rigid walls, no entrance or exit losses, no surface-tension effects, and perfectly rectangular cross-section. A real printed channel has none of those exactly. Reynolds number is reported so you can see when the laminar assumption itself is in question; water density is taken as 998.2 kg/m³ at 20 °C.
What is checked, and what is not
The blocking checks are geometric self-consistency only — whether the solid
you described can exist as a printable body. The single process rule that is
checked, h < w, is checked because it is written down in the PDK
component document for the rectangular channel. It is the only one.
On the BYU grid, the block is also compared with the image BYU publishes for the OS1, 2560 × 1600 pixels (19.5 × 12.2 mm, BYU’s rounded figure; the OS1’s Specs page, read 2026-09-30), either way round. The comparison is in pixels: on this grid a pixel of the block is a pixel of the image, so 2560 pixels fit and 2561 do not, whatever a pixel’s exact size. A block bigger than that both ways is flagged and never refused: the files stay on. Each figure is BYU’s published figure for the OS1: see Hardware and process. On any other grid no build area is compared.
There are obvious further questions — the smallest channel this printer can actually resolve, whether a one-pixel wall survives handling, whether uncured resin will drain from a long enclosed channel. This tool does not answer them and does not guess. The OpenMFDA design kit's documentation gives no limit for any of them, so inventing a threshold here would be worse than leaving it visibly unchecked. Those items are listed in the Checks panel as not checked.
Nothing produced by this page has been printed or fluidically tested. It is geometry and arithmetic.
Grid discipline
Every dimension is stored as a whole number of pixels or layers, because that is what the printer can actually address. The µm boxes are a convenience: type 250 µm at a 7.6 µm pitch and the tool takes 33 px (250.8 µm) and tells you it did. Two consequences worth knowing: a port whose width has the opposite parity to the channel's sits half a pixel off centre, and the tool moves it to the nearest whole pixel rather than emitting an off-grid coordinate; and the block's outer height is always floor + channel + roof, so it cannot disagree with its own contents.