Principle:Danijar Dreamerv3 Configuration Loading
| Knowledge Sources | |
|---|---|
| Domains | Reinforcement_Learning, Configuration |
| Last Updated | 2026-02-15 09:00 GMT |
Overview
A design pattern for hierarchical configuration loading that merges YAML-based default presets with command-line overrides to produce a single immutable configuration object for RL training.
Description
Configuration Loading in DreamerV3 follows a layered merging strategy: a YAML file defines named configuration presets (e.g., environment-specific settings, model sizes), a base defaults config is loaded first, then any requested named configs are merged on top, and finally command-line flags override individual values. This produces a fully resolved Config object that controls every aspect of training — from model architecture to optimizer hyperparameters to logging backends.
The pattern solves the problem of managing hundreds of hyperparameters across diverse environments (Atari, DMC, Minecraft, etc.) while keeping a single entry point. Named presets like atari, dmc, and size100M can be composed freely.
Usage
Use this principle when launching any DreamerV3 run mode (training, evaluation, distributed training). It is the mandatory first step that produces the configuration object consumed by all downstream components (agent, environment, replay, logger).
Theoretical Basis
Hierarchical configuration follows the override pattern:
Pseudo-code Logic:
# Abstract algorithm (NOT real implementation)
base_config = load_yaml("configs.yaml")["defaults"]
for preset_name in requested_presets:
base_config = merge(base_config, load_yaml("configs.yaml")[preset_name])
final_config = merge(base_config, parse_cli_flags())
The key properties are:
- Composability: Multiple presets can be stacked (e.g., defaults + atari + size100M)
- Override semantics: Later values replace earlier ones at the leaf level
- Immutability: The final Config object is frozen after construction