Skip to main content
When a run produces unexpected results, the first question is always: what’s different? Atomscale provides two complementary approaches to answer this, depending on the level of detail you need.

Two Approaches to Diagnosis

Inspect a single run over time to see exactly what happened.The Monitor page replays a run with its growth metrics, tool state, and detected events on one synchronized timeline. It shows time-resolved detail on how the process evolved, which metrics shifted and when, and what the tool was doing at the moment of a change.Use this when you need to understand exactly when and how a run departs from expected behavior.What you see:
  • Growth metrics charts of derived RHEED metrics across the course of the run
  • Tool state instrument parameter logs, synchronized with the metrics so you can line up a change with the conditions that produced it
  • Activity timeline of detected events and changepoints, which you can filter, relabel, and annotate

Setting Up

1

Open the run on the Monitor page

Select the session from the Sessions sidebar on the Monitor page. An active run appears under Ongoing; a finished run appears under Completed.
2

Replay or follow the run

For a completed run, use the playback bar to replay it and adjust the speed. For an active run, the view follows the live edge as data streams in. See Session View.
3

Line up metrics with tool state

Watch the growth metrics and tool state together. Where a metric shifts, check the tool state at the same moment to see whether an instrument event coincides with it.
4

Work the activity timeline

Open the Activity tab in the Details sidebar to see detected changepoints. Filter by label or magnitude to find the moments where the run’s behavior changed.

What to Look For

Both approaches follow the same logic: identify where the run diverges, assess how much, and connect that to what it means for your outcome.

Identifying Divergence

In the Monitor session view, watch the growth metrics for the point where they depart from the run’s earlier behavior or from what a healthy run looks like. The synchronized tool state shows whether a specific instrument event coincides with the shift, and the activity timeline flags changepoints automatically so you can jump straight to them. In Explore Similarity, look at where the problem run sits relative to runs with known outcomes. A run that clusters with failures but used a “good” recipe suggests the issue is in execution, not design. A run between clusters may indicate a borderline process condition.

Assessing Significance

Not every difference matters. The Monitor session view shows the magnitude of a shift over time: a brief excursion that self-corrects is different from a sustained drift. Explore Similarity scores quantify how far a run sits from its nearest neighbors, which you can compare against the natural spread of your process. Cross-reference with anomaly detection results: if a run looks anomalous in similarity analysis and also triggered drift or point anomalies, that strengthens the case that the deviation is real.

Connecting to Outcomes

The diagnostic value comes from linking process divergence to outcome differences. When the Monitor session view shows a run shifting during a specific phase, check whether that phase historically correlates with the outcome property that degraded. When Explore Similarity shows a run clustering with failures, examine what those failures have in common. Runs that are “close” in embedding space tend to produce similar outcomes, making the distance itself a meaningful diagnostic signal.

Choosing the Right Approach

ScenarioApproachWhy
You need to know exactly when and how a single run changedMonitor session viewTime-resolved metrics, tool state, and changepoints on one synchronized timeline
You want to find what a problem run is most similar toExplore SimilaritySearches your full dataset without pre-selecting references
An active run looks like it’s driftingMonitor session viewFollows the live edge so you can decide whether to intervene before the run completes
Process transfer to a new toolExplore SimilarityShows how new-tool behavior compares to original-tool signatures across your history
Recurring intermittent failuresBothExplore Similarity identifies what failing runs share; the session view shows the full detail of each

Documenting Findings

When you identify the source of divergence, record it:
  • Tag the run with descriptive labels (e.g., “temperature-drift”, “flux-excursion”) so it’s findable in future similarity analyses.
  • Add notes in the session’s Metadata documenting which parameters diverged, your hypothesis, and any corrective action taken.
  • Build up labeled examples of good and bad runs over time so your similarity comparisons grow more informative as your dataset matures.

Next Steps

Identify Uniformity Issues

Diagnose consistency problems within a single run that similarity analysis alone may not surface.

Detect Anomalies

Set up automated detection to catch divergence patterns before they require manual diagnosis.