Runners

In this chapter we explain how to configure local and remote runners.

On the local computer, the only external requirement to run simulations is to install SIESTA. If you are a SIESTA expert, you can build it from source and point ASAP to it. If not, you can use our embedded installer, which will fetch a pre-compiled SIESTA executable for you, as described below.

To be able to run simulations with ASAP on remote servers, you have to make sure that the remote environments fulfil a few requirements. In section Preparing a remote server before the first simulation, we give you minimal instructions to configure computational resources. You can find detailed instructions on how to configure remote servers in Appendix  Preparing a remote server before the first simulation.

We have implemented a configuration widget for runners to manage local and remote computational resources easily. See section Managing local and remote runners.

Preparing run environments

Installing SIESTA on the local computer

You can download a SIESTA binary through the “Help / Download Siesta…” menu in ASAP. Please note that only a limited number of operating systems, namely Windows, Debian, Linux Mint, Ubuntu and MacOS/Darwin are supported.

Once the download widget appears, you can select the operating system and the SIESTA version to install. By default, it will download a serial binary of SIESTA 4.0 for Windows. When clicking the Install and configure button, the download will start. If the operation takes too much time or gets stalled, you can cancel it by clicking the Cancel button. See section Managing local and remote runners for further information on runner configuration.

You can download more than one version of SIESTA. They will be stored on your hard disk with different and explicit names. In any case, we recommend you to download both the serial and MPI versions of the SIESTA binary that best corresponds to your operating system and your needs.

Should you encounter any problem with the downloaded binary, please contact us at info@simuneatomistics.com.

Preparing a remote server before the first simulation

NOTE: The following steps have to be done only once on each remote server and are not necessary for local simulations.

Please refer to section Preparing a remote server before the first simulation.

Managing local and remote runners

Configuring runners is how ASAP becomes aware of how to use the available computational resources. Runners can be seen as pre-set configurations that can be saved and used to run simulations either on your local machine or on a remote server. They consist in the combination of a remote server, a calculator executable, and an execution mode. When run locally, the calculator is always executed directly by ASAP, while on remote machines it can be executed either directly or through a batch scheduler.

Before launching a new simulation, you will be able to select any of the saved runners to use the resources at your disposal. To do that, click on the button shown in Configure runner button. It will open the configuration runners widget, as shown in Configuration runner widget..

Fig. 21 Main windows view. The button to access configuration runners widget is highlighted.

Fig. 22 Configuration runner widget.

The configuration runners widget offers the following options:

• New remote…. Button to access the remote configuration widget. It contains a form that will let you configure the remote connections to clusters/servers for remote computing. See subsection Adding a remote machine.

• New program…. To configure an executable on the remote server. See subsection :ref`subsec-adding-new-program`.

• Edit…. To edit a previously configured remote machine.

• Delete. To delete a previously configured remote connection.

• Copy. To copy a previously created remote configuration.

Adding a remote machine

Click on the New remote… button to access the remote configuration widget. It contains a form that will let you configure the remote connections to clusters/servers for remote computing, as illustrated in Fig. 23.

Fig. 23 Remote configuration widget. You can set up your remote machine here.

The first four fields define the required parameters to establish the connection to a remote server/cluster.

• Name: Name of the remote connection, up to the user preferences.

• Hostname: IP address of the remote server.

• Username: Username of the user in the remote server.

• Port: To adjust the network port used to connect through SSH. At present, this field must be non-empty.

• Timeout: To setup the network timeout. At present, this field must be non-empty.

• Required password at connection time: If checked the user is required to input the remote server password in order to connect.

• Python: Tells ASAP where to find the python interpreter.

• Remote RC command: Tell ASAP how to set the remote environment appropriately before running simulations. Please follow the recommendations described in section Install Python package on the remote server.

• Remote workspace: Workspace to use for the simulations on the remote server. If no absolute path is given, the remote workspace will be considered relative to the remote user home directory.

Finally it is possible to run a check to test the connection to the server with the selected python environment, by clicking on the Check this configuration button.

Adding a program

Click on the New program… button to configure an executable on the remote server.

Fig. 24 Widget to configure the runner on the local or on a remote machine.

Here we list the options of the Program widget:

• Name: Name of the program.

• Executable: Executable program path on the local or remote machine.

• Program Type: Two drop-down menus that allow you to select the program and its version. There are three available options: SIESTA, TranSIESTA and TBtrans (see Fig. 25).

• MPI executable: MPI executable path on the local or remote machine.

• … options: Use this field to include any additional commands not mentioned above but supported by the selected batch scheduler vendor.

• Recomm. num. procs.: Default number of processors suggested by ASAP for this program.

• Test program: Click this button to test the program.

Select New/Edit queue to open the Batch Scheduler Configuration widget.

Fig. 25 Batch Scheduler Configuration Widget

It contains a form that will allow you configure the Batch Scheduler parameters.

The Batch Scheduler Configuration widget offers the option to tune the batch schedule vendor. ASAP supports Portable Batch System and Torque (PBS/TORQUE), Slurm Workload Manager (SLURM) and IBM Spectrum (LSF).

You can use fixed queue parameters. In this case ASAP provides the script to submit the job based on the chosen Batch scheduler vendor.

The Batch Scheduler Configuration widget offers the following options:

• Configuration label: The name of Batch Scheduler Configuration.

• Job name prefix: A word, letter or number to be placed before the identification number of the job. You can edit this prefix at your convenience.

• Number of nodes: The number of nodes in a job.

• Number of processors per node: How many processors are reserved for each node.

• Batch queue: Queue name.

• Maximum memory: Maximum required memory for the job.

• Maximum CPU time: Maximum CPU time per node.

• Maximum walltime: Maximum number of hours you want to run your job.

• Notification email: User email specification.

Alternatively, you can use the user’s queue script. This way you will be able to fully customize script to submit the job.

Troubleshooting

Activate ASAP Python enviroment in the user’s queue script

In some cases, depending on the cluster environment, the calculation starts running and it stops a few seconds after. In such cases, it might be necessary to add the command to activate the environment (see Remote RC command, Adding a remote machine) at the end of the user’s queue script (see Adding a program).