[doc] Update redme.md with urartu v2.0 and add slurm in the action config

Author: tamohannes

README.md

@@ -18,23 +18,28 @@ We compare the abilities of state-of-the-art LLMs in embodying personas and hold
   <img width="350" alt="roleplay-schema" src="https://github.com/UKPLab/roleplay/assets/23078323/085c51e0-248b-4594-a2f6-6f820f662eba">
 </p>
 
-The LLM Roleplay (roleplay) codebase is built upon the [UrarTU framework](https://github.com/tamohannes/urartu). For detailed insights into its structure, please refer to the [Getting Started Guide](https://github.com/tamohannes/urartu/blob/master/getting_started.md).
+The LLM Roleplay (roleplay) codebase is built upon the [UrarTU framework](https://github.com/tamohannes/urartu) (version 2). For detailed insights into its structure, please refer to the [Getting Started Guide](https://github.com/tamohannes/urartu/blob/master/getting_started.md).
 
 ## Installation
 Getting started with roleplay is a breeze! 💨 Just follow these steps to set up the necessary packages and create a local package called `roleplay`:
 
-- Clone the repository: `git clone [email protected]:tamohannes/llm_roleplay.git`
+- Clone the repository: `git clone [email protected]:UKPLab/roleplay.git`
 - Navigate to the project directory: `cd roleplay`
 - Execute the magic command: `pip install .`
 
+🪄 After running the previous command, `roleplay` will install the required packages including the latest version of `urartu` (>=2.0) and make it ready to use.
+Plus, an alias will be created, allowing you to access roleplay from any directory on your operating system effortlessly:
 
-Adding a touch of convenience! 🪄 After running the previous command, `roleplay` will be set up and ready to use. Plus, an alias will be created, allowing you to access roleplay from any directory on your operating system effortlessly:
+```bash
+urartu --help
+```
 
+Now, to register `roleplay` under the corresponding name in `urartu` we need to run the following command by providing the path where the module is located, for more info refere to [UrarTU's documentation](https://pypi.org/project/urartu/):
 ```bash
-roleplay --help
+urartu register --name=roleplay --path=PATH_TO_ROLEPLAY/roleplay
 ```
-<!-- > **Note for Usage on Slurm System**
-> For an enhanced experience with the Slurm job cancellation process, it is recommended to utilize a specific fork of the `submitit` package available at: [https://github.com/tamohannes/submitit](https://github.com/tamohannes/submitit). This fork includes the `ResumableSlurmJob.on_job_fail` callback, which allows the incorporation of additional functionality within this callback to ensure a graceful job termination. -->
+
+After this you can run `urartu -h` again to see the available modules under `launch` command and make sure that `roleplay` is present there.
 
 
 
@@ -63,12 +68,12 @@ aim up
 Let's get started with generating dialogues using the `roleplay` action. The process is simple: just provide the name of the configuration file containing the action, followed by the action name itself. For the `roleplay` action, we'll initiate it by using the Mistral 8x7B model as the inquirer. 🎇
 
 ```bash
-roleplay action_config=roleplay +action_config/task/model_inquirer=mixtral +action_config/task/model_responder=llama action_config.task.model_inquirer.api_token="YOUR_TOKEN"
+urartu launch --name=roleplay action_config=roleplay +action_config/task/model_inquirer=mixtral +action_config/task/model_responder=llama action_config.task.model_inquirer.api_token="YOUR_TOKEN"
 ```
 
 The `action_config` parameter specifies which configuration file to use to run the action. Afterward, we define the configuration file for the inquirer using the `model_inquirer` argument and set the configuration for the responder with the `model_responder` argument.
 
-To execute the command on a Slurm cluster, configure the `roleplay/config/main.yaml` file with the corresponding fields, and then use the same command to run the job. For more details on how to edit the configuration files, please refer to the upcoming sections.
+To execute the command on a Slurm cluster, modify the `roleplay/configs/action_config/generate_dialogues.yaml` file with the corresponding fields, and then use the same command to run the job. For more details on how to edit the configuration files, please refer to the upcoming sections.
 
 > **Huggingface Authentication**
 > You might need to log in to HuggingFace to authenticate your use of Mistral 8x7B. To do this, use the `huggingface-cli` login command and provide your access token.
@@ -77,35 +82,37 @@ To execute the command on a Slurm cluster, configure the `roleplay/config/main.y
 
 ## Configs: Tailoring Your Setup
 
-The default configs which shape the way of configs are defined under `roleplay/config` directory:
-- `roleplay/config/main.yaml`: This core configuration file sets the foundation for default settings, covering all available keys within the system.
-- `roleplay/config/action_config` Directory: A designated space for specific action configurations.
+The default configs which shape the way of configs are defined in `urartu` under `urartu/config` directory:
+- `urartu/config/main.yaml`: This core configuration file sets the foundation for default settings, covering all available keys within the system.
+- `urartu/config/action_config` Directory: A designated space for specific action configurations.
+For more see the structure of [UrarTU](https://github.com/tamohannes/urartu).
 
 ### Crafting Customizations
 
 You have two flexible options for tailoring your configurations in `roleplay`. 
 
-1. **Custom Config Files**: To simplify configuration adjustments, `roleplay` provides a dedicated `configs` directory where you can store personalized configuration files. These files seamlessly integrate with Hydra's search path. The directory structure mirrors that of `roleplay/config`. You can define project-specific configurations in specially named files. For instance, the `roleplay.yaml` file within the `configs` directory can house all the configurations specific to your `roleplay` project, with customized settings.
+1. **Custom Config Files**: To simplify configuration adjustments, `roleplay` provides a dedicated `configs` directory where you can store personalized configuration files. These files seamlessly integrate with Hydra's search path. The directory structure mirrors that of `urartu/config`. You can define project-specific configurations in specially named files.
+The `generate_dialogues.yaml` file within the `configs` directory houses all the configurations specific to our `roleplay` project, with customized settings.
 
     - **Personalized User Configs**: To further tailor configurations for individual users, create a directory named `configs_{username}` at the same level as the `configs` directory, where `{username}` represents your operating system username (check out `configs_tamoyan` for an example). The beauty of this approach is that there are no additional steps required. Your customizations will smoothly load and override the default configurations, ensuring a seamless and hassle-free experience. ✨
 
-    The order of precedence for configuration overrides is as follows: `roleplay/config`, `configs`, `configs_{username}`, giving priority to user-specific configurations.
+    The order of precedence for configuration overrides is as follows: `urartu/config`, `roleplay/configs`, `roleplay/configs_{username}`, giving priority to user-specific configurations.
 
-2. **CLI Approach**: For those who prefer a command-line interface (CLI) approach, `roleplay` offers a convenient method. You can enhance your commands with specific key-value pairs directly in the CLI. For example, modifying your working directory path is as simple as:
+2. **CLI Approach**: For those who prefer a command-line interface (CLI) approach, `urartu` offers a convenient method. You can enhance your commands with specific key-value pairs directly in the CLI. For example, modifying your working directory path is as simple as:
 
     ```bash
-    roleplay action_config=roleplay action_config.workdir=PATH_TO_WORKDIR
+    urartu launch --name=roleplay action_config=roleplay action_config.workdir=PATH_TO_WORKDIR
     ```
 
-Choose the method that suits your workflow best and enjoy the flexibility `roleplay` provides for crafting custom configurations.
+Choose the method that suits your workflow best and enjoy the flexibility `urartu` provides for crafting custom configurations.
 
 
 ### Effortless Launch
 
-With `roleplay`, launching actions is incredibly easy, offering you two options. 🚀
+With `urartu`, launching actions is incredibly easy, offering you two options. 🚀
 
 - **Local Marvel:** This option allows you to run jobs on your local machine, right where the script is executed.
-- **Cluster Voyage:** This choice takes you on a journey to the Slurm cluster. By adjusting the `slurm.use_slurm` setting in `config/main.yaml`, you can easily switch between local and cluster execution.
+- **Cluster Voyage:** This choice takes you on a journey to the Slurm cluster. By adjusting the `slurm.use_slurm` setting in `roleplay/configs/action_config/generate_dialogues.yaml`, you can easily switch between local and cluster execution.
 
 Enjoy the flexibility to choose the launch adventure that best suits your needs and goals!
 

roleplay/configs/action_config/generate_dialogues.yaml

@@ -201,6 +201,39 @@ action_config:
     num_workers: 4
     shuffle: false
 
+slurm:
+  # Whether or not to run the job on SLURM
+  use_slurm: false
+  # Name of the job on SLURM
+  name: "example"
+  # Comment of the job on SLURM
+  comment: "example job"
+  # Partition of SLURM on which to run the job. This is a required field if using SLURM.
+  partition: ""
+  account: ""
+  # Where the logs produced by the SLURM jobs will be output
+  log_folder: "./slurm_logs"
+  # Maximum number of hours / minutes needed by the job to complete. Above this limit, the job might be pre-empted.
+  time_hours: 1
+  time_minutes: 0
+  # Additional constraints on the hardware of the nodes to allocate (example 'volta' to select a volta GPU)
+  constraint: ""
+  # GB of RAM memory to allocate for each node
+  mem_gb: 100
+  # TCP port on which the workers will synchronize themselves with torch distributed
+  port_id: 40050
+  # Number of CPUs per GPUs to request on the cluster.
+  num_cpu_per_proc: 4
+  # Number of GPUs per node to request on the cluster.
+  num_gpu_per_node: 4
+  # Number of nodes to request on the cluster.
+  num_nodes: 1
+  # Number of processes per node to request on the cluster.
+  num_proc_per_node: 1
+  # Any other parameters for slurm (e.g. account, hint, distribution, etc.,) as dictated by submitit.
+  # Please see https://github.com/facebookincubator/submitit/issues/23#issuecomment-695217824.
+  additional_parameters: {}
+
 hydra:
   sweeper:
     params: