Preparing the job
First you should prepare your system and set all parameters for the calculation in Materials Studio Visualizer. Then, instead of running the job on your desktop computer, press "files" (next to the "run" button). This will write all necessary files to run the job remotely in standalone mode on your hard disk. Before this make sure the job name is sensible - not too long, and without white spaces in it. This will be the "basename" of your files. The name can be changed in the left panel (project browser, by right clicking) in Visualizer. We now assume you changed it into
ms_basename
If you don't know where the files ended up, you can study this by right clicking one of the files in the project browser and choosing "properties". The next step is to transfer the files onto Vuori. The easiest way is to zip all files together, and copy them with scp to Vuori (your ssh-client might also have a file transfer functionality, or you could use the file manager in Scientist's User Interface). In Vuori, create a subdirectory for the calculation in your work-area ($WRKDIR) and copy the zip file there. A windows zip-file can be opened with the
unzip
command. The files are in dos-format. You may need to convert them into unix format. This is done with the command:
dos2unix ms_basename*
Note that some of the files (at least *.car) are "hidden" in Windows by default. This means that those files would not be included in the zip-file. These files are neither visible in the F-Secure file transfer window. If you do not see a file called ms_basename.car in the directory with the other files do the following:
1) Go to the folder where you have the files with windows explorer.
2) Select "tools" from the pull-down menus and there "folder options".
3) Now select the "view" leaf (or page), click "show hidden files" active, and create the zip-file again.
Now the input-files for DMol3 are ready and all we need is the script to submit the job for the queuing system.
Note also, that before you zip and copy back the result files to your Windows computer into the original project folder, you may need to convert the files back to dos-format (with unix2dos *)
Serial DMol3-job
#!/bin/bash
#SBATCH -J dmol-test
#SBATCH -e my_output_err_%j
#SBATCH -o my_output_%j
#SBATCH --mem-per-cpu=1000
#SBATCH -t 00:20:00
#SBATCH -p serial
MSBIN=/v/linux26_x86_64/appl/chem/accelrys/MS/latest/etc/DMol3/bin/RunDMol3.sh
BASENAME=CaSO4
$MSBIN $BASENAME
In the script you must replace the ms_basename with the "basename" of the files printed out by Materials Studio as described above. If there are a lot of jobs running on the machine, guessing the requested time well will shorten the time it takes for your job to get running. If you want to give additional input to the RunDMol3.sh script, you can get the help message by giving
/v/linux26_x86_64/appl/chem/accelrys/MS/latest/etc/DMol3/bin/RunDMol3.sh
Parallel DMol3 jobs
Example of a script file for running a parallel DMol3 that requests 12 cores and 12 hours and one minute of running time in Vuori:
#!/bin/bash
#SBATCH -J dmol3-example
#SBATCH -e my_output_err_%j
#SBATCH -o my_output_%j
#SBATCH --mem-per-cpu=1000
#SBATCH -t 12:01:00
#SBATCH -n 12
#SBATCH -p parallel
MSBIN=/v/linux26_x86_64/appl/chem/accelrys/MS/latest/etc/DMol3/bin/RunDMol3.sh
BASENAME=ms_basename
$MSBIN -np $SLURM_NPROCS $BASENAME
Note, that using 1-12 cores uses the "serial" queue and 12+ cores you need to use the "parallel" queue.
Submitting the job into the queuing system
Supposing that you have put a script like those above in a file called nobel.job,
it can be submitted with command
sbatch nobel.job
The job status can be displayed by command
squeue
A running or queuing job can be cancelled
scancel job_id
Calculating properties
The scripts above will run one job, such as a geometry or wavefunction optimization. If you have selected additional properties, such as NMR shielding constants, DOS or orbitals, you need to add these steps after the first calculation. The first calculation provides the optimised electronic structure, from which the properties can be calculated (one by one). The number of separate jobs can be seen from the number of BASENAMEs created from the GUI. The BASENAMEs have the same beginning added with a tail describing the properties it will generate, e.g. BASENAME_DOS or BASENAME_NMR.
The following example applies for a CASTEP job that will first optimize the geometry, then calculate the density of states and NMR shielding constants (you need the corresponding input files in the running directory).
#!/bin/bash
#SBATCH -J CASTEP-props
#SBATCH -e my_output_err_%j
#SBATCH -o my_output_%j
#SBATCH -t 12:01:00
#SBATCH -n 12
#SBATCH -p serial
MSBIN=/v/linux26_x86_64/appl/chem/accelrys/MS/latest/etc/CASTEP/bin/RunCASTEP.sh
BASENAME=ms_basename
$MSBIN -np $SLURM_NPROCS $BASENAME
BASENAME=ms_basename_DOS
$MSBIN -np $SLURM_NPROCS $BASENAME
BASENAME=ms_basename_NMR
$MSBIN -np $SLURM_NPROCS $BASENAME
Running other module jobs
Also some other Materials Studio modules can be run in standalone mode. All steps to accomplish this is as above for DMol3, but only running the jobs has a different command. For example, to run a CASTEP job you would need to replace the final lines in the job script to point to the following executables.
MSBIN=/v/linux26_x86_64/appl/chem/accelrys/MS/latest/etc/CASTEP/bin/RunCASTEP.sh
BASENAME=ms_basename
$MSBIN -np $SLURM_NPROCS $BASENAME
to run (a serial) Amorphous Cell you need instead:
/v/linux26_x86_64/appl/chem/accelrys/MS/latest/etc/AmorphousCell/bin/RunAmorphousCell.sh ms_basename
for Discover:
/v/linux26_x86_64/appl/chem/accelrys/MS/latest/etc/Discover/bin/RunDiscover.sh ms_basename
and for VAMP:
/v/linux26_x86_64/appl/chem/accelrys/MS/latest/etc/VAMP/bin/RunVAMP.sh ms_basename
Additional information
More information about the queuing system can be in the Vuori Guide or simply by
man sbatch
If you have further questions on running Materials Studio please contact helpdesk or Atte Sillanpää.