Home :: Academic Members :: News

view:21772   Last Update: 2020-2-2

Moladad Nikbakht

HPC Physics

كلاستر محاسباتي گروه فيزيك


مشخصات


Cluster pop-os runs single node operating system which is based on Ubuntu 18.01.

The cluster contains a compute node with following specifications:

       enlightened  Intel(R) Xeon(R) CPU E5-2699 v4 (processors: 44, cpu cores: 22,cache size:56320 KB)

       enlightened  64GB memory

       enlightened  VGA compatible controller: NVIDIA Corporation GP104GL Quadro P5000 (ram 16GB GDDR5, cudacore:2560)


کامپایلرها و نرم افزار های نصب شده بر روی کلاستر

 

      enlightened   C++

      enlightened   FORTRAN

      enlightened   Intel compiler (icc)

      enlightened   Parallel programming

                   --- Openmp

                   --- MPI

      enlightened   GPU based programs

                  --- opencl

                  --- cuda

      enlightened   XMDS

      enlightened   LAMMPS

نصب هر گونه نرم افزار منوط به امکان نصب آن نرم افزار در کلاستر تحت لینوکس و درخواست همکاران گرامی در هنگام دریافت اکانت است


سیستم صف

به منظور استفاده بهینه از کلاستر، سیستم صف مبتنی بر slurm در این کلاستر پیاده شده است.

در این کلاستر کاربران میبایست برنامه (job) خود را از طریق دستورات تعریف شده در slurm به کلاستر ارسال (sbatch or srun ) نمایند. امکان روئیت وضعیت برنامه، تخصیص منابع، ارسال ایمیل وضعیت برنامه و .... تحت slurm فراهم شده است. کاربران پس از دریافت حساب کاربری (user) میتوانند با استفاده از پروتکل ssh به کلاستر با آدرس (172.18.32.12@<user>) متصل شده و job خود را submit نمایند.   

Cluster pop-os manages resources using Simple Linux Utility for Resource Management (SLURM). Slurm is a highly scalable cluster management and job scheduling system for large and small Linux clusters.

for more information see: http://slurm.schedmd.com



ليست پارتيشن هاي تعريف شده در كلاستر

کاربران job خود را تحت پارتیشن تعریف شده برای آنها می توانند ارسال نمایند

دیگر موارد رم اختصاصی هسته اختصاصی زمان اختصاصی اولویت محدودیت Node پارتیشن
  10% 1 هسته 1 ساعت 1 ندارد pop-os phys-all
  30% 8 هسته 6 روز 3 دانشجویان pop-os phys-student
  40% 10هسته 6ساعت 2 اساتید pop-os phys-academic
با هماهنگی 50% 15 هسته 3 ساعت 4 ندارد pop-os phys-large-job

 

 

 

 

 

کاربران می توانند با استفاده از دستور sinfo به اطلاعات وضعیت کلاستر و با دستور scontrol show partition به محدودیتهای اعمال شده روی پارتیشن ها دسترسی یابند.

  • قبل از انتخاب پارتیشن؛ از محدودیت های آن پارتیشن و idle بودن وضعیت آن پارتیشن اطمینان حاصل نمایید.
  • هر اکانت اجازه ارسال یک job به خوشه را دارد.
  • متناسب با ترافیک موجود در کلاستر، ممکن است برخی پارتیشن ها در حالت خاموش قرار گیرند.
  • شایان ذکر است که به علت محدودیت های موجود؛ jobهای ارسال شده بر روی پارتیشن phys-large-job ؛چنانچه بیش از ۳ job کد در سیستم در حال اجرا باشد به حالت PENDING خواهد رفت.

حساب کاربری و محدودیت منابع برای کاربران

  • متقاضیان دریافت حساب کاربری (اساتید  و دانشجویان محترم) بایستی به صورت حضوری مراجعه نموده و فرم درخواست حساب کاربری را تکمیل و تحویل مسول پشتیبانی کلاستر نمایند.
  • هر کابر صرفا مجاز به استفاده از حساب کاربری خود می باشد. در صورت مشاهده تخلف، حساب مورد استفاده مسدود خواهد شد.
  • برای هر یک از همکاران عزیز، اکانت (account) تعریف شده و حساب کاربری دانشجویان تحت اکانت استاد راهنمای مربوطه خواهد بود.
  • حساب کاربری دانشجویان کارشناسی ارشد یک ساله و دانشجویان دکتری 3 ساله می باشد.
  • محدودیت استفاده از منابع  به هر account متناسب با CPU و زمان استفاده شده مطابق زیر اعمال خواهد شد.

