render rollout merge

[Naveen-Raj-M]

Objective:
This RFP proposes to integrate the execution of rollout prediction and rendering function. It should also provide an option to disable the automatic rendering

Current System:
Currently, the user has to execute rollout prediction and rendering through separate commands.

Proposed Changes:

1. In the gns/config.yaml file, add default configurations for rendering. By default, the render is set to true in the rendering configuration
2. In the gns/train.py script, within the predict method, after generating the example rollout file, check if config.rendering.render is set to true. If so, invoke the rendering method to handle the rendering process.
3. The rendering function takes the filename and directory as arguments and calls the render class from the render_rollout module.
4. Based on the configuration, either a GIF animation is generated using the render_gif_animation method or VTK output is produced using the write_vtk method from the render_rollout module
5. README.md is updated to describe this feature

Expected Challenges:

1. If multiple rollouts are predicted with a single input file, this feature will render for each predicted example. But, this can be overcome by setting the rendering.render option to be False and render separately with the specific rollout file.

Testing Plan:
The following steps are used to test the functioning of rendering function in gns/train.py script,

1. Fixtures are set up to generate temporary directories and dummy .pkl data for testing purposes.
2. Configuration Fixtures (cfg_gif and cfg_vtk) provide configuration objects for rendering GIFs or VTK output, respectively, using the DictConfig from omegaconf.
3. Two test functions (test_rendering_gif and test_rendering_vtk) are used to test if the rendering logic for GIFs and VTKs works correctly.
4. The rendering function (imported from gns.train) is called with the corresponding configuration, and the tests assert the creation of output files (GIF for the GIF test, and two VTK directories for the VTK test).
5. The temporary directories and files are cleaned up after the tests.

[kks32]

• You need to update readme.
• Write a test to see if rollouts are predicted correctly
• Don't you need to update or define the hydra configs?

[kks32]

Document all your functions properly using docstrings -- Google style

[kks32]

Refactor the code and be consistent, improve readability.

[kks32]

Fix the black failures, then we should be good to merge