Remove unneeded future option and fix broken link (#1729)

Co-authored-by: Jesse Harrison <49673989+jessepharrison@users.noreply.github.com>

Author: helijuottonen

docs/apps/r-env.md

@@ -355,15 +355,13 @@ For analyses requiring a single node, `plan(multisession)` and `plan(multicore)`
 
 To submit a job involving multisession or multicore futures, one should specify a single node (`--nodes=1`) and the number of tasks (`--ntasks=x`; 40 is the maximum on a single node). For guidelines on designing batch job files, see other examples on this page.
 
-The R script below could be used to compare analysis times using sequential, multisession and multicore strategies. Note that we need to separately specify `options(future.availableCores.methods = "Slurm")` for worker allocation to proceed as expected.
+The R script below could be used to compare analysis times using sequential, multisession and multicore strategies. 
 
 ```r
 library(future)
 library(tictoc)
 library(furrr)
 
-options(future.availableCores.methods = "Slurm")
-
 # Different future plans (choose one) 
 # (Note: three workers used for parallel options)
 
@@ -387,8 +385,6 @@ For multi-node analyses using `plan(cluster)`, the job can be submitted using th
 ```r
 library(future)
 
-options(future.availableCores.methods = "Slurm")
-
 cl <- getMPIcluster()
 plan(cluster, workers = cl)
 
@@ -454,7 +450,7 @@ By default, `r-env` is single-threaded. While users may set a desired number of
 
 The module uses OpenMP threading technology and the number of threads can be controlled using the environment variable `OMP_NUM_THREADS`. In practice, the number of threads is set to match the number of cores used for the job. Because `r-env` is based on an Apptainer container, when specifying the number of OpenMP threads we need to use the environment variable `APPTAINERENV_OMP_NUM_THREADS`.
 
-An example batch job script can be found below. Here we submit a job using eight cores (and therefore eight threads) on a single node. Notice how we match the number of threads and cores using `APPTAINERENV_OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK`. By using `APPTAINERENV_OMP_PLACES=cores`, we bind each thread to a single core. We also use `APPTAINERENV_OMP_PROC_BIND=close` to ensure that threads are placed as closely as possible (to allow faster communication between threads). Note that [other options](https://pages.tacc.utexas.edu/~eijkhout/pcse/html/omp-affinity.html) for controlling thread affinity are also available, depending on your analysis.
+An example batch job script can be found below. Here we submit a job using eight cores (and therefore eight threads) on a single node. Notice how we match the number of threads and cores using `APPTAINERENV_OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK`. By using `APPTAINERENV_OMP_PLACES=cores`, we bind each thread to a single core. We also use `APPTAINERENV_OMP_PROC_BIND=close` to ensure that threads are placed as closely as possible (to allow faster communication between threads). Note that [other options](https://theartofhpc.com/pcse/omp-affinity.html) for controlling thread affinity are also available, depending on your analysis.
 
 ```bash
 #!/bin/bash -l

docs/support/tutorials/parallel-r.md

@@ -68,12 +68,10 @@ Multinode analyses will give you access to more resources than a single-node ana
 
 **4. Reserving more resources does not necessarily mean faster analyses.** Finding an optimal number of cores and/or threads is usually a case of trial and error. Often there is a threshold after which only marginal benefits are obtained in relation to the resources you reserve. Also, the more resources one reserves, the longer the wait until they become available.
 
-**5. Make use of `future::availableCores()`**. There are a couple of ways to detect the number of available cores using R. On Puhti, using `parallel::detectCores()` will always give 40 as the result. That is, the function detects how many cores are present on the node, regardless of how many you have reserved. Much more often, the goal is to detect the number of reserved cores. To do this, one can use the package `future`:
+**5. Make use of `parallelly::availableCores()`**. There are a couple of ways to detect the number of available cores using R. On Puhti, using `parallel::detectCores()` will always give 40 as the result. That is, the function detects how many cores are present on the node, regardless of how many you have reserved. Much more often, the goal is to detect the number of reserved cores. To do this, one can use the package `parallelly` (or the package `future` that imports `parallelly`):
 
 ```r
-library(future)
-options(future.availableCores.methods = "Slurm")
-availableCores()
+parallelly::availableCores()
 ```
 **6. Remember that parallelisation support is limited in RStudio**. Forked processes are considered unstable when running R from RStudio. Because of this, certain options for parallelisation (e.g. `plan(multicore)` in the package `future`) are unavailable when using RStudio. If you wish to use multiprocessing while working with RStudio, socket clusters are a more stable option. However, heavier parallel scripts are best submitted as non-interactive batch jobs.