The GrpCPURunMins is used to manage job for users
What is GrpCPURunMins (or whatever your scheduler calls it)?
It is a limit on the remaining cputime per account or user. You can think of remaining cputime as sum (job_core_count*job_remaining_time) for all of a user's or account's jobs.
If an account has 10 jobs that each use 2 cores and each have 24 hours remaining, the remaining cputime is 10 * 2 cores * 24 hours = 480 cpuhours = 28800 cpuminutes. As the jobs continue to run, the remaining cputime will decrease because the 24 hours in the equation will decrease.
Once a user/account reaches this limit, no more jobs are allowed to start for that association.

میزان cpu*time(minute) همکاران محترم (و دانشجویان مربوطه) در طول یک سال مطابق با جدول زیر می باشد. به عبارتی cputime=100800 معادل استفاده از 7 cpu  به مدت 10روز متوالی است: 7*24*10*60 یا معادل 70 روز استفاده مداوم از یک هسته است 1*24*70*60

دکتر داداشی:216231 دکتر قنبری: 301799 دکتر نجاری: 216231 دکتر عابدینی: 345739 دکتر درودی: 216231
دکتر حسینی: 216231 دکتر بیات: 216231 دکتر اسعدی: 216231 دکتر نصیری: 388253 دکتر نیکبخت: 1592253
دکتر محمدخانی: 216231 دکتر بلباسی: 476403 دکتر خوئینی: 1001373 دکتر معصومی: 216231 دکتر بیگدلی:561971
دکتر رحمت: 216231 دکتر رسولی: 216231 دکتر محمودی: 474603 دکتر یمانی: 216231 دکتر فولادوند: 216231
دکتر درونه:1610753 دکتر داوودی: 474603 دکتر ملکی: 216231 دکتر صفری: 1081159 دکتر بازرگان: 216231

نحوه ارسال job به کلاستر و دستورات مورد نیاز

The Slurm job scheduler

This guide describes basic job submission and monitoring for Slurm, Slurm job scheduler and its use on the pop-os system.
Jobs on pop-os are run as batch jobs, i.e. in an unattended manner. Typically a user logs in to the pop-os
login nodes (<user>@172.18.32.12), prepares a job (which contains details of the work to carry out and the computer resources needed) and submits it to the job queue. The user can then log out (if she/he wishes) until their job has run, to collect the output data.
Jobs are managed by Slurm, which is in charge of
• allocating the computer resources requested for the job,
• running the job and
• reporting the outcome of the execution back to the user.

Running a job involves, at the minimum, the following steps
• preparing a submission script and
• submitting the job to execution.


 Preparing a submission script

چنانچه از دستور sbatch برای ارسال job به کلاستر استفاده شود بایستی فایل batch file (به عنوان نمونه submit.sh) مطابق توضیحات زیر آماده و به کلاستر ارسال گردد.

A submission script is a shell script that describes the processing to carry out (e.g. the application, its input and output, etc.) and requests computer resources (number of cpus, amount of memory, etc.) to use for processing.

Example 1: a job by strudent (user=neda) running a single cpu job
Supposing the test.cpp is a c++ code which uses g++ compiler and requires 1 cpu for 30 minutes.
In this case the job requires a single cpu (this is the smallest unit we allocate on pop-os), So the user can use partition=phys-all with the following requirements:
• the job uses pop-os node,
• the application is a single process,
• the job will run for no more than 1 hours,
• the job is given the arbitrary name e.g :"test1" and
• the user should be emailed when the job starts and stops or aborts.

the following submission script runs the application in a single job

