Update ClusterODX

Author: pierotofy

src/content/docs/installation.md

@@ -100,11 +100,11 @@ To install WebODM on a Qnap NAS:
 
 ### Manage Processing Nodes
 
-WebODM can be linked to one or more processing nodes that speak the [NodeODX API](https://github.com/WebODM/NodeODX/blob/master/docs/index.adoc), such as [NodeODX](https://github.com/WebODM/NodeODX), [NodeMICMAC](https://github.com/OpenDroneMap/NodeMICMAC/), [ClusterODM](https://github.com/WebODM/ClusterODM) and [Lightning](https://webodm.net). The default configuration includes a "node-odx-1" processing node which runs on the same machine as WebODM, just to help you get started. As you become more familiar with WebODM, you might want to install processing nodes on separate machines.
+WebODM can be linked to one or more processing nodes that speak the [NodeODX API](https://github.com/WebODM/NodeODX/blob/master/docs/index.adoc), such as [NodeODX](https://github.com/WebODM/NodeODX), [NodeMICMAC](https://github.com/OpenDroneMap/NodeMICMAC/), [ClusterODX](https://github.com/WebODM/ClusterODX) and [Lightning](https://webodm.net). The default configuration includes a "node-odx-1" processing node which runs on the same machine as WebODM, just to help you get started. As you become more familiar with WebODM, you might want to install processing nodes on separate machines.
 
 Adding more processing nodes will allow you to run multiple jobs in parallel.
 
-You can also setup a [ClusterODM](https://github.com/WebODM/ClusterODM) node to run a single task across multiple machines with [distributed split-merge](https://docs.opendronemap.org/large/?highlight=distributed#getting-started-with-distributed-split-merge) and process dozen of thousands of images more quickly, with less memory.
+You can also setup a [ClusterODX](https://github.com/WebODM/ClusterODX) node to run a single task across multiple machines with [distributed split-merge](https://docs.opendronemap.org/large/?highlight=distributed#getting-started-with-distributed-split-merge) and process dozen of thousands of images more quickly, with less memory.
 
 If you don't need the default "node-odx-1" node, simply pass `--default-nodes 0` flag when starting WebODM:
 

src/content/docs/options-flags.md

@@ -508,7 +508,7 @@ Automatically compute image masks using AI to remove the sky. Experimental.
 
 ## sm-cluster
 
-URL to a ClusterODM instance for distributing a split-merge workflow on multiple nodes in parallel.
+URL to a ClusterODX instance for distributing a split-merge workflow on multiple nodes in parallel.
 
 **Options:** `<string>`
 

src/content/docs/tutorials/large-datasets.md

@@ -33,16 +33,16 @@ will create 3 submodels. Make sure to pass `--split-overlap 0` if you manually p
 
 ## Distributed Split-Merge
 
-WebODM can also automatically distribute the processing of each submodel to multiple machines via [NodeODX](https://github.com/WebODM/NodeODX) nodes, orchestrated via [ClusterODM](https://github.com/WebODM/ClusterODM).
+WebODM can also automatically distribute the processing of each submodel to multiple machines via [NodeODX](https://github.com/WebODM/NodeODX) nodes, orchestrated via [ClusterODX](https://github.com/WebODM/ClusterODX).
 
-![ClusterODM](/images/clusterodm.webp)
+![ClusterODX](/images/ClusterODX.webp)
 
 ### Getting Started with Distributed Split-Merge
 
-The first step is start ClusterODM:
+The first step is start ClusterODX:
 
 ```bash
-docker run -ti -p 3001:3000 -p 8080:8080 webodm/clusterodm
+docker run -ti -p 3001:3000 -p 8080:8080 webodm/clusterodx
 ```
 
 Then on each machine you want to use for processing, launch a NodeODX instance via:
@@ -51,7 +51,7 @@ Then on each machine you want to use for processing, launch a NodeODX instance v
 docker run -ti -p 3000:3000 webodm/nodeodx
 ```
 
-Connect via telnet to ClusterODM and add the IP addresses/port of the machines running NodeODX:
+Connect via telnet to ClusterODX and add the IP addresses/port of the machines running NodeODX:
 
 ```bash
 $ telnet <cluster-odm-ip> 8080
@@ -93,7 +93,7 @@ ASR VIEWCMD <number of images> - View command used to create a machine
 !! - Repeat last command
 ```
 
-If the NodeODX instance wasn't active when ClusterODM started, you can perform a `NODE UPDATE`:
+If the NodeODX instance wasn't active when ClusterODX started, you can perform a `NODE UPDATE`:
 
 ```
 # NODE UPDATE
@@ -111,25 +111,25 @@ While a process is running, it is also possible to list the tasks and view the t
 # TASK OUTPUT <taskId> [lines]
 ```
 
-### Autoscaling ClusterODM
+### Autoscaling ClusterODX
 
-ClusterODM also includes the option to autoscale on multiple platforms, including Amazon and Digital Ocean. This allows users to reduce costs associated with always-on instances as well as being able to scale processing based on demand.
+ClusterODX also includes the option to autoscale on multiple platforms, including Amazon and Digital Ocean. This allows users to reduce costs associated with always-on instances as well as being able to scale processing based on demand.
 
 To setup autoscaling you must:
 
-- Have a functioning version of NodeJS installed and then install ClusterODM:
+- Have a functioning version of NodeJS installed and then install ClusterODX:
 
 ```bash
-git clone https://github.com/WebODM/ClusterODM
-cd ClusterODM
+git clone https://github.com/WebODM/ClusterODX
+cd ClusterODX
 npm install
 ```
 
 - Make sure docker-machine is installed.
 - Setup a S3-compatible bucket for storing results.
-- Create a configuration file for [DigitalOcean](https://github.com/WebODM/ClusterODM/blob/master/docs/digitalocean.md) or [Amazon Web Services](https://github.com/WebODM/ClusterODM/blob/master/docs/aws.md).
+- Create a configuration file for [DigitalOcean](https://github.com/WebODM/ClusterODX/blob/master/docs/digitalocean.md) or [Amazon Web Services](https://github.com/WebODM/ClusterODX/blob/master/docs/aws.md).
 
-You can then launch ClusterODM with:
+You can then launch ClusterODX with:
 
 ```bash
 node index.js --asr configuration.json
@@ -143,7 +143,7 @@ info: Can write to S3
 info: Found docker-machine executable
 ```
 
-You should always have at least one static NodeODX node attached to ClusterODM, even if you plan to use the autoscaler for all processing. If you setup auto scaling, you can't have zero nodes and rely 100% on the autoscaler. You need to attach a NodeODX node to act as the "reference node" otherwise ClusterODM will not know how to handle certain requests. For this purpose, you should add a "dummy" NodeODX node and lock it:
+You should always have at least one static NodeODX node attached to ClusterODX, even if you plan to use the autoscaler for all processing. If you setup auto scaling, you can't have zero nodes and rely 100% on the autoscaler. You need to attach a NodeODX node to act as the "reference node" otherwise ClusterODX will not know how to handle certain requests. For this purpose, you should add a "dummy" NodeODX node and lock it:
 
 ```bash
 telnet localhost 8080

src/content/docs/tutorials/using-singularity.md

@@ -34,13 +34,13 @@ singularity run --bind /my/project:/datasets/code \
   --project-path /datasets
 ```
 
-### ClusterODM, NodeODX, SLURM, with Singularity on HPC
+### ClusterODX, NodeODX, SLURM, with Singularity on HPC
 
-You can write a SLURM script to schedule and set up available nodes with NodeODX for ClusterODM to be wired to if you are on the HPC. Using SLURM will decrease the amount of time and processes needed to set up nodes for ClusterODM each time.
+You can write a SLURM script to schedule and set up available nodes with NodeODX for ClusterODX to be wired to if you are on the HPC. Using SLURM will decrease the amount of time and processes needed to set up nodes for ClusterODX each time.
 
 To setup HPC with SLURM, you must make sure SLURM is installed.
 
-SLURM script will be different from cluster to cluster, depending on which nodes in the cluster that you have. However, the main idea is to run NodeODX on each node once, and by default, each NodeODX will be running on port 3000. After that, run ClusterODM on the head node and connect the running NodeODXs to the ClusterODM.
+SLURM script will be different from cluster to cluster, depending on which nodes in the cluster that you have. However, the main idea is to run NodeODX on each node once, and by default, each NodeODX will be running on port 3000. After that, run ClusterODX on the head node and connect the running NodeODXs to the ClusterODX.
 
 Here is an example of a SLURM script assigning nodes 48, 50, 51 to run NodeODX:
 
@@ -66,7 +66,7 @@ wait
 
 You can check for available nodes using `sinfo`, run the script with `sbatch sample.slurm`, and check running jobs with `squeue -u $USER`.
 
-SLURM does not handle assigning jobs to the head node, so run ClusterODM locally. Then connect to the CLI and wire the NodeODXs to ClusterODM:
+SLURM does not handle assigning jobs to the head node, so run ClusterODX locally. Then connect to the CLI and wire the NodeODXs to ClusterODX:
 
 ```bash
 telnet localhost 8080
@@ -76,7 +76,7 @@ telnet localhost 8080
 > NODE LIST
 ```
 
-It is also possible to pre-populate nodes using JSON. If starting ClusterODM from apptainer or docker, the relevant JSON is available at `docker/data/nodes.json`:
+It is also possible to pre-populate nodes using JSON. If starting ClusterODX from apptainer or docker, the relevant JSON is available at `docker/data/nodes.json`:
 
 ```json
 [
@@ -86,13 +86,13 @@ It is also possible to pre-populate nodes using JSON. If starting ClusterODM fro
 ]
 ```
 
-After hosting ClusterODM on the head node and wiring it to NodeODX, you can tunnel to see if ClusterODM works as expected:
+After hosting ClusterODX on the head node and wiring it to NodeODX, you can tunnel to see if ClusterODX works as expected:
 
 ```bash
 ssh -L localhost:10000:localhost:10000 user@hostname
 ```
 
-Open a browser and connect to `http://localhost:10000` (port 10000 is where ClusterODM's administrative web interface is hosted).
+Open a browser and connect to `http://localhost:10000` (port 10000 is where ClusterODX's administrative web interface is hosted).
 
 Then tunnel port 3000 for task assignment: