Research Computing Center Wiki - Recent changes [en]

Using a Conda environment in Jupyter

Shtsai — Tue, 11 Aug 2026 20:20:00 GMT

Open Jupyter in Open OnDemand

← Older revision		Revision as of 16:20, 11 August 2026
(One intermediate revision by the same user not shown)
Line 4:		Line 4:

	== Open OnDemand ==		== Open OnDemand ==
	Open OnDemand is a web-based service that allows users to run software with a graphical user interface (GUI) such as Jupyter Notebook. Please see our ~~Open OnDemand~~ [[OnDemand\|wiki page]] to learn more.		Open OnDemand is a web-based service that allows users to run software with a graphical user interface (GUI) such as Jupyter Notebook. Please see our [[OnDemand\|Open OnDemand wiki page]] to learn more.

	== Using a Conda environment in Jupyter ==		== Using a Conda environment in Jupyter ==
Line 21:		Line 21:

	=== Open Jupyter in Open OnDemand ===		=== Open Jupyter in Open OnDemand ===
	Click on the Jupyter app in [https://ondemand.gacrc.uga.edu/ Open OnDemand] and choose your desired resources. Please ensure that you choose the Miniforge3 version of Jupyter.		Click on the Jupyter app in [https://ondemand.gacrc.uga.edu/ Open OnDemand access URL] and choose your desired resources. Please ensure that you choose the Miniforge3 version of Jupyter.

	Click launch at the bottom of the page to start a Jupyter Notebook session. You will be redirected to "My Interactive Sessions" where you can wait for the job to be allocated resources.<br>		Click launch at the bottom of the page to start a Jupyter Notebook session. You will be redirected to "My Interactive Sessions" where you can wait for the job to be allocated resources.<br>

Training

Moses — Tue, 11 Aug 2026 15:31:56 GMT

← Older revision		Revision as of 11:31, 11 August 2026
Line 112:		Line 112:
	\|September 14th, Monday, 1:00 PM - 3:00 PM		\|September 14th, Monday, 1:00 PM - 3:00 PM
	\|-		\|-
	\|v		\|Use Linux on Cluster
	\|September 22nd, Tuesday, 1:00 PM - 3:00 PM		\|September 22nd, Tuesday, 1:00 PM - 3:00 PM
	\|}		\|}

Training

Chelsea — Tue, 11 Aug 2026 13:47:57 GMT

Linux Training for Linux-inexperienced Cluster New Users

← Older revision		Revision as of 09:47, 11 August 2026
(One intermediate revision by the same user not shown)
Line 10:		Line 10:


	In '''~~August~~ 2026''', the GACRC is hosting 6 training sessions listed below. These training workshops will be offered remotely via Zoom Meeting. Detailed instructions for joining the Zoom meeting will be sent to your UGA email account before each training session you register for.		In '''September 2026''', the GACRC is hosting 9 training sessions listed below. These training workshops will be offered remotely via Zoom Meeting. Detailed instructions for joining the Zoom meeting will be sent to your UGA email account before each training session you register for.

	We will offer:		We will offer:
Line 17:		Line 17:

	2. Sapelo2 cluster new user training (3 sessions)		2. Sapelo2 cluster new user training (3 sessions)

			3. Using Sapelo2 Cluster at the GACRC, Part II (1 session)

			4. Installing Software Packages in Virtual Environments on Sapelo2 (1 session)

			5. Job Parallelization with GNU Parallel and Slurm Arrays (1 session)

	==Event Schedule==		==Event Schedule==
Line 56:		Line 62:
	\|-		\|-
	\|Using Sapelo2 Cluster at the GACRC		\|Using Sapelo2 Cluster at the GACRC
	\|~~July 16th~~, Thursday~~, 2:00 PM - 4:00 PM~~		\|August 20th, Thursday, 2:00 PM - 4:00 PM
	\|-
	~~\|Using Sapelo2 Cluster at the GACRC~~
	~~\|July 22nd, Wednesday~~, 2:00 PM - 4:00 PM
	\|-		\|-
	\|Using Sapelo2 Cluster at the GACRC		\|Using Sapelo2 Cluster at the GACRC
	\|~~August 7th~~, Friday, 2:00 PM - 4:00 PM		\|September 11th, Friday, 2:00 PM - 4:00 PM
	\|-		\|-
	\|Using Sapelo2 Cluster at the GACRC		\|Using Sapelo2 Cluster at the GACRC
	\|~~August 12th~~, Wednesday, 2:00 PM - 4:00 PM		\|September 16th, Wednesday, 2:00 PM - 4:00 PM
	\|-		\|-
	\|Using Sapelo2 Cluster at the GACRC		\|Using Sapelo2 Cluster at the GACRC
	\|~~August 20th~~, Thursday, 2:00 PM - 4:00 PM		\|September 24th, Thursday, 2:00 PM - 4:00 PM
	\|}		\|}

