executing-plans
executing-plans
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
training-evaluationGuides safe MapTR training and chamfer-evaluation command construction, preflight validation, checkpoint handling, reproducibility, and resource-aware recovery.
Independent GitHub snapshot · Automated classification · Original documentation governs
Use this sub-skill to construct and review commands for MapTR training or vector-map evaluation. It is deliberately conservative: prove inputs and backend readiness before starting GPU work, prefer dry runs, and never infer that a documented command succeeded on the current system.
This guidance covers the MapTR main behavior represented by commit
a6872d8d9670bde17b4b01560f1221f88b443d55:
chamfer metric;The project documents Python 3.8, PyTorch 1.9.1 with CUDA 11.1,
mmcv-full==1.4.0, mmdet==2.14.0, mmsegmentation==0.14.1, the bundled
mmdetection3d 0.17.2 code, and a compiled GeometryKernelAttention extension.
Those are documented compatibility targets, not proof that a current host
can import the plugin or run its CUDA kernels. Full data, checkpoints,
training, evaluation, and the custom extension were not executed while this
skill was produced.
data-preparation.model-configuration.visualization-benchmarking.Before constructing a launch, obtain all of these values. Keep an unknown as a stop condition rather than filling it with a guess.
--cfg-options overrides.mmcv-full ops, and
GeometryKernelAttention import/build evidence.--work-dir, checkpoint retention plan, and evaluation
result location.Read workflows.md for complete gates, commands, and expected observations. Read cli-reference.md before adding flags or overrides.
From the MapTR project root, run only parser/config checks first:
python tools/train.py --help
python tools/test.py --help
python tools/misc/print_config.py projects/configs/maptr/maptr_tiny_r50_24e.py
The config print should show plugin=True, MapTR dataset/model types,
evaluation.metric='chamfer', and resolved data/checkpoint paths. Printing a
config does not import the plugin, read all data, build CUDA extensions, or
prove training readiness.
Do not proceed when a path is missing, an override is unclear, requested GPUs exceed visible GPUs, the config/checkpoint pairing is unverified, or a required CUDA/custom-op probe has not passed.
For a supported single-process training attempt:
python tools/train.py CONFIG.py \
--work-dir work_dirs/RUN_ID \
--gpus 1 --seed 42 --deterministic --launcher none
For one-node distributed training, use the bundled validator from this sub-skill directory. It prints a command by default and starts nothing:
python scripts/launch_distributed.py train \
--project-root MAPTR_ROOT --config projects/configs/maptr/CONFIG.py \
--gpus N -- --work-dir work_dirs/RUN_ID --seed 42
For evaluation, use the same validator even with one GPU. The checked-in test
entry point intentionally rejects --launcher none:
python scripts/launch_distributed.py test \
--project-root MAPTR_ROOT --config projects/configs/maptr/CONFIG.py \
--checkpoint work_dirs/RUN_ID/epoch_N.pth --gpus N
The test command appends --eval chamfer. Never substitute the generic
3D-detection bbox launcher for MapTR. The vector-map datasets accept
chamfer and iou; project train/eval instructions and MapTR configs use
chamfer.
Review launch_distributed.py, then add
--execute only after its dry-run output and warnings pass human review.
Execution can allocate GPUs and run for hours.
A training work directory should receive the merged config, timestamped text
log, logger outputs, and checkpoints such as epoch_1.pth according to
checkpoint_config.interval. MapTR 24-epoch configs normally evaluate every
two epochs and save every epoch. Confirm actual config values rather than
assuming those intervals for another config.
Chamfer evaluation should print per-class AP at thresholds 0.5, 1.0, and 1.5,
plus NuscMap_chamfer/mAP-style detail keys, and write formatted predictions
below a timestamped test/<config-name>/ directory. Treat those as expected
shapes only, not benchmark claims.
Record the exact command, CUDA_VISIBLE_DEVICES, seed, deterministic flag,
merged config, checkpoint identity, environment versions, and complete log.
Do not compare scores from different configs, class maps, point sampling, data
versions, or checkpoints as if they were equivalent.
--resume-from restores training state; a nonexistent path is silently not
applied by the training entry point. Validate it before launch.pretrained path initializes a new model; it is not a training
resume checkpoint. load_from loads weights without promising optimizer and
epoch continuity.loss_scale=512. Confirm the
merged config and backend support. Do not add a second AMP mechanism.tools/test.py --out is parsed but reaches an intentional assertion instead
of dumping predictions. --show/--show-dir are not forwarded through its
distributed test path. Route artifact visualization elsewhere.Use troubleshooting.md for symptoms, causes, recovery, and explicit stop conditions. In particular:
metric bbox is not supported → replace --eval bbox with
--eval chamfer; do not reinterpret a detector metric as a map metric.--gpus 1, or
move to a proven eight-GPU host; never oversubscribe silently.Do not run merely to discover whether a prerequisite was satisfied. If configuration, data, checkpoint provenance, backend compatibility, GPU count, or budget remains unresolved, return a blocked preflight with the missing evidence and the next safe probe.