Thus users can prepare for the Louhi OS update by porting and testing their codes on Tahko.
For further details see Louhi User's Guide (under construction).
Logging in to Tahko
Tahko can be accessed only from local CSC computers. To log in, connect any of the CSC servers (louhi, murska, corona, or sepeli) , and use ssh to connect Tahko.
Compiling programs
cc -o myprog myprog.cDifferent compilers can be used by loading the required module, e.g.
ftn -o myprog myprog.f90
module load PrgEnv-pgi
For further information see Louhi User's Guide (under construction).
Working directories
Though login-node sees the common disk server, the compute nodes can only access the local disk space. Therefore all the executables and the other necessary files must be copied to local disks. Each user has a local working directory set in $WRKDIR environment variable:
cd $WRKDIR
make necessary subdirectories (if needed), and copy the executables and the other necessary files there.
Running applications
Tahko is restricted to porting and testing. Thus only short runs are permitted so that everybody can run his or her code within a reasonable amount of time.
CLE uses aprun command to run applications.
Interactive:
Using 4 processors:aprun -n 4 ./myprog
Most common options:
| -d depth | Specifies the number of threads (depth) per processing element (PE). Default is 1. Each node must have at least depth cores. |
| -n pes | Specifies the number of prosessing elements (PE). Default is 1. The number of processors allocated for the application is number of threads times number of processing elements, i.e. depth*pes. |
| -N pes-per-node | Specifies number of processing elements per node. Each node must have at least pes-per-node cores. Default is the actual number of cores per node. |
NOTE: Since Tahko has single core processors, options -d and -N are currently irrelevant.
Batch jobs
Submitting jobs to batch system:
qsub myjob.sh
See also the Batch file example and qsub resources.
Currently available queues are test and parallel. From latter one jobs are further sent to queues small and large.
Output will be printed into file myjob.sh.oXXX (stdout) and myjob.sh.eXXX (stderr).
XXX is the job id.
Status of running jobs
qstat
qstat -a (all jobs, same as above)
qstat -u nnn (all jobs of user(s) nnn)
Deleting a job
qdel job_id
job_id stands for the job id number, as seen in qstat list