At a glance

What this page covers

For
Power-electronics engineers defining labels, records, or datasets before training a model.
You will leave with
A four-part label contract that separates rule outcome, execution state, review requirement, and final disposition.
Evidence status
Published Field Note backed by a rebuildable simulation-only campaign at one frozen operating point.
Boundary
The campaign uses a simplified single-point equivalent model; it is not hardware approval, multi-point validation, or proof of solver equivalence.
Starting point, decision and reusable output
Decision
Decide whether a candidate record supports proceed, rework, review, or abstention without confusing software execution with electrical evidence.
Starting point
No machine-learning code is required; basic familiarity with LLC screening and engineering review is useful.
Reusable output
A 20-candidate Quickstart, a versioned 200-candidate evidence archive, and a replayable candidate record.
Next useful action

Run the beginner grouped-baseline lab, then compare its split and label contract with this LLC evidence loop.

Build the grouped baseline

A surrogate model does not learn engineering intent. It learns the relationships encoded in the records it receives. If pass sometimes means “the calculation ran”, sometimes “the analytical gate passed”, and sometimes “the design is acceptable”, adding more designs only scales the ambiguity. Before asking how much data a surrogate needs, the workflow must define exactly what each label means and preserve the evidence behind it.

This Field Note opens a series on building surrogate models for power-electronics design. Part one establishes that foundation by separating rule outcome, execution state, review requirement, and final disposition inside a replayable LLC workflow. A rule can pass or reject. An execution can complete or fail. A case can require review. A final decision can proceed, rework, abstain, or escalate.

To see why these distinctions matter, imagine reviewing 200 LLC candidates in a spreadsheet. For each one, you check required gain, input phase, solver completion, electrical limits, and the reason it did or did not advance. Now ask a coding assistant to automate that work. The calculations are not the hardest part. The hard part is preventing the software from calling a timeout a bad converter or writing PASS without saying what passed. This first step makes every later dataset decision interpretable: define the decision contract, run a small rebuildable demo, inspect every output, and keep the engineering meaning attached to each record.

With that foundation in place, the next Field Note will examine how far the design population must diversify before the records begin to support a useful surrogate, rather than merely describe one generator, one model, and one operating point.

Why “screen these designs” is not an engineering specification

An LLC screening request leaves critical decisions undefined:

  • Which topology, equations, and operating condition are in scope?
  • What does the first-harmonic approximation, or FHA, need to prove?
  • Which quantities are measurements, calculated values, or model proxies?
  • What happens when a numerical method does not finish?
  • Does an automatic pass mean “advance to the next check” or “approve hardware”?

A coding assistant can fill those gaps with reasonable-looking assumptions. That is exactly the risk. Hidden assumptions become repeated decisions as soon as the workflow scales.

For a future surrogate, those repeated decisions become the target it tries to learn. A model can score well against an internally consistent table while learning the wrong engineering distinction. The purpose of this first Field Note is therefore not to train the surrogate. It is to make the future training records mean one consistent thing.

Current baseline: staged engineering review before automation

The manual baseline is a staged review. Freeze the specification and candidate bounds, inspect the FHA gain and input phase, send only eligible candidates to the next method, and record electrical rejections separately from methods that did not complete.

The bounded decision is whether a generated candidate:

  1. is rejected at the FHA gate;
  2. advances to a time-stepped linear-equivalent evaluation;
  3. passes or fails the named automatic electrical checks;
  4. is withheld because execution failed.

Hardware approval is outside that decision.

How one ambiguous label can corrupt the evidence set

Suppose the simulation software reaches a timeout. The converter may be poor, the numerical setup may be difficult, the model may be incomplete, or the allowed run time may simply be too short. None of those possibilities is an electrical rejection.

If the workflow stores that case as reject, later analysis sees a false physical label. If the same records are used for machine learning, the model learns simulation behaviour as though it were converter behaviour. A larger dataset then reinforces the mistake: the surrogate becomes better at reproducing the workflow's labelling error, not at recognising an electrically unacceptable LLC design.

