Context object

Context objects used in luz to share information between model methods, metrics and callbacks.

Details

The ctx object is used in luz to share information between the training loop and callbacks, model methods, and metrics. The table below describes information available in the ctx by default. Other callbacks could potentially modify these attributes or add new ones.

Attribute	Description
`verbose`	The value (`TRUE` or `FALSE`) attributed to the `verbose` argument in `fit` .
`accelerator`	Accelerator object used to query the correct device to place models, data, etc. It assumes the value passed to the `accelerator` parameter in `fit`.
`model`	Initialized `nn_module` object that will be trained during the `fit` procedure.
`optimizers`	A named list of optimizers used during training.
`data`	The currently in-use dataloader. When training it’s `ctx$train_data`, when doing validation its `ctx$valid_data`. It can also be the prediction dataset when in `predict`.
`train_data`	Dataloader passed to the `data` argument in `fit`. Modified to yield data in the selected device.
`valid_data`	Dataloader passed to the `valid_data` argument in `fit`. Modified to yield data in the selected device.
`min_epochs`	Minimum number of epochs the model will be trained for.
`max_epochs`	Maximum number of epochs the model will be trained for.
`epoch`	Current training epoch.
`iter`	Current training iteration. It’s reset every epoch and when going from training to validation.
`training`	Whether the model is in training or validation mode. See also `help("luz_callback_train_valid")`
`callbacks`	List of callbacks that will be called during the training procedure. It’s the union of the list passed to the `callbacks` parameter and the default `callbacks`.
`step`	Closure that will be used to do one `step` of the model. It’s used for both training and validation. Takes no argument, but can access the `ctx` object.
`call_callbacks`	Call callbacks by name. For example `call_callbacks("on_train_begin")` will call all callbacks that provide methods for this point.
`batch`	Last batch obtained by the dataloader. A batch is a `list()` with 2 elements, one that is used as `input` and the other as `target`.
`input`	First element of the last batch obtained by the current dataloader.
`target`	Second element of the last batch obtained by the current dataloader.
`pred`	Last predictions obtained by `ctx$model$forward` . Note: can be potentially modified by previously ran callbacks. Also note that this might not be available if you used a custom training step.
`loss_fn`	The active loss function that will be minimized during training.
`loss`	Last computed loss from the model. Note: this might not be available if you modified the training or validation step.
`opt`	Current optimizer, ie. the optimizer that will be used to do the next `step` to update parameters.
`opt_nm`	Current optimizer name. By default it’s `opt` , but can change if your model uses more than one optimizer depending on the set of parameters being optimized.
`metrics`	`list()` with current metric objects that are `update`d at every `on_train_batch_end()` or `on_valid_batch_end()`. See also `help("luz_callback_metrics")`
`records`	`list()` recording metric values for training and validation for each epoch. See also `help("luz_callback_metrics")` . Also records profiling metrics. See `help("luz_callback_profile")` for more information.
`handlers`	A named `list()` of handlers that is passed to `rlang::with_handlers()` during the training loop and can be used to handle errors or conditions that might be raised by other callbacks.
`epoch_handlers`	A named list of handlers that is used with `rlang::with_handlers()`. Those handlers are used inside the epochs loop, thus you can handle epoch specific conditions, that won’t necessarily end training.

Context attributes

Details

See also