#!/bin/bash
#SBATCH -p phys-all                             <--------------------------set partition
#SBATCH --time=00:30:00                     <--------------------------set wallclocktime (arbitrary)
#SBATCH --error=job.%J.err                   <--------------------------set output file for error (arbitrary)
#SBATCH --output=job.%J.out                <--------------------------set output file (arbitrary)
#SBATCH --job-name="test1"                 <--------------------------set a name for the job
#SBATCH --mail-type=ALL                     <--------------------------set the massage status form (arbitrary)
#SBATCH --mail-user=????@znu.ac.ir  <--------------------------set the email for job status messaging (arbitrary)
g++ test.cpp -o myfirstcode
./myfirstcode

Example 2: a job by strudent (user=neda) running a multi-cpu job
Supposing the test.cpp is an openmp parallel code in c++ which uses g++ compiler and lapack library and requires 6 cpu for 2 days.
In this case the job requires a multui-cpu, and since the user is student, he/she should use partition=phys-student with the following requirements:
• the job uses pop-os node,
• the application is a multi process,
• the job will run for no more than 72 hours,
• the job is given the arbitrary name e.g :"test2" and
• the user should be emailed when the job starts and stops or aborts.

the following submission script runs the application in a single job

#!/bin/bash
#SBATCH -p phys-student  <--------------------------set partition
#SBATCH --ntasks=1  <--------------------------set number of nodes
#SBATCH --cpus-per-task=6  <--------------------------set number of cpupernode 
#SBATCH --time=2-00:00:00  <--------------------------set wallclocktime (arbitrary)
#SBATCH --error=job.%J.err  <--------------------------set output file for error (arbitrary)
#SBATCH --output=job.%J.out  <--------------------------set output file (arbitrary)
#SBATCH --job-name="test2"  <--------------------------set a name for the job
#SBATCH --mail-type=ALL <--------------------------set the massage status form (arbitrary)
#SBATCH --mail-user=????@znu.ac.ir  <--------------------------set the email for job status messaging (arbitrary)
export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK  <--------------------------set number of cpu by slurm protocol
g++ -Ofast  test.cpp -llapacke -llapack  -fopenmp -o mysecondcode
./mysecondcode

In large part, the script above is similar to the one for a single node job except in this example, #SBATCH --cpu-per-task=m is used to reserve m cores per node (here on a single node e.g. --ntasks=1) and to prepare the environment for a openmp parallel run with m processes in pop-os node.

Example 3: a job by strudent (user=neda) running a gpu job
Supposing the test.cu is a cuda code which uses nvcc compiler and requires gpu and 1 cpu.
In this case the job requires a gpu, and since the user is student, he/she should use partition=phys-gpu with the following requirements:
• the job uses pop-os node,
• the application is a multi process,
• the job will run for no more than 24 hours,
• the job is given the arbitrary name e.g :"test2" and
• the user should be emailed when the job starts and stops or aborts.

the following submission script runs the application in a single job

#!/bin/bash
#SBATCH -p phys-gpu  <--------------------------set partition
#SBATCH --time=00:03:00  <--------------------------set wallclocktime (arbitrary)
#SBATCH --error=job.%J.err  <--------------------------set output file for error (arbitrary)
#SBATCH --output=job.%J.out  <--------------------------set output file (arbitrary)
#SBATCH --job-name="test3"  <--------------------------set a name for the job
#SBATCH --mail-type=ALL <--------------------------set the massage status form (arbitrary)
#SBATCH --mail-user=????@znu.ac.ir  <--------------------------set the email for job status messaging (arbitrary)
nvcc  test.cu  -o mythird
./mythird

NOTE:

enlightened phys-all is the default partition and the one your jobs will go to if you do not specify a partition in your job submission script.

indecision Users can also use phys-large-job partition if their job requires  larger resorces (Time, Cpu, Mem). Attention: this partition has a minimum priority, and the job will be PREEMPTED by submited jobs from other partitions (go to pending status).

surprise Setting a wall clock time means you are setting the time limit of the job, which influence the priority of your job. Do not set the wall clock time (i.e. --time=???) if you are sure that the running time is smaller than the wall clock time of the specified partition. A larger wall clock time==smaler priority. It is best to give this up to the maximum time allowed at first to get an idea of how long it runs.  After you know that, it is best to give it a more reasonable time limit.  Setting a reasonable timelimit will increase your chance of running quickly based on the backfill algorithm used.

surprise If the wall clock time exceeds the wall clock time of the specified partition, the job will be killed automatically. 

surprise If the running time exceeds the wall clock time limit of the specified partition or demanded time, the job will exit.

enlightened The notification massage (email notification) is actived only for partition=phys-large-job. So you can ignore setting these parts

enlightened The GPU partition is hidden and has maximum prioroty. (contact admin bifore using phys-gpu partition)


ارسال job به کلاستر توسط دستور sbatch

Once you have a submission script ready (e.g submit.sh), the job is submitted to the execution queue with the command sbatch script.sh. The queueing system prints a number (the job id) almost immediately and returns control to the linux prompt. At this point the job is in the submission queue. Once you have submitted the job, it will sit in a pending state until the resources have been allocated to your job (the length of time your job is in the pending state is dependent upon a number of factors including how busy the system is and what resources you are requesting). You can monitor the progress of the job using the command squeue (see below).

Once the job starts to run you will see files with names such as job-12.out either in the directory you submitted the job from (default behaviour) or in the directory where the script was instructed explicitly to change to.


مشاهده وضعیت job با دستور squeue

squeue is the main command for monitoring the state of systems, groups of jobs or individual jobs. The command squeue prints the list of current jobs. The list looks something like this:

NODELIST(REASON) NODES        TIME        ST        USER        NAME        PARTITION        JOBID       
pop-os 1 10:07 R ghanbari heat phys-academic 2491
pop-os 1 0:22 R neda test1 phys-all 2499
pop-os (Resources) 1 15:36 PD alireza test2 phys-student 2511


The first column gives the job ID, the second the partition (or queue) where the job was submitted, the third the name of the job (specified by the user in the submission script) and the fourth the owner of the job. The fifth is the status of the job (R=running, PD=pending, CA=cancelled, CF=configuring, CG=completing, CD=completed, F=failed). The sixth column gives the elapsed time for each particular
job.


Slurm Job States

Your job will report different states before, during, and after execution. The most common ones are seen below, but this is not an exhaustive list.

Job was killed, either by the user who submitted it, a system administrator, or by the Cgroups plugin (for using more resources than requested). CA CANCELLED
Job has ended in a zero exit status, and all processes from the job are no longer running. CD COMPLETED
This status differs from COMPLETED because some processes may still be running from this job. CG COMPLETING
Job did not complete successfully, and ended in a non-zero exit status. F FAILED
The node or nodes that the job was running on had a problem. N NODE_FAIL
Job is queued, so it is not yet running. Look at the Jobs that never start section for details on why jobs can remain in pending state. PD PENDING
Job has been allocated resources, and is currently running. R RUNNING
Job exited because it reached its walltime limit. TO TIMEOUT

 

 

 

 

 

 

 

 

 

 

 

نکته: روی تعداد job های ارسالی کاربران به کلاستر محدودیت اعمال شده است. پس از ارسال هر job حتما از دستور squeue وضعیت آن را چک کنید و در صورت قرار داشتن در وضعیتی به جز R از ارسال job جدید خودداری کنید و به دنبال آن باشید که چرا job  شما در وضعیت R قرار ندارد.


کنسل کردن job ارسال شده به کلاستر

Use the scancel command to delete a job, e.g. scancel 1121 to delete job with ID 1121. A user can delete his/her own jobs at any time, whether the job is pending (waiting in the queue) or running. A user cannot delete the jobs of another user. Normally, there is a (small) delay between the execution of 10 the scancel command and the time when the job is dequeued and killed.


توجه: چنانچه کاربری اقدام به اجرای برنامه به صورت مستقیم بر روی کلاستر نماید، حساب کاربری مربوطه مسدود خواهد شد

کاربران گرامی سعی نمایند تا از نگهداری حجم بالای اطلاعات در کلاستر خودداری نمایند. علاوه بر این پیشنهاد می شود تا به صورت دوره ای نسخه پشتیبانی از داده های خود از روی کلاستر تهیه نمایند تا در صورت بروز ایراد در کلاستر با مشکل مواجه نشوند.


 

پشتیبانی کامپیوتر محاسباتی گروه فیزیک دانشگاه زنجان

دکتر مولاداد نیکبخت

ایمیل: hpc_physics[at]znu.ac.ir

 

 

 

Copyright © 2020, University of Zanjan, Zanjan, Iran
master[at]znu.ac.ir