[Feature, Example] A3C Atari Implementation for TorchRL

[simeetnayan81]

Description

Describe your changes in detail.
This PR adds an implementation of the Asynchronous Advantage Actor-Critic (A3C) algorithm for Atari environments in the torchrl/sota-implementations directory. The main files added are:

a3c_atari.py: Contains the A3C worker class, shared optimizer, and main training loop using multiprocessing.
utils_atari.py: Provides utility functions for environment creation, model construction, and evaluation, adapted for Atari tasks.
config_atari.yaml: Configuration file for hyperparameters, environment settings, and logging.

The implementation leverages TorchRL's collectors, objectives, and logging utilities, and is designed to be modular and extensible for research and benchmarking. Some of the utils functions are also borrowed from a2c_atari.

Motivation and Context

This change is required to provide a strong, reproducible baseline for A3C on Atari environments using TorchRL. It enables researchers and practitioners to benchmark and compare reinforcement learning algorithms within the TorchRL ecosystem. The implementation follows best practices for distributed RL and is compatible with TorchRL's API.

This PR solves the issue: #1755

Types of changes

What types of changes does your code introduce? Remove all that do not apply:

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds core functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation (update in the documentation)
• Example (update in the folder of examples)

Checklist

Go over all the following points, and put an x in all the boxes that apply.
If you are unsure about any of these, don't hesitate to ask. We are here to help!

• I have read the CONTRIBUTION guide (required)
• My change requires a change to the documentation.
• I have updated the tests accordingly (required for a bug fix or a new feature).
• I have updated the documentation accordingly.

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/rl/3001

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 4 New Failures, 2 Cancelled Jobs, 1 Unrelated Failure

As of commit 3ebad77 with merge base fbfd8a8 ():

NEW FAILURES - The following jobs have failed:

• Continuous Benchmark (PR) / CPU Pytest benchmark (gh)
  Workflow failed! Resource not accessible by integration
• Habitat Tests on Linux / tests (3.9, 12.8) / linux-job (gh)
  RuntimeError: Command docker exec -t 96997f589d3c74d918dc38dbf2ac214adea1efdb69dac8ebcb607020afd39749 /exec failed with exit code 1
• Unit-tests on Linux / tests-cpu (3.10) / linux-job (gh)
  test/test_env.py::TestNonTensorEnv::test_parallel[False-False]
• Unit-tests on Linux / tests-olddeps (3.9, 11.6) / linux-job (gh)
  AttributeError: module 'torch.utils._pytree' has no attribute 'register_pytree_node'

CANCELLED JOBS - The following jobs were cancelled. Please retry:

• Continuous Benchmark (PR) / GPU Pytest benchmark (gh)
  ##[error]The operation was canceled.
• LLM Tests on Linux / unittests (3.9, 12.8) / linux-job (gh)

BROKEN TRUNK - The following job failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

• Libs Tests on Linux / unittests-gym (3.9, 12.8) / linux-job (gh) (trunk failure)
  AttributeError: module 'torch.utils._pytree' has no attribute 'register_pytree_node'

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[vmoens]

This all looks pretty good!
Could you share a (couple of) learning curve?
Another thing to do before landing is to add it to the sota-implementations CI run:
https://github.com/pytorch/rl/blob/main/.github/unittest/linux_sota/scripts/test_sota.py
Make sure the config passed there is as much barebone as we can - we just want to run the script for a couple of collection / optim iters and make sure it runs without error (not that it properly trains).
We also need to add it to the sota-check runs

[simeetnayan81]

Thanks @vmoens . I'll add the required changes as well as some training curves.

[simeetnayan81]

@vmoens, I have added the required scripts as well.

Not getting enough resources and time for hyperparam tuning to generate a proper training curve.

[vmoens]

LGTM, just a minor comment on the logger!

[vmoens]

What I usually see is that the logger is only passed to the first worker.
Another thing is that you may want to assume that the logger isn't serializable and should be instantiated locally within the worker.

[simeetnayan81]

Oh yea, I did that because I thought logging any single worker should be a good representative of the global model since anyway the weights are being copied. Logging all the worker might not be really useful but that can be done as well.

[vmoens]

we should have way fewer workers - I think we need users to tell us how many.

[simeetnayan81]

That can be configured in the config_atari. You want me to explicitly set it to some constant here?

[vmoens]

To shuffle things a bit I usually rely on a replay buffer instance rather than just splitting the data

[vmoens]

can you explain what we do here? What do we use the _grad for?

[simeetnayan81]

_grad is used to store the gradients for each parameter.
We copy local gradients to the global model so the global model can be updated with the optimizer.
This is a key step in A3C, where multiple workers asynchronously update a shared global model.

[vmoens]

shouldn't we move this to the utils file?

[simeetnayan81]

Sure, will do it

[vmoens]

I made a few edits.
Can you explain the way the params are shared and updated? I'm not sure I see the logic

[simeetnayan81]

I made a few edits. Can you explain the way the params are shared and updated? I'm not sure I see the logic

There is a global model (shared across all workers) and a local model (each worker has its own copy).
The global model’s parameters are placed in shared memory so all workers can access and update them.
Each worker interacts with its own environment using its local model.
After collecting experience, the worker computes gradients (via backpropagation) on its local model.
The gradients from the local model are copied to the corresponding parameters of the global model (global_param._grad = local_param.grad).
The optimizer (e.g., Adam) is called on the global model, using the gradients just copied from the local model.
This updates the global model’s parameters.
The local model can be periodically updated (synced) from the global model to keep it up-to-date.