Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Configuration management #80

Closed
kks32 opened this issue Jun 24, 2024 · 1 comment
Closed

RFC: Configuration management #80

kks32 opened this issue Jun 24, 2024 · 1 comment
Assignees
Labels
Priority: High Priority: High
Milestone

Comments

@kks32
Copy link
Contributor

kks32 commented Jun 24, 2024

Configuration Management

Summary

Use a configuration file instead of flags

Motivation

Currently, the code uses flags for configuration, which are defined in train.py. This approach has limitations:

  • It's not easily reusable across different scripts
  • It's hard to version control configurations
  • It doesn't support hierarchical configurations

Design Detail

Implement a configuration system using a library like hydra or OmegaConf. This would allow:

  • YAML-based configuration files
  • Easy overriding of config values from command line
  • Hierarchical configurations
  • Better version control of configurations

Example:

# Top-level configuration
mode: train

# Data configuration
data:
  path: /path/to/your/data
  batch_size: 2
  noise_std: 6.7e-4

# Model configuration
model:
  path: models/
  file: null
  train_state_file: train_state.pt

# Output configuration
output:
  path: rollouts/
  filename: rollout

# Training configuration
training:
  steps: 20000000
  validation_interval: null
  save_steps: 5000
  learning_rate:
    initial: 1e-4
    decay: 0.1
    decay_steps: 5000000

# Hardware configuration
hardware:
  cuda_device_number: null
  n_gpus: 1

# Logging configuration
logging:
  tensorboard_dir: logs/

constants:
  input_sequence_length: 6
  num_particle_types: 9
  kinematic_particle_id: 3

Drawbacks

Why should we not do this? Please consider the impact on users,
Breaking change on existing workflow.

Rationale and Alternatives

Why is this design the best in the space of possible designs?

  • Easier set-up with DesignSafe and other CI tools. Keep track of all configuration files.

What other designs have been considered and what is the rationale for not choosing them?

What is the impact of not doing this?

  • Command line args are too long and can be harder to keep track

Unresolved questions

What parts of the design do you expect to resolve through the RFC process before this gets merged?

  • Basic configuration (replicate all flags)

Changelog

@kks32 kks32 added the Priority: High Priority: High label Jun 24, 2024
@kks32 kks32 added this to the GNS v2.0 milestone Jun 24, 2024
@kks32 kks32 mentioned this issue Jun 25, 2024
4 tasks
@kks32 kks32 changed the title Configuration management RFC: Configuration management Jun 26, 2024
@kks32
Copy link
Contributor Author

kks32 commented Jun 28, 2024

Fixed in #81

@kks32 kks32 closed this as completed Jun 28, 2024
@github-project-automation github-project-automation bot moved this from To do to Done in Graph Network Simulator Jun 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority: High Priority: High
Projects
Development

No branches or pull requests

2 participants