The opposite error is just as serious. If a candidate passes a simplified single-point model and the report shows only PASS, the reader may interpret a screening result as a validated design.

Separate rule outcome, execution state, review, and final disposition

The workflow uses four distinct questions:

  1. Did the method complete, and did it converge where required?
  2. Did the named rule pass or reject the available result?
  3. Does the case require engineering review?
  4. What final disposition is authorised: proceed, rework, abstain, or escalate?

Those answers are stored separately. A failed execution has no electrical rule outcome. A rule can pass while the case still requires review. Review does not overwrite the evidence already recorded, and the final disposition states only the next action authorised from that evidence.

LLC evidence workflow from specification to a bounded decision contract
Plot generated by the published notebook workflow. The diagram separates candidate generation, the FHA gate, the time-stepped linear-equivalent method, and the final decision contract.

This separation is the core design choice. It keeps the software useful without giving it authority the evidence has not earned.

Build the evidence loop before adding model complexity

1. Freeze the electrical scope

The archived campaign used one half-bridge LLC operating condition with a centre-tapped secondary:

QuantityFrozen value
Input voltage400 V
Output voltage36 V
Output power230 W
Operating conditionFixed input, full load
FHA frequency search50 to 180 kHz
Maximum FHA gain error1%
Minimum inductive input phase2°

The scope label Phase A means preliminary electrical screening at this one operating point. It is an internal label, not an industry-standard design phase.

Magnetic design, semiconductor losses, thermal behaviour, EMI, control robustness, tolerances, line and load sweeps, and hardware validation are excluded. Naming those exclusions prevents a successful run from implying that they were checked.

2. Generate candidates deterministically

The frozen campaign generated 200 candidates with a deterministic Latin-hypercube process and seed 20260820. It varied resonant frequency, inductance ratio, quality factor, and transformer turns ratio.

Determinism matters because a reviewer can regenerate the same population and compare its content hash. Without a frozen seed, bounds, definitions, and configuration, a repeated run may test a different problem.

3. Use FHA as a fast analytical gate

For each candidate, the FHA stage searched the allowed frequency range. A candidate advanced only when it could reach the required gain within 1% while retaining at least 2° of inductive input phase.

FHA answers a bounded screening question. It does not reproduce every switching, nonlinear, magnetic, parasitic, or control effect.

FHA pass example with required gain and phase-qualified operating point
Fresh 20-candidate notebook run, not the archived 200-candidate campaign. This example finds a phase-qualified operating point at approximately 114.75 kHz.
FHA reject example at the upper search boundary
Fresh 20-candidate notebook run, not the archived 200-candidate campaign. This example reaches the 180 kHz search boundary without satisfying the complete gain and phase contract.

The plots make the decision inspectable. A pass shows the selected point, required gain, gain response, and input phase. A reject shows why the allowed region did not contain an acceptable point.

4. Evaluate survivors with the primary time-stepped method

FHA survivors entered switched-linear-equivalent-v1, a time-stepped linear-equivalent model with explicit convergence and measurement windows. The archived campaign performed 168 of these evaluations.

The model adds time-domain evidence while remaining a simplified electrical representation. Its commutation-current signs are proxies inside that model, not proof of zero-voltage switching in a physical converter.

Time-domain traces for a pass case
Fresh 20-candidate notebook run, not the archived 200-candidate campaign. The retained traces show drive, resonant-capacitor voltage, parallel-branch voltage, resonant current, and magnetising current. The commutation indication is a model proxy only.

5. Write one record per candidate

Each record keeps the input specification and hash, candidate variables and units, methods, thresholds, convergence evidence, telemetry, decision reason, and provenance. Missing targets remain missing instead of receiving invented values.

The record also retains a human boundary: requires engineer review remains true and reviewed by remains empty until an authorised review occurs.

What the campaign can actually prove

The 200-candidate result

The verifier recovered all 200 records, checked the controlled status vocabulary, validated stored hashes, and reproduced the frozen candidate-set hash.

Gate outcomeCount
Generated200
FHA reject32
FHA pass168
Time-stepped linear-equivalent evaluations168
Evaluation executions completed168
Evaluation executions failed0
Automatic rule pass168
Automatic rule reject32
Cases requiring engineering review200
Engineer-authorised final dispositions0

All 32 analytical rejections used the archived reason FHA_GAIN_TARGET_NOT_REACHED. Their FHA rule outcome was reject, so they did not enter the more expensive primary method.

All 168 FHA survivors completed and converged in the time-stepped linear-equivalent method. Their named electrical rule outcome was pass at the frozen single point. It does not mean that 168 hardware designs were approved.

Five survivors selected the 180 kHz upper edge of the FHA search. The rebuildable schema marks that boundary condition so an edge optimum is not mistaken for a comfortably contained solution.

The current population also contains no FHA-versus-primary-method disagreement. That absence is not proof that the two methods are equivalent.

The notebook makes the small run visible

The downloadable notebook runs a new 20-candidate demonstration. It does not read the archived 200-candidate records.

Twenty generated LLC candidates in the Ln and Q design plane
Fresh 20-candidate notebook run. The plot shows the generated design space and distinguishes FHA pass and reject outcomes.
Gate counts for the fresh 20-candidate notebook run
Fresh 20-candidate notebook run: 17 candidates passed the FHA and final automatic gate, 3 were rejected at FHA, and 0 methods failed. These counts are separate from the archived 200-candidate campaign.

This small run is useful because the engineer can change the visible input values, run the workflow, and inspect the records and plots within one session. It demonstrates the bookkeeping and decision semantics without asking the reader to audit 200 cases first.

One recoverable candidate

Candidate llc-0186 was selected by the frozen ranking rule as the reusable record from the archived campaign.

Design variableValue
Resonant frequency72.999 kHz
Inductance ratio3.6118
Quality factor0.6576
Turns ratio, primary to secondary4.2289
Resonant inductance117.103 µH
Magnetising inductance422.951 µH
Resonant capacitance40.592 nF

The FHA gate selected 114.25 kHz. At that point, the gain error was 0.0127% and the calculated input phase was 42.68°, so the candidate advanced.

The time-stepped method converged after 90 cycles. Its eight-cycle, 1,280-sample measurement window produced:

TelemetryValue
Output voltage35.9767 V
Output power229.702 W
Equivalent-model power ratio95.3188%
Switching frequency114.25 kHz
Resonant-current peak2.347 A
Resonant-current RMS1.755 A
Magnetising-current peak0.669 A
Resonant-capacitor peak voltage86.268 V

Its automatic rule outcome is pass. The case still requires engineering review, and no engineer-authorised final disposition is recorded. The result belongs to the frozen model, condition, and thresholds.

Replaying one candidate record

The campaign replayed llc-0186 in a separate evidence directory using the same configuration and method. The retained 1,280-sample waveform and every decision-relevant telemetry value matched the original record on the archived environment. The observed numerical delta was 0.0 for each compared metric.

Exact hashes establish archived integrity. Named numerical tolerances support cross-environment reproduction. Replay proves that the result can be reconstructed, not that the model is physically complete.

The simulation software timeout that must not become an electrical reject

A separate simulation software preflight exceeded its configured 180-second timeout and did not produce the required measurements.

Its execution status is failed, with reason SOLVER_TIMEOUT.

It is not reject.

The failed method produced no decision-safe electrical conclusion. It was archived outside the completed 200-candidate primary-method population and did not contaminate those labels.

The public archive retains a sanitized failure record and note.

This failure also blocks a stronger claim: the campaign has not established equivalence between the linear-equivalent primary method and a higher-fidelity closed-loop implementation.

Why these 200 records are not yet a trustworthy training dataset

