Public install at GA (DIII-D)

The supported server for executing OMFIT at GA is the omega cluster, which uses UNIX modules to administer software. Note that one must connect to somega to get the shared omega nodes (or use SLURM) to run OMFIT. You should not launch OMFIT on the login nodes of omega.

To load the stable or unstable versions users can do:

> module purge                  # purge existing modules (some OMFIT environments conflict with default Python environment)

# do one of the following
> module load omfit             # to load the OMFIT stable version - recommended (if not developing or instructed otherwise)
> module load omfit/unstable    # to load the OMFIT unstable version - leading edge

> omfit                         # start OMFIT (notice that the stable/unstable version depends on the loaded module)

Tip

New users might want to take a look at the Run section.

Scratch areas on omega

It is very important that you understand the policies for the scratch areas of omega, as given under the heading “Scratch areas” of http://mkdocs.gat.com/Omega/#scratch-areas. In particular, when OMFIT imports a module, it makes a copy of the files of the module in a subdirectory of the environmental variable OMFIT_TMPDIR, which on omega is /local-scratch. These files will be deleted after 32 days, even if the OMFIT session is active, and their absence causes OMFIT to not be able to save the current session to a project. If you know that you will have a session open for a very long time, then you could try setting OMFIT_TMPDIR to something else, but it is likely to cause other problems, and so it is just better to be aware of this time limit, and be sure to save your sessions at least daily. Also, there is a limited amount of space on the /local-scratch drives, which is sufficient for most workflows, but not SOLPS and GATO workflows, where setting OMFIT_TMPDIR to /cluster-scratch is more appropriate for its larger disk space.

For a detailed explanation of how OMFIT manages temporary files, how session directories are cleaned up, and how to use external references to reduce scratch usage, see OMFIT temporary files and disk usage.

Using OMFIT on the worker nodes

The omega cluster has two types of nodes: login nodes and worker nodes. When you ssh omega, there is an algorithm to put you on the least loaded omega login node, which will be omega-a or omega-b. You cannot launch OMFIT on the regular login nodes. When you ssh somega (which you should directly from cybele or your own system and not go through the login nodes), there is an algorithm to put you on the least loaded shared omega node (omega14-omega17). Instead of using the default launcher on somega, it is possible to start OMFIT on a worker node (omega03 to omega..) by the following methodology requiring two separate simultaneous terminal sessions:

# TERMINAL 1:
srun -p medium --ntasks-per-node=1 --pty /bin/bash
echo $SLURM_NODELIST

# TERMINAL 2 on an omega login node:
ssh -X HOST_FROM_TERMINAL_1
module load omfit
omfit

The medium partition allows a maximum time of 1 day. Other partitions are short (30 mins), or long (7 days). More details about running on omega can be found at http://mkdocs.gat.com/Omega/Software_On_Omega/Slurm/

Remote connection to GA workstations

If you are outside of the GA network you will need to go through the cybele firewall which accepts incoming connections on the port 2039.

The firewall also accepts NoMachine connections (make sure to use the SSH login, otherwise it will not work). This is the best way to run OMFIT on the GA workstations.

From Windows you can also use mobaxterm (X11 server + ssh client) to run graphical applications on a Unix server. This will however perform significantly worse than NoMachine.

Guest wifi at GA blocks access to GitHub

This issue can be circumvented by accessing git using ssh over the https port. Edit ~/.ssh/config and add:

Host github.com
Hostname ssh.github.com
Port 443

Contacts

In case of problems please contact Sterling Smith or Torrin Bechtel Amara.