Line 101:		Line 104:
	\|-		\|-
	\|Use Linux on Cluster		\|Use Linux on Cluster
	\|~~July 14th~~, Tuesday, 1:00 PM - 3:00 PM		\|August 18th, Tuesday, 1:00 PM - 3:00 PM
	\|-		\|-
	\|Use Linux on Cluster		\|Use Linux on Cluster
	\|~~July 20th~~, ~~Monday~~, 1:00 PM - 3:00 PM		\|September 9th, Wednesday, 1:00 PM - 3:00 PM
	\|-		\|-
	\|Use Linux on Cluster		\|Use Linux on Cluster
	\|~~August 5th~~, ~~Wednesday~~, 1:00 PM - 3:00 PM		\|September 14th, Monday, 1:00 PM - 3:00 PM
	\|-		\|-
	\|~~Use Linux on Cluster~~		\|v
	\|~~August 10th, Monday, 1:00 PM - 3:00 PM~~		\|September 22nd, Tuesday, 1:00 PM - 3:00 PM
	\|-
	~~\|Use Linux on Cluster~~
	~~\|August 18th~~, Tuesday, 1:00 PM - 3:00 PM
	\|}		\|}

Line 144:		Line 144:
	\|-		\|-
	\|Using Sapelo2 Cluster at the GACRC, Part II		\|Using Sapelo2 Cluster at the GACRC, Part II
	\|		\|September 18th, Friday, 1:00 PM - 3:00 PM
	\|}		\|}

Line 171:		Line 171:
	\|-		\|-
	\|Installing Software Packages in Virtual Environments on Sapelo2		\|Installing Software Packages in Virtual Environments on Sapelo2
	\|		\|September 23rd, Wednesday, 2:00 PM - 2:45 PM
	\|}		\|}

Line 198:		Line 198:
	\|-		\|-
	\|Job Parallelization with GNU Parallel and Slurm Arrays		\|Job Parallelization with GNU Parallel and Slurm Arrays
	\|		\|September 25th, Friday, 1:00 PM - 3:00 PM
	\|}		\|}

Line 564:		Line 564:
	\|Fall 2026		\|Fall 2026
	\|		\|
	\|[[:Media:~~GACRC Teaching Cluster Training~~-Python.pdf]]		\|[[Media:GACRC_Teaching_Cluster_Training-Python.pdf]]
	\|-		\|-
	\|Fall 2026		\|Fall 2026
	\|		\|
	\|[[:Media:~~GACRC Teaching Cluster Training~~-Amber.pdf]]		\|[[Media:GACRC_Teaching_Cluster_Training-Amber.pdf]]
	\|-		\|-
	\|GEOG - Spring2026 \|\| In-Class \|\| [[Media:GACRC-Teaching-cluster-new-user-training-workshop-python-Spring2026.pdf]]		\|GEOG - Spring2026 \|\| In-Class \|\| [[Media:GACRC-Teaching-cluster-new-user-training-workshop-python-Spring2026.pdf]]

Disk Storage

Shtsai — Tue, 11 Aug 2026 00:59:46 GMT

← Older revision		Revision as of 20:59, 10 August 2026
Line 269:		Line 269:
	== Current Storage Systems ==		== Current Storage Systems ==

			* Aeon hybrid Lustre appliance (2.4PB flash & 9.6PB spinning drives) - $SCRATCH & $WORK on Sapelo2

			* ZFS storage appliance (500TB) - $HOME on Sapelo2

			* ZFS storage appliance (8PB) - $PROJECT research groups' long-term space - only for active projects requiring Sapelo2 access

			* ZFS storage appliances (8PB) - backup & mirroring environments for $HOME and $PROJECT.

			<!--
	(1) ZFS storage chain (300TB) - $HOME on Sapelo2		(1) ZFS storage chain (300TB) - $HOME on Sapelo2

Line 278:		Line 287:

	(4) ZFS storage chains (2.4PB) - backup environment for $HOME and $PROJECT.		(4) ZFS storage chains (2.4PB) - backup environment for $HOME and $PROJECT.
			-->




	<!--		<!--