All final decisions come from one fixed input and full-load condition. The evidence does not cover line, load, temperature, tolerances, magnetics, semiconductor stress, cross-solver validation, hardware correlation, or held-out design-level model evaluation.

The 168 passes are also one-sided after the FHA gate. A surrogate trained on these records could learn the boundaries of this generator and model while appearing more general than it is.

The next dataset should add controlled diversity and stronger cross-method evidence, not merely more rows.

This is where the next Field Note begins. It will ask how far that diversity must expand before an unseen-design evaluation becomes meaningful, and how to tell whether new candidates add coverage or only add density inside the same narrow region.

Run the files in the route that fits you

Start with the 20-candidate Quickstart ↗. The 200-candidate evidence archive ↗ is for deeper audit.

Route A: Windows, no programming setup

  1. Download the Quickstart ZIP and extract it.
  2. Open the extracted folder.
  3. Double-click run_demo.bat.
  4. Wait for the run to finish.
  5. Open the new LLC_Demo_Runs folder beside the extracted package.
  6. Open summary.html in your browser.
  7. Confirm that the report says OUTPUT INTEGRITY: PASS.
  8. Review the separate FHA execution, FHA gate, time-domain execution, final automatic disposition, warnings, and engineering-approval status.

OUTPUT INTEGRITY: PASS means that the expected files and consistency checks passed. It does not approve any candidate for hardware.

Route B: PowerShell

Open PowerShell in the extracted Quickstart folder and run:

py -B run_demo.py

To change the visible electrical specification and candidate count:

py -B run_demo.py --vin 400 --vout 36 --pout 230 --candidates 20

The output appears in LLC_Demo_Runs beside the package. Each run receives its own folder so the generated evidence does not overwrite the source package.

Route C: Jupyter or Colab

For a local notebook, open notebooks/llc_quick_demo.ipynb. For a browser-only route, open the Colab notebook ↗.

  1. Find the marked parameter cell.
  2. Edit Vin, Vout, Pout, or candidate count.
  3. Choose Run all.
  4. Read the gate-count and design-space plots first.
  5. Inspect the pass and reject FHA cases.
  6. Review the retained time-domain traces and the status definitions.
  7. Download the generated files if you want to compare or audit the run later.

What each output is for

OutputWhat to inspect
summary.htmlHuman-readable result, warnings, plots, and separated status fields
candidate_records.csvOne tabular row per candidate for quick filtering
candidate_records.jsonlComplete machine-readable records, one JSON object per line
manifest.jsonRun identity, files, and content hashes
verification.jsonMachine-readable integrity result and checks
pedagogical_cases.jsonSelected pass, reject, and failure examples for review
plots/Workflow, design space, gate counts, FHA cases, and retained traces
ml_dataset_v1.csvBounded export for later data work, not a qualified training set
feature_dictionary.jsonFeature names, units, and meanings
target_dictionary.jsonTarget definitions and missing-value semantics
split_manifest.jsonDesign-level grouping contract for future model evaluation
dataset_card.mdScope, provenance, exclusions, and safe-use notes

Replay and verify

From the Quickstart or Evidence Archive root:

py -B -m llc_tool replay
py -B -m unittest discover -s tests -p "test_*.py" -v
py -B VERIFY_RELEASE.py

Replay reconstructs the named record under the published contract. The tests check implementation behaviour. The release verifier checks package integrity and evidence relationships. None of these commands is a substitute for higher-fidelity simulation or hardware review.

The defensible conclusion is deliberately narrow:

  • Result: the frozen loop completed with 32 FHA rejections and 168 single-point linear-equivalent passes.
  • Artifact: llc-0186 can be reconstructed and replayed with traceable evidence.
  • Failure: the simulation software timeout remained a method failure and was never relabelled as an electrical rejection.

Use the Quickstart to inspect that distinction yourself. Then subscribe to Field Notes for the next step: measuring how much design diversity is needed before an unseen-design evaluation becomes meaningful.