|
| 1 | +# Configuring Graphium with Hydra |
| 2 | +This document provides users with a point of entry to composing configs in Graphium. As a flexible library with many features, configuration is an important part of Graphium. To make configurations as reusable as possible while providing maximum flexibility, we integrated Graphium with `hydra`. Our config structure is designed to make the following functionality as accessible as possible: |
| 3 | + |
| 4 | +- Switching between **accelerators** (CPU, GPU and IPU) |
| 5 | +- **Benchmarking** different models on the same dataset |
| 6 | +- **Fine-tuning** a pre-trained model on a new dataset |
| 7 | + |
| 8 | +In what follows, we describe how each of the above functionality is achieved and how users can benefit from this design to achieve the most with Graphium with as little configuration as possible. |
| 9 | + |
| 10 | +## Accelerators |
| 11 | +With Graphium supporting CPU, GPU and IPU hardware, easily switching between these accelerators is pre-configured. General, accelerator-specific configs are specified under `accelerator/`, whereas experiment-specific differences between the accelerators are specialized under `training/accelerator`. |
| 12 | + |
| 13 | +## Benchmarking |
| 14 | +Benchmarking multiple models on the same datasets and tasks requires us to easily switch between model configurations without redefining major parts of the architecture, task heads, featurization, metrics, predictor, etc. For example, when changing from a GCN to a GIN model, a simple switch of `architecture.gnn.layer_type: 'pyg:gin'` might suffice. Hence, we abstract the `model` configs under `model/` where such model configurations can be specified. |
| 15 | +In addition, switching models may have implications on configs specific to your current experiment, such as the name of the run or the directory to which model checkpoints are written. To enable such overrides, we can utilize `hydra` [specializations](https://hydra.cc/docs/patterns/specializing_config/). For example, for our ToyMix dataset, we specify the layer type under `model/[model_name].yaml`, e.g., for the GCN layer, |
| 16 | + |
| 17 | +```yaml |
| 18 | +# @package _global_ |
| 19 | + |
| 20 | +architecture: |
| 21 | + gnn: |
| 22 | + layer_type: 'pyg:gcn' |
| 23 | +``` |
| 24 | +
|
| 25 | +and set experiment-related parameters in `training/model/toymix_[model_name].yaml` as a specialization, e.g., for the GIN layer, |
| 26 | + |
| 27 | +```yaml |
| 28 | +# @package _global_ |
| 29 | +
|
| 30 | +constants: |
| 31 | + name: neurips2023_small_data_gin |
| 32 | + ... |
| 33 | +
|
| 34 | +trainer: |
| 35 | + model_checkpoint: |
| 36 | + dirpath: models_checkpoints/neurips2023-small-gin/ |
| 37 | +``` |
| 38 | +We can now utilize `hydra` to e.g., run a sweep over our models on the ToyMix dataset via |
| 39 | + |
| 40 | +```bash |
| 41 | +python main_run_multitask.py -m model=gcn,gin |
| 42 | +``` |
| 43 | +where the ToyMix dataset is pre-configured in `main.yaml`. Read on to find out how to define new datasets and architectures for pre-training and fine-tuning. |
| 44 | + |
| 45 | +## Pre-training / Fine-tuning |
| 46 | +From a configuration point-of-view, fine-tuning requires us to load a pre-trained model and attach new task heads. However, in a highly configurable library such as ours changing the task heads also requires changes to the logged metrics, loss functions and the source of the fine-tuning data. To allow a quick switch between pre-training and fine-tuning, by default, we configure models and the corresponding tasks in a separate manner. More specifically, |
| 47 | + |
| 48 | +- under `architecture/` we store architecture related configurations such as the definition of the GNN/Transformer layers or positional/structural encoders |
| 49 | +- under `tasks/` we store configurations specific to one task set, such as the multi-task dataset ToyMix |
| 50 | +- under `training/` we store configurations specific to training models which could be different for each combination of `architecture` and `tasks` |
| 51 | + |
| 52 | +Since architecture and tasks are logically separated it now becomes very easy to e.g., use an existing architecture backbone on a new set of tasks or a new dataset altogether. Additionally, separating training allows us to specify different training parameters for e.g., pre-training and fine-tuning of the same architecture and task set. |
| 53 | +We will now detail how you can add new architectures, tasks and training configurations. |
| 54 | + |
| 55 | +### Adding an architecture |
| 56 | +The architecture config consists of specifications of the neural network components, including encoders, under the config key `architecture` and the featurization, containing the positional/structural information that is to be extracted from the data. |
| 57 | +To add a new architecture, create a file `architecture/my_architecture.yaml` with the following information specified: |
| 58 | +```yaml |
| 59 | +# @package _global_ |
| 60 | +architecture: |
| 61 | + model_type: FullGraphMultiTaskNetwork # for example |
| 62 | + pre_nn: |
| 63 | + ... |
| 64 | +
|
| 65 | + pre_nn_edges: |
| 66 | + ... |
| 67 | +
|
| 68 | + pe_encoders: |
| 69 | + encoders: # your encoders |
| 70 | + ... |
| 71 | +
|
| 72 | + gnn: # your GNN definition |
| 73 | + ... |
| 74 | +
|
| 75 | + graph_output_nn: # output NNs for different levels such as graph, node, etc. |
| 76 | + graph: |
| 77 | + ... |
| 78 | + node: |
| 79 | + ... |
| 80 | + ... |
| 81 | +
|
| 82 | +datamodule: |
| 83 | + module_type: "MultitaskFromSmilesDataModule" |
| 84 | + args: # Make sure to not specify anything task-specific here |
| 85 | + ... |
| 86 | + featurization: |
| 87 | + ... |
| 88 | +``` |
| 89 | +You can then select your new architecture during training, e.g., by running |
| 90 | +```bash |
| 91 | +python main_run_multitask.py architecture=my_architecture |
| 92 | +``` |
| 93 | + |
| 94 | +### Adding tasks |
| 95 | +The task set config consists of specifications for the task head neural nets under the config key `architecture.task_heads`; if required, any task-specific arguments to the datamodule you use, e.g., `datamodule.args.task_specfic_args` when using the `MultitaskFromSmilesDataModule` datamodule; the per-task metrics under the config key `metrics.[task]` where `[task]` matches the tasks specified under `architecture.task_heads`; the per-task configs of the `predictor` module, as well as the loss functions of the task set under the config key `predictor.loss_fun`. |
| 96 | +To add a new task set, create a file `tasks/my_tasks.yaml` with the following information specified: |
| 97 | +```yaml |
| 98 | +# @package _global_ |
| 99 | +architecture: |
| 100 | + task_heads: |
| 101 | + task1: |
| 102 | + ... |
| 103 | + task2: |
| 104 | + ... |
| 105 | +
|
| 106 | +datamodule: # optional, depends on your concrete datamodule class. Here: "MultitaskFromSmilesDataModule" |
| 107 | + args: |
| 108 | + task_specific_args: |
| 109 | + task1: |
| 110 | + ... |
| 111 | + task2: |
| 112 | + ... |
| 113 | +
|
| 114 | +metrics: |
| 115 | + task1: |
| 116 | + ... |
| 117 | + task2: |
| 118 | + ... |
| 119 | +
|
| 120 | +predictor: |
| 121 | + metrics_on_progress_bar: |
| 122 | + task1: |
| 123 | + task2: |
| 124 | + loss_fun: ... # your loss functions for the multi-tasking |
| 125 | +``` |
| 126 | +You can then select your new dataset during training, e.g., by running |
| 127 | +```bash |
| 128 | +python main_run_multitask.py tasks=my_tasks |
| 129 | +``` |
| 130 | + |
| 131 | +### Adding training configs |
| 132 | +The training configs consist of specifications to the `predictor` and `trainer` modules. |
| 133 | +To add new training configs, create a file `training/my_training.yaml` with the following information specified: |
| 134 | +```yaml |
| 135 | +# @package _global_ |
| 136 | +predictor: |
| 137 | + optim_kwargs: |
| 138 | + lr: 4.e-5 |
| 139 | + torch_scheduler_kwargs: # example |
| 140 | + module_type: WarmUpLinearLR |
| 141 | + max_num_epochs: &max_epochs 100 |
| 142 | + warmup_epochs: 10 |
| 143 | + verbose: False |
| 144 | + scheduler_kwargs: |
| 145 | + ... |
| 146 | +
|
| 147 | +trainer: |
| 148 | + ... |
| 149 | + trainer: # example |
| 150 | + precision: 16 |
| 151 | + max_epochs: *max_epochs |
| 152 | + min_epochs: 1 |
| 153 | + check_val_every_n_epoch: 20 |
| 154 | +``` |
0 commit comments