ModelZoo · Understanding the Output
What a Run Produces
Every run writes one folder. Example: DC arc fault (config_dsk.yaml), CLS_1k_NPU, F28P55
data/projects/<dataset_name>/run/<date-time>/<model_name>/
├── run.yaml, run.json # fully resolved parameters of this run
├── status.yaml, status.json # paths and status of every stage
├── training/
│ ├── base/ # FLOAT model
│ │ ├── model.onnx, checkpoint.pth
│ │ ├── run.log # training log of the whole run
│ │ ├── golden_vectors/ # test_vector.c, user_input_config.h
│ │ ├── model_aux.h # class index → class name
│ │ ├── pca_on_feature_extracted_{train,validation}_data.png
│ │ ├── file_level_classification_summary.log
│ │ ├── memory_preflight/ # early memory estimate
│ │ └── <date-time>_<model_name>.zip
│ └── quantization/ # QUANTIZED model (the one you deploy)
│ ├── model.onnx, checkpoint.pth
│ ├── golden_vectors/, model_aux.h, memory_preflight/
│ └── post_training_analysis/ # ROC, histograms, CSVs
└── compilation/ # DEVICE library
├── artifacts/mod.a, artifacts/tvmgen_default.h
├── run.log # compiler log + memory usage
└── <date-time>_<model_name>_<device>.zip
training/base · float model
Floating-point model, the full training log, PCA plots of your features, and a per-file classification summary.
training/quantization · quantized model
Integer model that is packaged and compiled for the device, with its own golden vectors and the post-training analysis plots.
compilation · device library
The compiled model library mod.a and its API header tvmgen_default.h, plus one .zip with everything a device project needs.
The tree differs a little by task: PCA plots and the file-level summary are for classification; the analysis plots depend on the task.
ModelZoo · Understanding the Output
Float vs. Quantized Model
Training produces two models: a float model first, then a quantized model derived from it. Each gets its own folder
| File | training/base/ · float | training/quantization/ · quantized |
|---|
model.onnx | Float32 ONNX model (7 KB here) | Quantized ONNX model (13.7 KB here). This is the model that gets compiled |
checkpoint.pth | PyTorch weights of the float model | PyTorch weights of the quantized model |
golden_vectors/ | Expected outputs as float | Expected outputs as int8_t; config adds SKIP_NORMALIZE, OUTPUT_INT |
model_aux.h | Number of classes and class-index-to-name table, e.g. {"class_0_normal", "class_1_arc"} |
memory_preflight/ | An early compile of the model to estimate its memory use on the target before the full run |
run.log | Log of the whole training: float, quantized and test evaluation | — |
PCA plots, file_level_classification_summary.log | Feature PCA (train, validation) and per-file predictions for float, quantized and test data | — |
post_training_analysis/ | — | Plots and CSVs of the quantized model on the test set |
<date-time>_<model>.zip | Packages the quantized model, golden vectors, analysis, model_aux.h and the log | — |
Which one do I use? Deploy the quantized model. Compare its accuracy with the float model in run.log: a large drop means quantization is hurting the model.
ModelZoo · Understanding the Output
Golden Vectors: user_input_config.h
Feature extraction settings for the device, generated from your config so the device reproduces the training-time preprocessing
// training/quantization/golden_vectors/user_input_config.h
#define SKIP_NORMALIZE // added by compilation
#define OUTPUT_INT // added by compilation
#define FE_WIN
#define FE_FFT
#define FE_NORMALIZE
#define FE_BIN
#define FE_LOG
#define FE_CONCAT
#define FE_VARIABLES 1
#define FE_FRAME_SIZE 1024
#define FE_HL 1
#define FE_FEATURE_SIZE_PER_FRAME 256
#define FE_STACKING_CHANNELS 1
#define FE_STACKING_FRAME_WIDTH 256
#define FE_NN_OUT_SIZE 2
#define FE_OFFSET 0
#define FE_SCALE None
#define FE_FFT_STAGES 10
#define FE_MIN_FFT_BIN 1
#define FE_FFT_BIN_SIZE 2
#define FE_BIN_NORMALIZE 0
#define FE_LOG_MUL 10
#define FE_LOG_BASE 2.71828183
#define FE_LOG_TOL 1e-12
#define FE_NUM_FRAME_CONCAT 1
Which steps run
FE_WIN, FE_FFT, FE_BIN, FE_LOG, FE_CONCAT, ... turn each feature extraction step on. They mirror the transform list of your feature extraction preset.
Sizes and parameters
Frame size 1024 (FE_FFT_STAGES 10 = 210), 256 features per frame, 1 frame, 1 variable, 2 model outputs (FE_NN_OUT_SIZE), and the binning and log parameters.
Quantized vs. float version
The only difference is the two lines the compile step adds: SKIP_NORMALIZE (the device feature-extraction library normalizes and quantizes the features to int8_t itself, using the bias/scale/shift in tvmgen_default.h; the compiled model skips its own input normalization) and OUTPUT_INT (integer outputs).
The content depends on the task. A regression run with a simple window only defines the sizes (FE_FRAME_SIZE 10, FE_NN_OUT_SIZE 1, ...).
ModelZoo · Understanding the Output
Golden Vectors: test_vector.c
Real samples with the expected result at each stage, to check your device implementation against the PC
// 1. Please uncomment one (and only one) of the below sets at a time.
// SET 0
//Class: class_0_normal (Index: 472): ADC Data
float raw_input_test[1024] = { 2106.0, 2082.0, 1946.0, ... };
//Class: class_0_normal (Index: 472): Extracted Features
float model_test_input[256] = { 62.40304, -17.06461, ... };
//Class: class_0_normal (Index: 472): Expected Model Output
int8_t golden_output[2] = { 61, -73, };
/*
// SET 1 class_0_normal (Index: 295)
// SET 2 class_1_arc (Index: 2982)
// SET 3 class_1_arc (Index: 1051)
*/
// model_aux.h
const NUMBER_OF_CLASSES = 2;
const char *classIdToName[NUMBER_OF_CLASSES] = {"class_0_normal", "class_1_arc"};
What a set contains
raw_input_test: one window of raw sensor (ADC) data.
model_test_input: the features extracted from it on the PC.
golden_output: what the model should output for it (int8_t for the quantized model, float for the float model).
Sets are picked from the training data and cover every class (here 2 per class).
How to use it on the device
1. Leave exactly one set uncommented (SET 0 by default).
2. Run feature extraction on raw_input_test and compare with model_test_input.
3. Run the model and compare with golden_output. Use classIdToName to print the class.
ModelZoo · Understanding the Output
PCA Graphs: Are Your Features Separable?
training/base/pca_on_feature_extracted_train_data.png and ..._validation_data.png (classification tasks)
What it shows
Every training sample after feature extraction, projected onto its 3 principal components and coloured by class. It is computed before the model is trained.
Well-separated clusters
Like here: the features already tell the classes apart, so even a small model can learn them.
Heavily overlapping clusters
The features may not separate the classes. Try another feature extraction preset or frame size before reaching for a larger model.
Only 3 components are shown, so some overlap can still be separable in the full feature space. Treat it as a quick sanity check.
ModelZoo · Understanding the Output
Post-Training Analysis: Classification
training/quantization/post_training_analysis/: the quantized model on the test set
One_vs_Rest_MultiClass_ROC_test.png
One ROC curve per class, with its AUC. Curves hugging the top-left corner (AUC near 1.0) mean the model ranks that class well. Marked points show example thresholds.
Histogram_Class_Score_differences_test.png
For each pair of classes, the difference between their output scores. Two groups far from 0 mean confident decisions; values near 0 are samples the model is unsure about.
fpr_tpr_thresholds.csv
,fpr,tpr,thresholds
0,0.0,0.0,inf
1,0.0,0.0041,92.0
2,0.0,0.0061,91.0
3,0.0,0.0143,90.0
...
The numbers behind the ROC curve: false positive rate and true positive rate at each threshold on the model output.
Use it to pick a decision threshold with the false-alarm rate your application can accept.
The per-file table in training/base/file_level_classification_summary.log shows which recordings are misclassified.
ModelZoo · Understanding the Output
Post-Training Analysis: Other Tasks
Each task type writes the plots that suit it. Examples from the generic regression and anomaly detection runs
Regression
actual_vs_predicted_test.png (with R²), residual_error_test.png, results_on_test_set.csv. Points on the red line are perfect predictions.
Anomaly detection
reconstruction_error.png (+ _log_scale): errors of normal vs. anomaly samples and the chosen threshold. threshold_performance.csv lists accuracy, precision, recall, F1 and false positive rate for each threshold k.
Forecasting
Prediction plots and CSVs per target variable, in three places:
training/base/
best_epoch_<N>_results/
training/quantization/
best_epoch_<N>_results/
test_results/
prediction_plots/*.png
predictions_csv/*.csv
One scatter plot per forecast step (1-step ahead, 2-step ahead, ...), each with R² and SMAPE.
Always compare the quantized test_results with the float best epoch.
ModelZoo · Understanding the Output
Compilation Output: What Goes on the Device
compilation/: the quantized model compiled by TI's Neural Network Compiler for the target_device
artifacts/tvmgen_default.h (excerpt): the API of the model library
/* Symbol defined when running model on TI NPU hardware accelerator */
#define TVMGEN_DEFAULT_TI_NPU
/* Input feature normalization parameters */
extern const float tvmgen_default_bias_data[] = {20.517256};
extern const float tvmgen_default_scale_data[] = {2931.};
extern const int32_t tvmgen_default_shift_data[] = {11};
/* TI NPU hardware accelerator initialization */
extern void TI_NPU_init();
extern volatile int32_t tvmgen_default_finished;
struct tvmgen_default_inputs { void* onnx__Add_0; };
struct tvmgen_default_outputs { void* output; };
int32_t tvmgen_default_run(struct tvmgen_default_inputs* inputs,
struct tvmgen_default_outputs* outputs);
artifacts/mod.a: the compiled model library. Link it into your project.artifacts/tvmgen_default.h: call tvmgen_default_run(). On NPU devices, initialize the NPU first (SysConfig in the C2000 examples; F29H85 examples call TI_NPU_init()), then wait for tvmgen_default_finished.<date-time>_<model>_<device>.zip: the hand-off bundle: artifacts/, golden_vectors/, post_training_analysis/, model_aux.h.run.log: compiler log. Look for TI Model Library Memory Usage (mod.a): code, RO data, RW data and total size on the device.*.bin_sub*: intermediate files the compiler can leave next to the artifacts (seen on NPU targets). They are not part of the bundle; you do not need them.
Next step: copy the bundle into your device project, then use test_vector.c to confirm the device matches the PC results (see Deploying to an SDK Example).
Adithya Thonse · October 2026
