From c2101af4b54f6fc6a50d5b2ffad760ca3a70947c Mon Sep 17 00:00:00 2001
From: jgugliel <julien.guglielmini@pasteur.fr>
Date: Mon, 14 Mar 2022 17:54:13 +0100
Subject: [PATCH] README update

---
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.md b/README.md
index 84c22c8..8fa194c 100644
--- a/README.md
+++ b/README.md
@@ -42,7 +42,7 @@ The number of threads $THREADS passed by the `-t` option will be used for both t
 ### Using `sbatch`
 This is the recommended way of using wGRR. Simply use the `sbatch` command with the proper partition specification. Note that there is no need to allocate more than one CPU (with the `sbatch` option `-c`). For example:
 ```bash
-sbatch -p hubbioit ./wGRR -f test_2.prt -t 30
+sbatch -p hubbioit ./wGRR -i test_2.prt -t 30
 ```
 This will run wGRR on the file test_2.prt on the hubbioit partition. The MMseqs job will be submitted to the cluster's scheduler with 30 CPUs. Then for the actual wGRR calculation, the required amount of jobs (depending on the value passed with the `-a` option) will be submitted to the queue. If 100 jobs (1 CPU each) are necessary, a job array of 100 jobs will be submitted to the scheduler.
 You can adjust the number of maximum jobs running simultaneously (to avoid using 100% of your partition's CPUs) by using the `-m` option.
-- 
GitLab