Classic common parameters and independent environments¶

Classic object detection uses ATSLegacy 2.7.0; classic classification uses ATSLegacy 2.5.0. These identify architecture/configuration versions, not modern architecture versions. The pages share some controls, but implement dataset preprocessing and parameter mapping separately.

Override priority¶

Load the selected model YAML and its base configurations, generate a separate experiment configuration, then apply explicit UI overrides. Built-in YAML files are not rewritten. Use configuration preserves the original setting, not a universal fixed default.

Epochs, batch size and random seed use the UI values directly, defaulting to 100, 4 and 42 respectively; other optimization settings default to the model configuration. Each experiment saves effective_det.yaml or effective_clas.yaml to verify actual sizes, data paths, classes, learning rate and loader settings.

Weight initialization¶

Option	Actual behavior
Use pretrained settings from the configuration	Uses the YAML setting; a URL may download weights or hit an existing cache. A cache is not guaranteed on every customer's computer.
Use local pretrained weights	Specify a compatible .pdparams for initialization in this run. This is not a resume-training switch.
Random initialization	Do not load the configuration's pretrained weights; start from random parameters. A valid model configuration is still required.

Offline, choose local weights or random initialization. The presence of an architecture folder alone does not mean pretrained weights are included.

Learning rate and optimizer¶

An initial-learning-rate UI value of 0 means Use configuration; it does not set the engine learning rate to 0. The weight-decay Use configuration placeholder likewise makes no override.

Keep the configured optimizer or explicitly select Momentum, SGD, Adam or AdamW. The application adapts parameter structures when switching; AdamW receives numeric weight decay rather than the previous optimizer's regularizer dictionary.

Learning-rate schedule	Behavior
Use configuration setting	Preserve milestones, total schedule length and warmup. Changing the training epoch count does not automatically rewrite the whole schedule.
Constant learning rate	Uses the initial learning rate of this run's configuration, without UI-configured warmup.
Cosine annealing	Rebuilds the schedule for this run's total epochs. Warmup epochs must be an integer smaller than the total.

Data augmentation and AMP¶

Keeping model augmentation preserves its original policy. Disabling random augmentation substitutes validation preprocessing for random training augmentation. Normalization, channel layout and required resizing remain.

AMP can follow the configuration, be disabled, or be enabled. Explicit enabling requires a GPU; CPU training disables AMP. Following the configuration does not guarantee AMP on a GPU: the model configuration still decides.

Windows workers and GPU selection¶

Native multiprocessing data loading is limited in the classic Windows runtime. With workers>0, this application uses threads inside the isolated process for parallel reading and preprocessing; 0 keeps the original loader. Start with 2 or 4; a larger value is not necessarily faster.

Each task uses one selected NVIDIA GPU; any installed card can be selected, but native Windows multi-GPU joint training of one classic model is not supported. The independent process normally reports GPU 0 because of visible-device mapping; this does not mean the physical card selection was ignored.

Each run creates an independent timestamped directory under the output root. Training and automatic export use the independent classic environment without changing modern or anomaly environments. See the parameter checklist for complete ranges.