AlphaFold3-Sapelo2

Jordan — Fri, 07 Aug 2026 20:58:19 GMT

Running Program

← Older revision		Revision as of 16:58, 7 August 2026
(8 intermediate revisions by the same user not shown)
Line 8:		Line 8:

	== Version ==		== Version ==
	3.0.0, 3.0.1, 3.0.2, 3.0.3		3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4

	== Author / Distributor ==		== Author / Distributor ==
Line 32:		Line 32:
	</pre>		</pre>

	'''Version 3.0.1'''		*'''Version 3.0.1'''

	This version is installed as a singularity container:		This version is installed as a singularity container:
Line 46:		Line 46:
	singularity exec /apps/singularity-images/alphafold-3.0.1.sif python /app/alphafold/run_alphafold.py --helpfull		singularity exec /apps/singularity-images/alphafold-3.0.1.sif python /app/alphafold/run_alphafold.py --helpfull
	</pre>		</pre>
	~~Note that AlphaFold~~ 3 is GPU dependent while also being CPU and memory intensive, meaning that it will only run on the A100 and H100 nodes and needs numerous CPUs to run in a timely/efficient manner (see the example job submission script below). <b>Furthemore, the "unifiedmem" and "JSON-4" versions have unified memory enabled, which allows the GPU device to "borrow" host memory from the node for proteins and other complexes that are large enough to exceed the standard maximum of 5,120 tokens; not only does this substantially increase run times, it will also <i>only</i> work on the A100 nodes due to architectural conflicts with the H100 nodes. ~~To use either of these versions with~~ a large protein or other complex, please use the following Slurm header in your submission script in place of the corresponding "--gres" header seen in the sample job below (and note that you can remove the "#SBATCH --constraint" header for this):~~</b>~~
			*'''Version 3.0.2'''

			This version is installed as a singularity container:
	<pre class="gscript">		<pre class="gscript">
	...		/apps/singularity-images/alphafold-3.0.2.sif
	~~#SBATCH~~ --~~gres=gpu:A100:1~~		</pre>
	...		You can view the documentation for this version of AlphaFold with the following command, in an interactive job (i.e., NOT a login/submit node, where Singularity does not work):
			<pre class="gcommand">
			singularity exec /apps/singularity-images/alphafold-3.0.2.sif python /app/alphafold/run_alphafold.py --helpfull
	</pre>		</pre>

	~~Please also note that like many AI tools, AlphaFold~~ is ~~prone to~~ "~~hallucinations~~" ~~when dealing with inputs that are too large;~~ this ~~mostly manifests as results~~ with ~~polypeptides predicted to occupy~~ the ~~same 3D space~~, ~~which obviously makes these results useless~~. ~~While tests with~~ a ~~complex of up to ~9~~,~~700 tokens (the urease complex from~~ <i>~~Helicobacter pylori~~</i>~~) completed successfully, to date, the largest complex observed to run~~ <b>~~correctly~~</b> ~~was ~7~~,~~300 tokens~~ (~~the ornithine decarboxylase~~, ~~specifically <i>SpeF<~~/i>, ~~complex from~~ <i>~~Salmonella~~</i>).		*'''Version 3.0.3'''

			This version is installed as a singularity container:
			<pre class="gscript">
			/apps/singularity-images/alphafold-3.0.3.sif
			</pre>
			You can view the documentation for this version of AlphaFold with the following command, in an interactive job (i.e., NOT a login/submit node, where Singularity does not work):
			<pre class="gcommand">
			singularity exec /apps/singularity-images/alphafold-3.0.3.sif python /app/alphafold/run_alphafold.py --helpfull
			</pre>

			*'''Version 3.0.4'''

			This version is installed as a singularity container:
			<pre class="gscript">
			/apps/singularity-images/alphafold-3.0.4.sif
			</pre>
			You can view the documentation for this version of AlphaFold with the following command, in an interactive job (i.e., NOT a login/submit node, where Singularity does not work):
			<pre class="gcommand">
			singularity exec /apps/singularity-images/alphafold-3.0.4.sif python /app/alphafold/run_alphafold.py --helpfull
			</pre>
	</br>		</br>
	</br>		</br>
	AlphaFold 3 also depends on a set of database files, the current versions of which can be found at /db/AlphaFold3/20241114, and a file containing the model parameters; ~~currently~~ this is ~~only~~ available ~~directly from Google, and can be obtained by completing the form found here: https:~~//~~docs.google.com~~/~~forms~~/d/~~e/1FAIpQLSfWZAgo1aYk0O4MuAXZj8xRQ8DafeFJnldNOnh_13qAx2ceZw/viewform~~. ~~Once these are obtained~~ and ~~placed somewhere in your storage space on Sapelo2 (/home or /work is recommended), they~~ must be included with the '-B' or "--bind" option at runtime, as must the location of the input file and output directory (see example below).		Note that AlphaFold 3 is GPU dependent while also being CPU intensive unless you elect to provide your own multiple sequence alignments (MSAs) produced in a separate step beforehand. This means that, for most proteins, it will only run on the A100 and H100 nodes (it has been tested on the L4 nodes but only for fairly small proteins like the example input below) and needs numerous CPUs to run in a timely/efficient manner (see the example job submission script below). For especially large inputs (i.e., complexes that exceed the "standard" maximum of 5,120 tokens on the A100 and H100 nodes, all of which have 80GB of device memory per GPU device), unified memory has been enabled by default starting with alphafold-3.0.1-unifiedmem.sif and all subsequent versions. Unified memory allows the GPU device to "borrow" host memory from the node for proteins and other complexes that are larger than can be handled with the available device memory alone; however, there are some caveats and considerations:
			* For one, use of this "extra" memory is <b>extremely</b> slow, often increasing run times from several minutes to several hours; although this mode now works on both H100 and A100 nodes, H100 nodes seem to run faster in this mode than A100 nodes.
			* For another, host memory is the memory you request in your Slurm headers with "#SBATCH --mem=" so you need to make sure you're accounting for this when submitting a job for a large complex that's likely to need unified memory: for all unified memory-enabled containers for v3.0.1 and v3.0.2, the default is 3.2 times the amount of device memory per GPU, so 3.2 x 80GB = 256GB, while the containers for v3.0.3 and v3.0.4 have a default of 4.0 times the device memory, or 4.0 x 80GB = 320GB, and memory usage scales not only with input size but also number of sample and diffusion iterations; <b>also, be aware that v3.0.4 introduced several updated dependencies and appears to use significantly more memory than previous versions for the same inputs.</b>
			* While the above values are the default maximums, it's possible to adjust them at runtime: if you attempt to model a large complex and receive a "RESOURCE EXHAUSTED" error but <i>not</i> an "OOM killed" error, you can manually increase the amount of host memory that gets allocated to your AlphaFold command using the "--env XLA_CLIENT_MEM_FRACTION=X.Y" flag after the "--nv" flag (see example command below), where "X" and "Y" are integer values (e.g., "--env XLA_CLIENT_MEM_FRACTION=<b>5.0</b>").
			* Finally, please also note that like many AI tools, AlphaFold is prone to "hallucinations" when dealing with inputs that are too large; this mostly manifests as results with polypeptides predicted to occupy the same 3D space, which obviously makes these results useless; while tests with a complex of up to ~9,700 tokens (the urease complex from <i>Helicobacter pylori</i>) completed successfully, to date, the largest complex observed to run <b>correctly</b> was ~7,300 tokens (the ornithine decarboxylase, specifically <i>SpeF</i>, complex from <i>Salmonella</i>).

			</br>
			Note that AlphaFold 3 also depends on a set of database files, the current versions of which can be found at /db/AlphaFold3/20241114, and a file containing the model parameters; as of 08/06/2026, this is now available centrally at /db/AlphaFold3/model_parameters/20260604/af3.bin. Both the databases and the model parameters file must be included with the '-B' or "--bind" option at runtime, as must the location of the input file and output directory (see example below).

	Sample job submission script to run the singularity container for v3.0.0 on a GPU:		Sample job submission script to run the singularity container for v3.0.0 on a GPU:
Line 79:		Line 111:
	--bind /Path/to/input/file:/root/af_input \		--bind /Path/to/input/file:/root/af_input \
	--bind /Path/to/output_directory:/root/af_output \		--bind /Path/to/output_directory:/root/af_output \
	--bind /~~Path~~/to/model_parameters:/root/models \		--bind /db/AlphaFold3/model_parameters/20260604:/root/models \
	--bind /db/AlphaFold3/20241114:/root/public_databases \		--bind /db/AlphaFold3/20241114:/root/public_databases \
	/apps/singularity-images/alphafold-3.0.1-JSON-4.sif \		/apps/singularity-images/alphafold-3.0.1-JSON-4.sif \