Melt Curves → Tm

1. 01Melt curves read straight from an RDML instrument export, or pasted as a temperature column plus one column per reaction
2. 02Three normalisation methods — exponential base-trend correction, a bilinear baseline scan that searches for its own low and high windows per target, and the two combined — with the windows the scan settled on reported rather than assumed
3. 03Friedman’s super smoother over the raw curve and over the first derivative, so a peak is called on a smoothed −dF/dT rather than on instrument noise
4. 04Peak calling with a width measured between the flanking second-derivative extrema, plus the peak height above its own shoulder, its fluorescence drop, and each peak’s share of the reaction
5. 05The product peak identified by the target’s expected melting temperature, and every remaining peak grouped into artifact columns shared across the plate
6. 06Per-well verdicts that name the problem — a product with the wrong melting temperature, several products, or a product detected in a negative control — decided by the sample type the file carries
7. 07Every stage of the pipeline drawable and downloadable: raw, smoothed, normalised, first derivative and second derivative
8. 08The measured Tm shown beside the Tm predicted from the amplicon’s own sequence, when the file carries one, as two different questions rather than one number

A faithful port of the melt-curve analysis in RDML-Python, the RDML consortium’s own reference implementation, together with the Friedman super smoother and the NaN-aware regression it stands on. Validated against the real Python over upstream’s entire melt-curve test corpus — both plates, all three normalisation methods, both fluorescence sources and a non-zero peak cutoff: 634 reactions and 95,234 temperature points asserted on four pipeline matrices, plus the peak, product-choice and artifact-ordering table. The panel runs on @ports/discover, @ports/eds, @ports/melt, @ports/qpcr, @ports/rdml, @ports/workflow.

Everything runs client-side. Files are parsed in the browser and projects are saved on this machine, so an unpublished sequence is never uploaded.

What does it need from me?

The temperature ramp and one fluorescence column per reaction — what every instrument exports. An RDML file additionally carries the sample types and the target’s expected melting temperature, which is what lets the tool call one peak the product and flag a negative control that amplified.

Why is every peak reported as an artifact?

Because no expected melting temperature is known yet. Enter the product’s Tm, or import a run that states one, and the matching peak is called the product while the rest stay artifacts. The tool does not guess which peak you meant.

Which normalisation should I use?

Exponential is the default and is what most runs want. The bilinear scan is worth it when the fluorescence loss is not exponential across the ramp; it searches for its own baseline windows per target and tells you which ones it chose.

Does it recompute the melting temperature my instrument reported?

It computes its own from the raw fluorescence. The instrument’s own value is imported and shown separately, as the instrument’s, so the two can disagree visibly instead of one quietly replacing the other.

Is the predicted Tm the same as the measured one?

No, and they are labelled apart. The prediction comes from the amplicon’s sequence through a Poland–Scheraga model at a stated monovalent salt, which is not your reaction buffer; a degree or two of disagreement with a real melt is expected and informative.