.TH sbatch "1" "Slurm Commands" "Slurm 26.05" "Slurm Commands"

.SH "نام (NAME)"
sbatch \- ارسال یک اسکریپت دسته‌ای به Slurm.

.SH "خلاصه دستور (SYNOPSIS)"
\fBsbatch\fR [\fIOPTIONS(0)\fR...] [ : [\fIOPTIONS(N)\fR...]] \fIscript(0)\fR [\fIargs(0)\fR...]

گزینه(ها) چندین کار را در یک کار ناهمگن زمان‌بندی‌شده به‌طور هم‌زمان تعریف می‌کنند.
برای جزئیات بیشتر درباره کارهای ناهمگن، سند زیر را ببینید:
.br
https://slurm.schedmd.com/heterogeneous_jobs.html

.SH "توضیحات (DESCRIPTION)"
دستور sbatch یک اسکریپت دسته‌ای (batch script) را به Slurm ارسال می‌کند. اسکریپت دسته‌ای می‌تواند از طریق نام فایل در خط فرمان به sbatch داده شود، یا اگر نام فایلی مشخص نشده باشد، sbatch اسکریپت را از ورودی استاندارد می‌خواند.

اسکریپت دسته‌ای ممکن است شامل یک یا چند خط باشد که با "#SBATCH" شروع شده و به دنبال آن هر یک از گزینه‌های خط فرمان که در این صفحه مستند شده‌اند قرار گیرند. دستورالعمل‌های #SBATCH مستقیماً توسط Slurm خوانده می‌شوند، بنابراین نحو مخصوص شل از جمله نام متغیرها به عنوان متن لفظی (literal) خوانده خواهد شد. هنگامی که به اولین خط غیرتوضیحی و غیرخالی در اسکریپت برسد، دیگر هیچ دستورالعمل #SBATCH پردازش نخواهد شد. مثال زیر را ببینید.

دستور sbatch بلافاصله پس از انتقال موفقیت‌آمیز اسکریپت به کنترلر Slurm و اختصاص یک شناسه کار (job ID) به آن، خارج می‌شود. لزوماً منابع به سرعت به اسکریپت دسته‌ای اختصاص داده نمی‌شوند؛ ممکن است پیش از اینکه منابع مورد نیازش در دسترس قرار گیرند، مدتی در صف کارهای معلق بماند.

به‌طور پیش‌فرض، هر دو خروجی استاندارد و خطای استاندارد به فایلی به نام "slurm\-%j.out" هدایت می‌شوند، که در آن "%j" با شماره تخصیص کار جایگزین می‌شود. این فایل روی اولین گرهِ تخصیص کار ایجاد خواهد شد. به غیر از خود اسکریپت دسته‌ای، Slurm هیچ‌گونه جابه‌جایی برای فایل‌های کاربر انجام نمی‌دهد.

هنگامی که تخصیص منابع برای کار دسته‌ای اعطا شد، Slurm یک نسخه منفرد از اسکریپت دسته‌ای را روی یکی از گره‌های تخصیص‌یافته اجرا می‌کند. میزبان دسته‌ای (batch host) معمولاً اولین گره در تخصیص است، اما به دلیل گزینه \fB\-\-batch\fR ممکن است در جای دیگری قرار گیرد.

سند زیر تأثیر گزینه‌های مختلف بر تخصیص پردازنده‌ها (CPUs) به کارها و وظایف را شرح می‌دهد:
.br
https://slurm.schedmd.com/cpu_management.html

.SH "مقدار بازگشتی (RETURN VALUE)"
دستور sbatch در صورت موفقیت مقدار 0 یا در صورت شکست کد خطا را برمی‌گرداند.

.SH "تفکیک مسیر اسکریپت (SCRIPT PATH RESOLUTION)"

مسیر اسکریپت دسته‌ای به ترتیب زیر تفکیک می‌شود:
.br

1. اگر اسکریپت با "." شروع شود، مسیر به این صورت ساخته می‌شود:
دایرکتوری کاری فعلی / script
.br
2. اگر اسکریپت با "/" شروع شود، مسیر مطلق در نظر گرفته می‌شود.
.br
3. اگر اسکریپت در دایرکتوری کاری جاری باشد.
.br
4. اگر اسکریپت از طریق PATH قابل تفکیک باشد. \fBpath_resolution\fR(7) را ببینید.
.br
.P
دایرکتوری کاری جاری همان دایرکتوری کاری فرایند فراخواننده است، مگر اینکه آرگومان \fB\-\-chdir\fR ارسال شده باشد، که دایرکتوری کاری جاری را بازنویسی خواهد کرد.

.SH "گزینه‌ها (OPTIONS)"
.LP

.TP
\fB\-A\fR, \fB\-\-account\fR=<\fIaccount\fR>
منابع استفاده‌شده توسط این کار را به حساب مشخص‌شده شارژ می‌کند.
\fIaccount\fR یک رشته دلخواه است. نام حساب می‌تواند پس از ارسال کار با استفاده از دستور \fBscontrol\fR تغییر یابد.
.IP

.TP
\fB\-\-acctg\-freq\fR=<\fIdatatype\fR>=<\fIinterval\fR>[,<\fIdatatype\fR>=<\fIinterval\fR>...]
فواصل نمونه‌برداری حسابداری کار و پروفایل‌سازی را به ثانیه تعیین می‌کند.
این گزینه می‌تواند برای بازنویسی پارامتر \fIJobAcctGatherFrequency\fR در فایل slurm.conf استفاده شود. <\fIdatatype\fR>=<\fIinterval\fR> فاصله نمونه‌برداری وظیفه را برای پلاگین jobacct_gather یا فاصله نمونه‌برداری را برای یک نوع پروفایل‌سازی توسط پلاگین acct_gather_profile مشخص می‌کند. چندین جفت <\fIdatatype\fR>=<\fIinterval\fR> جداشده با کاما می‌توانند مشخص شوند. مقادیر پشتیبانی‌شده برای \fIdatatype\fR عبارتند از:
.IP
.RS
.TP 12
\fBtask\fR
فاصله نمونه‌برداری برای پلاگین‌های jobacct_gather و برای پروفایل‌سازی وظیفه توسط پلاگین acct_gather_profile.
.br
\fBنکته\fR: این بسامد برای پایش مصرف حافظه استفاده می‌شود. در صورت اعمال محدودیت‌های حافظه، بالاترین بسامدی که کاربر می‌تواند درخواست کند همان است که در فایل slurm.conf پیکربندی شده است. این مقدار را نمی‌توان غیرفعال کرد.
.IP

.TP
\fBenergy\fR
فاصله نمونه‌برداری برای پروفایل‌سازی مصرف انرژی با استفاده از پلاگین acct_gather_energy.
.IP

.TP
\fBnetwork\fR
فاصله نمونه‌برداری برای پروفایل‌سازی infiniband با استفاده از پلاگین acct_gather_interconnect.
.IP

.TP
\fBfilesystem\fR
فاصله نمونه‌برداری برای پروفایل‌سازی سیستم‌فایل با استفاده از پلاگین acct_gather_filesystem.
.IP

.LP
مقدار پیش‌فرض برای فاصله نمونه‌برداری وظیفه ۳۰ ثانیه است.
مقدار پیش‌فرض برای تمام فاصله‌های دیگر 0 است.
فاصله 0 نمونه‌برداری از نوع مشخص‌شده را غیرفعال می‌کند.
اگر فاصله نمونه‌برداری وظیفه 0 باشد، اطلاعات حسابداری تنها هنگام پایان کار جمع‌آوری می‌شود (که تداخل Slurm با کار را کاهش می‌دهد).
.br
مقادیر کوچک‌تر (غیر صفر) تأثیر بیشتری بر عملکرد کار دارند، اما مقدار ۳۰ ثانیه بعید است برای برنامه‌هایی با کمتر از 10,000 وظیفه محسوس باشد.
.RE
.IP

.TP
\fB\-a\fR, \fB\-\-array\fR=<\fIindexes\fR>
ارسال یک آرایه کار (job array)؛ چندین کار که با پارامترهای یکسان اجرا می‌شوند.
مشخصه \fIindexes\fR تعیین می‌کند که چه مقادیری برای اندیس آرایه باید استفاده شود. مقادیر متعدد می‌توانند با استفاده از یک فهرست جداشده با کاما و/یا بازه‌ای از مقادیر با جداکننده "\-" مشخص شوند. برای مثال، "\-\-array=0\-15" یا "\-\-array=0,6,16\-32".
یک تابع گام نیز می‌تواند با یک پسوند شامل دونقطه و یک عدد مشخص شود. برای مثال، "\-\-array=0\-15:4" معادل با "\-\-array=0,4,8,12" است.
حداکثر تعداد وظایف هم‌زمان در حال اجرا از این آرایه کار را می‌توان با استفاده از جداکننده "%" مشخص کرد.
برای مثال "\-\-array=0\-15%4" تعداد وظایف هم‌زمان در حال اجرا از این آرایه کار را به ۴ محدود می‌کند.
حداقل مقدار اندیس 0 است.
حداکثر مقدار یکی کمتر از پارامتر پیکربندی MaxArraySize است.
\fBنکته\fR: در حال حاضر، آرایه‌های کار فدرال فقط روی کلاستر محلی اجرا می‌شوند.
.IP

.TP
\fB\-\-batch\fR=<\fIlist\fR>
گره‌ها می‌توانند دارای \fBfeatures\fR (ویژگی‌هایی) باشند که توسط مدیر Slurm به آن‌ها اختصاص یافته است.
کاربران می‌توانند با استفاده از این گزینه مشخص کنند کدام‌یک از این \fBfeatures\fR برای اسکریپت دسته‌ای آن‌ها مورد نیاز است.
برای مثال تخصیص منابع یک کار ممکن است شامل هر دو گره Intel Haswell و KNL به ترتیب با ویژگی‌های "haswell" و "knl" باشد.
در چنین پیکربندی، اسکریپت دسته‌ای معمولاً با اجرا روی یک گره سریع‌تر Haswell سودمندتر خواهد بود.
این مورد با استفاده از گزینه "\-\-batch=haswell" مشخص می‌شود.
مشخصات می‌توانند شامل عملگرهای AND و OR با استفاده از جداکننده‌های امپرسند (&) و خط عمودی (|) باشند. برای مثال:
"\-\-batch=haswell|broadwell" یا "\-\-batch=haswell|big_memory".
آرگومان \-\-batch باید زیرمجموعه‌ای از آرگومان \fB\-\-constraint\fR=<\fIlist\fR> کار باشد (یعنی کار نمی‌تواند فقط گره‌های KNL را درخواست کند، اما اجرای اسکریپت را روی یک گره Haswell الزامی بداند).
اگر درخواست از طریق منابع تخصیص‌یافته به کار قابل برآورده شدن نباشد، اسکریپت دسته‌ای روی اولین گرهِ تخصیص کار اجرا خواهد شد.
.IP

.TP
\fB\-\-bb\fR=<\fIspec\fR>
مشخصات بافر انفجاری (burst buffer). قالب این مشخصات وابسته به سیستم است.
همچنین \fB\-\-bbf\fR را ببینید.
هنگامی که گزینه \fB\-\-bb\fR استفاده می‌شود، Slurm این گزینه را تجزیه کرده و یک فایل اسکریپت موقت بافر انفجاری ایجاد می‌کند که به صورت داخلی توسط پلاگین‌های بافر انفجاری استفاده می‌شود. برای اطلاعات بیشتر و مثال‌ها، راهنمای بافر انفجاری Slurm را ببینید:
.br
https://slurm.schedmd.com/burst_buffer.html
.IP

.TP
\fB\-\-bbf\fR=<\fIfile_name\fR>
مسیر فایل حاوی مشخصات بافر انفجاری (burst buffer).
قالب این مشخصات وابسته به سیستم است.
این دستورالعمل‌های بافر انفجاری در اسکریپت دسته‌ای ارسال‌شده درج خواهند شد.
برای اطلاعات بیشتر و مثال‌ها، راهنمای بافر انفجاری Slurm را ببینید:
.br
https://slurm.schedmd.com/burst_buffer.html
.IP

.TP
\fB\-b\fR, \fB\-\-begin\fR=<\fItime\fR>
اسکریپت دسته‌ای را طبق معمول بلافاصله به کنترلر Slurm ارسال می‌کند، اما به کنترلر دستور می‌دهد تخصیص کار را تا زمان مشخص‌شده به تعویق بیندازد.

زمان می‌تواند به شکل \fIHH:MM:SS\fR باشد تا یک کار در ساعت مشخصی از روز اجرا شود (ثانیه‌ها اختیاری هستند).
(اگر آن زمان گذشته باشد، روز بعد در نظر گرفته می‌شود.)
همچنین می‌توانید \fImidnight\fR (نیمه‌شب)، \fInoon\fR (ظهر)، \fIelevenses\fR (ساعت ۱۱ صبح)،
\fIfika\fR (ساعت ۳ بعدازظهر) یا \fIteatime\fR (ساعت ۴ بعدازظهر) را مشخص کنید و می‌توانید زمان روز را با پسوند \fIAM\fR یا \fIPM\fR برای اجرا در صبح یا عصر همراه کنید.
همچنین می‌توانید با مشخص کردن تاریخی به شکل \fIMMDDYY\fR یا \fIMM/DD/YY\fR یا
\fIYYYY\-MM\-DD\fR تعیین کنید که کار در چه روزی اجرا شود. تاریخ و زمان را با استفاده از قالب زیر ترکیب کنید:
\fIYYYY\-MM\-DD[THH:MM[:SS]]\fR. همچنین می‌توانید
زمان‌هایی مانند \fInow + count time\-units\fR بدهید، که در آن time\-units
می‌تواند \fIseconds\fR (پیش‌فرض)، \fIminutes\fR، \fIhours\fR،
\fIdays\fR، یا \fIweeks\fR باشد.
کلمات کلیدی \fItoday\fR و \fItomorrow\fR نیز ممکن است استفاده شوند.
این مقدار می‌تواند پس از ارسال کار با استفاده از دستور
\fBscontrol\fR تغییر یابد.
برای مثال:.IP
.nf
   \-\-begin=16:00
   \-\-begin=now+1hour
   \-\-begin=now+60           (پیش‌فرض برحسب ثانیه)
   \-\-begin=2010\-01\-20T12:34:00
.fi

.RS
.PP
نکاتی دربارهٔ مشخصات تاریخ/زمان:
 \- اگرچه فیلد \(aqseconds\(aq (ثانیه) در قالب زمانی HH:MM:SS توسط کد مجاز دانسته شده است، اما توجه داشته باشید که زمان بررسی (poll time) زمان‌بند Slurm آن‌قدر دقیق نیست که اعزام کار را در همان ثانیهٔ دقیق تضمین کند. این کار در بررسی بعدی پس از زمان مشخص‌شده واجد شرایط شروع خواهد بود. بازهٔ دقیق بررسی به زمان‌بند Slurm بستگی دارد (برای نمونه، ۶۰ ثانیه در sched/builtin پیش‌فرض).
 \- اگر زمانی (HH:MM:SS) مشخص نشود، مقدار پیش‌فرض (00:00:00) است.
 \- اگر تاریخی بدون سال مشخص شود (مانند MM/DD)، سال جاری فرض می‌شود؛ مگر اینکه ترکیب MM/DD و HH:MM:SS برای آن سال گذشته باشد، که در این صورت سال بعد استفاده خواهد شد.
.RE
.IP

.TP
\fB\-D\fR, \fB\-\-chdir\fR=<\fIdirectory\fR>
دایرکتوری کاری اسکریپت دسته‌ای (batch script) را پیش از اجرا روی \fIdirectory\fR تنظیم می‌کند. مسیر را می‌توان به صورت یک مسیر کامل یا مسیر نسبی نسبت به دایرکتوری محل اجرای دستور مشخص کرد.
.IP

.TP
\fB\-\-cluster\-constraint\fR=[!]<\fIlist\fR>
ویژگی‌هایی را مشخص می‌کند که یک خوشهٔ فدراسیونی باید داشته باشد تا یک کار همزاد (sibling job) به آن ارسال شود. اگر خوشه‌ای حداقل یکی از ویژگی‌های مشخص‌شده را داشته باشد، Slurm تلاش خواهد کرد تا کار همزاد را به آن ارسال کند. اگر گزینهٔ «!» لحاظ شده باشد، Slurm تلاش خواهد کرد کار همزاد را به خوشه‌ای ارسال کند که هیچ‌یک از ویژگی‌های مشخص‌شده را نداشته باشد.
.IP

.TP
\fB\-M\fR, \fB\-\-clusters\fR=<\fIstring\fR>
خوشه‌هایی که دستورها باید برای آن‌ها صادر شوند. نام چند خوشه را می‌توان با کاما از هم جدا کرد. کار به خوشه‌ای ارسال خواهد شد که زودترین زمان مورد انتظار برای آغاز کار را ارائه دهد. مقدار پیش‌فرض، خوشهٔ فعلی است. مقدار \(aq\fIall\fR\(aq برای استعلام اجرای کار روی تمام خوشه‌ها به کار می‌رود. برای کنترل متغیرهای محیطی صادرشده بین خوشه‌ها، به گزینهٔ \fB\-\-export\fR توجه کنید.
توجه داشته باشید که برای عملکرد صحیح این گزینه، \fBslurmdbd\fR باید فعال و در حال اجرا باشد، مگر اینکه در یک فدراسیون با پیکربندی \fBFederationParameters=fed_display\fR اجرا شود.
.IP

.TP
\fB\-\-comment\fR=<\fIstring\fR>
یک توضیح اختیاری؛ در صورت استفاده از فاصله یا برخی نویسه‌های خاص باید در علامت نقل‌قول دوتایی قرار گیرد.
.IP

.TP
\fB\-\-consolidate\-segments\fR
اطمینان حاصل می‌کند که تمام قطعه‌های (segments) حاصل از تخصیص، در یک بلوک تجمیعی سطح بالاتر ادغام شوند.

\fBنکته\fR: این گزینه تنها با پلاگین \fBtopology/block\fR کار خواهد کرد.
.IP

.TP
\fB\-C\fR, \fB\-\-constraint\fR=<\fIlist\fR>
گره‌ها می‌توانند دارای ویژگی‌هایی (\fBfeatures\fR) باشند که توسط مدیر Slurm به آن‌ها اختصاص یافته است. کاربران می‌توانند با استفاده از گزینهٔ constraint مشخص کنند کدام‌یک از این \fBویژگی‌ها\fR برای کارشان لازم است. اگر به دنبال محدودیت‌های «نرم» (soft) هستید، لطفاً برای اطلاعات بیشتر \fB\-\-prefer\fR را ببینید.
تنها گره‌هایی که دارای ویژگی‌های منطبق با محدودیت‌های کار باشند برای برآورده کردن درخواست استفاده خواهند شد.
محدودیت‌های چندگانه را می‌توان با AND، OR، matching OR، تعداد منابع و غیره مشخص کرد (برخی عملگرها در تمام انواع سیستم‌ها پشتیبانی نمی‌شوند).

\fBنکته\fR: ویژگی‌های تغییرپذیر (Changeable features) ویژگی‌هایی هستند که توسط یک پلاگین NodeFeatures تعریف شده‌اند.

گزینه‌های پشتیبانی‌شدهٔ \fB\-\-constraint\fR عبارتند از:
.IP
.PD 1
.RS
.TP
\fBنام تکی (Single Name)\fR
تنها گره‌هایی که دارای ویژگی مشخص‌شده باشند استفاده خواهند شد.
برای نمونه، \fB\-\-constraint="intel"\fR
.IP

.TP
\fBتعداد گره (Node Count)\fR
یک درخواست می‌تواند با افزودن یک ستاره و تعداد پس از نام ویژگی، تعداد گره‌های مورد نیاز با یک ویژگی خاص را مشخص کند.
برای نمونه، \fB\-\-nodes=16 \-\-constraint="graphics*4"\fR نشان می‌دهد که کار به ۱۶ گره نیاز دارد و حداقل چهار گره از آن گره‌ها باید دارای ویژگی «graphics» باشند.
اگر بیش از یک ویژگی درخواست شود و از شمارش گره‌ها استفاده شود، درخواست باید داخل کروشه قرار گیرد.

\fBنکته\fR: این گزینه توسط پلاگین helpers NodeFeatures پشتیبانی نمی‌شود. به جای آن می‌توان از کارهای ناهمگن (Heterogeneous jobs) استفاده کرد.
.IP

.TP
\fBAND\fR
تنها گره‌هایی که تمام ویژگی‌های مشخص‌شده را داشته باشند استفاده خواهند شد.
علامت امپرسند (&) برای عملگر AND به کار می‌رود.
برای نمونه، \fB\-\-constraint="intel&gpu"\fR
.IP

.TP
\fBOR\fR
تنها گره‌هایی که حداقل یکی از ویژگی‌های مشخص‌شده را داشته باشند استفاده خواهند شد.
خط عمودی (|) برای عملگر OR استفاده می‌شود. اگر ویژگی‌های تغییرپذیر درخواست نشده باشند، گره‌های موجود در تخصیص می‌توانند ویژگی‌های متفاوتی داشته باشند. برای نمونه، \fBsalloc -N2 \-\-constraint="intel|amd"\fR می‌تواند منجر به تخصیص کاری شود که در آن یک گره دارای ویژگی intel و گره دیگر دارای ویژگی amd باشد.
اما اگر عبارت حاوی یک ویژگی تغییرپذیر باشد، تمام عملگرهای OR به‌طور خودکار به عنوان Matching OR در نظر گرفته می‌شوند تا تمام گره‌های موجود در تخصیص کار دارای مجموعه ویژگی‌های یکسانی باشند. برای نمونه،
\fBsalloc -N2 \-\-constraint="foo|bar&baz"\fR
به کار دو گره اختصاص می‌یابد که هر دو گره دارای foo، یا bar و baz هستند (یک یا هر دو گره می‌توانند دارای foo، bar و baz باشند). پلاگین helpers NodeFeatures نخستین مجموعه از ویژگی‌های گره را پیدا می‌کند که با تمام گره‌های تخصیص کار مطابقت داشته باشد؛ این ویژگی‌ها به عنوان ویژگی‌های فعال روی گره تنظیم شده و به RebootProgram (ببینید \fBslurm.conf\fR(5)) و اسکریپت کمکی (ببینید \fBhelpers.conf\fR(5)) فرستاده می‌شوند. در این حالت، پلاگین helpers از اولین مورد بین «foo» یا «bar,baz» که با دو گره تخصیص کار مطابقت دارد استفاده می‌کند.
.IP

.TP
\fBMatching OR\fR
اگر باید تنها یکی از گزینه‌های ممکن برای تمام گره‌های تخصیص‌یافته استفاده شود، از عملگر OR استفاده کرده و گزینه‌ها را داخل کروشه قرار دهید.
برای نمونه، \fB\-\-constraint="[rack1|rack2|rack3|rack4]"\fR ممکن است برای مشخص کردن این استفاده شود که تمام گره‌ها باید روی یک رَک واحد از خوشه تخصیص داده شوند، اما از هر یک از آن چهار رک می‌توان استفاده کرد.
.IP

.TP
\fBتعداد چندگانه (Multiple Counts)\fR
تعداد مشخصی از منابع چندگانه را می‌توان با استفاده از عملگر AND و قرار دادن گزینه‌ها داخل کروشه مشخص کرد.
برای نمونه، \fB\-\-constraint="[rack1*2&rack2*4]"\fR ممکن است برای مشخص کردن این استفاده شود که دو گره باید از گره‌های دارای ویژگی «rack1» و چهار گره از گره‌های دارای ویژگی «rack2» تخصیص داده شوند.

\fBنکته\fR: این گزینه توسط پلاگین helpers NodeFeatures پشتیبانی نمی‌شود.

\fBنکته\fR: تعداد چندگانه (Multiple Counts) می‌تواند باعث شود کارها با چیدمان شبکه‌ای غیربهینه تخصیص یابند.
.IP

.TP
\fBکروشه‌ها (Brackets)\fR
کروشه‌ها را می‌توان برای نشان دادن این استفاده کرد که شما به دنبال مجموعه‌ای از گره‌ها با نیازمندی‌های متفاوتی هستید که درون کروشه قرار دارند. برای نمونه، \fB\-\-constraint="[(rack1|rack2)*1&(rack3)*2]"\fR یک گره با یکی از ویژگی‌های «rack1» یا «rack2» و دو گره با ویژگی «rack3» برای شما فراهم می‌کند.
اگر بیش از یک ویژگی درخواست شود و از شمارش گره‌ها استفاده شود، درخواست باید داخل کروشه احاطه شود.

\fBنکته\fR: کروشه‌ها تنها برای نحو \fBMultiple Counts\fR و \fBMatching OR\fR اختصاص یافته‌اند.
عملگرهای AND نیازمند شمارش برای هر ویژگی درون کروشه هستند (یعنی «[quad*2&hemi*1]»). سامانه Slurm تنها یک مجموعه از محدودیت‌های درون کروشه را برای هر کار مجاز می‌داند.

\fBنکته\fR: کروشه‌ها توسط پلاگین helpers NodeFeatures پشتیبانی نمی‌شوند. Matching OR را می‌توان بدون کروشه و با استفاده از نویسهٔ خط عمودی به همراه حداقل یک ویژگی تغییرپذیر درخواست کرد.
.IP

.TP
\fBپرانتزها (Parentheses)\fR
پرانتزها می‌توانند برای گروه‌بندی ویژگی‌های مشابه گره در کنار یکدیگر استفاده شوند. برای نمونه، ممکن است از \fB\-\-constraint="[(knl&snc4&flat)*4&haswell*1]"\fR برای مشخص کردن این استفاده شود که چهار گره با ویژگی‌های «knl»، «snc4» و «flat» به علاوهٔ یک گره با ویژگی «haswell» مورد نیاز است.
همچنین می‌توان از پرانتزها برای گروه‌بندی عملیات استفاده کرد. بدون پرانتز، ویژگی‌های گره دقیقاً از چپ به راست تجزیه می‌شوند.
برای نمونه،
\fB\-\-constraint="foo&bar|baz"\fR گره‌هایی با foo و bar، یا baz را درخواست می‌کند.
\fB\-\-constraint="foo|bar&baz"\fR گره‌هایی با foo و baz، یا bar و baz را درخواست می‌کند (توجه کنید که چگونه baz با همه‌چیز AND شد).
\fB\-\-constraint="foo&(bar|baz)"\fR گره‌هایی با foo و حداقل یکی از bar یا baz را درخواست می‌کند.
\fBنکته\fR: از OR درون پرانتز نباید با پلاگین KNL NodeFeatures استفاده شود، اما توسط پلاگین helpers NodeFeatures پشتیبانی می‌شود.
.RE
.IP

.TP
\fB\-\-container\fR=<\fIpath_to_container\fR>
مسیر مطلق به بستهٔ کانتینر OCI (OCI container bundle).
.IP

.TP
\fB\-\-container-id\fR=<\fIcontainer_id\fR>
نام یکتا برای کانتینر OCI..IP

.TP
\fB\-\-container-type\fR=<\fIcontainer_type\fR>
نوع کانتینر برای استفاده در کار.
.IP

.TP
\fB\-\-contiguous\fR
در صورت تنظیم، گره‌های تخصیص‌یافته باید یک مجموعهٔ پیوسته را تشکیل دهند.

\fBنکته\fR: این گزینه تنها با پلاگین \fBtopology/flat\fR کار خواهد کرد.
سایر پلاگین‌های توپولوژی ترتیب گره‌ها را تغییر می‌دهند و از اعمال این گزینه جلوگیری می‌کنند.
.IP

.TP
\fB\-S\fR, \.IP

.TP
\fB\-\-delay\-boot\fR=<\fIminutes\fR>
اگر کار برای مدتی کمتر از این بازهٔ زمانی واجد شرایط اجرا بوده است، گره‌ها را برای برآورده ساختن ویژگی‌های (features) مشخص‌شدهٔ این کار بازراه‌اندازی (reboot) نکنید.
اگر کار کمتر از این مدت زمان مشخص منتظر مانده باشد، تنها از گره‌هایی استفاده خواهد کرد که از پیش دارای ویژگی‌های مشخص‌شده هستند.
آرگومان بر حسب دقیقه است.
یک مقدار پیش‌فرض می‌تواند توسط مدیر سیستم با استفاده از گزینهٔ \fBdelay_boot\fR از پارامتر پیکربندی \fBSchedulerParameters\fR در فایل slurm.conf تعیین شود، در غیر این صورت مقدار پیش‌فرض صفر است (بدون تاخیر).
.IP

.TP
\fB\-d\fR, \fB\-\-dependency\fR=<\fIdependency_list\fR>
شروع این کار را تا زمانی که وابستگی‌های مشخص‌شده برآورده شوند، به تعویق بیندازید. به محض اینکه یک وابستگی برآورده شود، از کار حذف خواهد شد.
<\fIdependency_list\fR> به فرم
<\fItype:job_id[:job_id][,type:job_id[:job_id]]\fR> یا
<\fItype:job_id[:job_id][?type:job_id[:job_id]]\fR> است.
اگر از جداکنندهٔ «,» استفاده شود، تمام وابستگی‌ها باید برآورده شوند.
اگر از جداکنندهٔ «?» استفاده شود، برآورده شدن هر یک از وابستگی‌ها کافی خواهد بود.
تنها می‌توان از یک جداکننده استفاده کرد. برای نمونه:
.nf
-d afterok:20:21,afterany:23
.fi
.IP
بدین معناست که کار تنها پس از بازگشت کد خروج ۰ از کارهای ۲۰ و ۲۱ و همچنین اتمام کار ۲۳ می‌تواند اجرا شود. با این حال:
.nf
-d afterok:20:21?afterany:23
.fi
بدین معناست که برآورده شدن هر یک از شرایط (afterok:20 یا afterok:21 یا afterany:23) برای آزاد شدن کار کافی خواهد بود.
کارهای متعددی می‌توانند یک وابستگی یکسان را به اشتراک بگذارند و این کارها حتی ممکن است متعلق به کاربران مختلفی باشند. این مقدار را می‌توان پس از ثبت کار با استفاده از دستور scontrol تغییر داد.
وابستگی به کارهای راه‌دور در یک فدراسیون مجاز است.
به محض اینکه وابستگی یک کار به دلیل وضعیت خاتمهٔ کار پیشین ناموفق شود، کار وابسته هرگز اجرا نخواهد شد، حتی اگر کار پیشین دوباره در صف قرار گیرد (requeued) و در اجرای بعدی دارای وضعیت خاتمهٔ متفاوتی باشد.
.IP
.PD
.RS
.TP
\fBafter:job_id[[+time][:jobid[+time]...]]\fR
پس از شروع یا لغو کارهای مشخص‌شده و سپری شدن زمان 'time' به دقیقه از شروع یا لغو کار، این کار می‌تواند اجرای خود را آغاز کند. اگر مقداری برای 'time' داده نشود، هیچ تاخیری پس از شروع یا لغو اعمال نمی‌شود.
.IP

.TP
\fBafterany:job_id[:jobid...]\fR
این کار می‌تواند پس از خاتمه یافتن کارهای مشخص‌شده، اجرای خود را آغاز کند. این نوع، وابستگی پیش‌فرض است.
.IP

.TP
\fBafterburstbuffer:job_id[:jobid...]\fR
این کار می‌تواند پس از خاتمهٔ کارهای مشخص‌شده و تکمیل هرگونه عملیات مرتبط با انتقال دادهٔ خروجیِ بافر انفجاری (burst buffer stage out)، اجرای خود را آغاز کند.
.IP

.TP
\fBaftercorr:job_id[:jobid...]\fR
یک تسک (تکلیف) از این آرایه کار (job array) می‌تواند پس از اینکه شناسهٔ تسک متناظر در کار مشخص‌شده با موفقیت کامل شد (با کد خروج صفر به پایان رسید)، اجرای خود را آغاز کند. اگر کار مشخص‌شده یک آرایه نباشد، همانند afterok با آن رفتار می‌شود.
.IP

.TP
\fBafternotok:job_id[:jobid...]\fR
این کار می‌تواند پس از اینکه کارهای مشخص‌شده در یک وضعیت ناموفق (کد خروج غیرصفر، خرابی گره، اتمام مهلت زمانی، و غیره) خاتمه یافتند، اجرای خود را آغاز کند.
این کار باید زمانی ارسال شود که کار مشخص‌شده همچنان فعال باشد، یا در بازهٔ \fBMinJobAge\fR ثانیه پس از پایان کار مشخص‌شده ارسال گردد.
اگر شناسهٔ کار وابسته یافت نشود و در همان کلاستری باشد که کار در آن ارسال شده است، کار رد می‌شود. اگر شناسهٔ کار وابسته یافت نشود و در کلاستری متفاوت از محل ارسال کار باشد، وابستگی به عنوان ناموفق (failed) علامت‌گذاری می‌گردد.
.IP

.TP
\fBafterok:job_id[:jobid...]\fR
این کار می‌تواند پس از اینکه کارهای مشخص‌شده با موفقیت اجرا شدند (با کد خروج صفر به پایان رسیدند)، اجرای خود را آغاز کند.
این کار باید زمانی ارسال شود که کار مشخص‌شده همچنان فعال باشد، یا در بازهٔ \fBMinJobAge\fR ثانیه پس از پایان کار مشخص‌شده ارسال گردد.
اگر شناسهٔ کار وابسته یافت نشود و در همان کلاستری باشد که کار در آن ارسال شده است، کار رد می‌شود. اگر شناسهٔ کار وابسته یافت نشود و در کلاستری متفاوت از محل ارسال کار باشد، وابستگی به عنوان ناموفق (failed) علامت‌گذاری می‌گردد.
.IP

.TP
\fBsingleton\fR
این کار می‌تواند پس از خاتمه یافتن هر کار اجراشدهٔ قبلی که دارای نام کار و کاربر یکسانی است، اجرای خود را آغاز کند.
به عبارت دیگر، در هر مقطع زمانی تنها یک کار با آن نام و متعلق به آن کاربر می‌تواند در حال اجرا یا تعلیق باشد.
در یک فدراسیون، وابستگی singleton باید در تمام کلاسترها برآورده شود مگر اینکه از DependencyParameters=disable_remote_singleton در slurm.conf استفاده شده باشد.
.RE
.IP

.TP
\fB\-m\fR, \fB\-\-distribution\fR={*|block|cyclic|arbitrary|plane=<\fIsize\fR>}[:{*|block|cyclic|fcyclic}[:{*|block|cyclic|fcyclic}]][,{Pack|NoPack}]

روش‌های توزیع جایگزین را برای فرایندهای دوردست مشخص می‌کند.
برای تخصیص کار، این گزینه متغیرهای محیطی را تنظیم می‌کند که توسط درخواست‌های بعدی srun استفاده خواهند شد و همچنین بر اینکه کدام هسته‌ها برای تخصیص کار انتخاب شوند تأثیر می‌گذارد.

این گزینه توزیع تسک‌ها روی گره‌هایی که منابع بر روی آن‌ها تخصیص یافته است، و توزیع آن منابع به تسک‌ها برای اتصال (task affinity) را کنترل می‌کند. روش توزیع اول (پیش از نخستین «:») توزیع تسک‌ها روی گره‌ها را کنترل می‌کند. روش توزیع دوم (پس از نخستین «:») توزیع پردازنده‌های (CPU) تخصیص‌یافته در سراسر سوکت‌ها را برای اتصال به تسک‌ها کنترل می‌کند. روش توزیع سوم (پس از دومین «:») توزیع پردازنده‌های تخصیص‌یافته در سراسر هسته‌ها را برای اتصال به تسک‌ها کنترل می‌کند.
روش‌های توزیع دوم و سوم تنها در صورتی اعمال می‌شوند که قابلیت چسبندگی تسک (task affinity) فعال باشد.
توزیع سوم تنها در حالتی پشتیبانی می‌شود که افزونهٔ task/cgroup پیکربندی شده باشد. مقدار پیش‌فرض برای هر نوع توزیع با * مشخص می‌شود.

توجه داشته باشید که با select/cons_tres، ممکن است تعداد پردازنده‌های تخصیص‌یافته به هر سوکت و گره متفاوت باشد. برای اطلاعات بیشتر در خصوص تخصیص منابع، توزیع تسک‌ها روی گره‌ها، و اتصال تسک‌ها به پردازنده‌ها به
<https://slurm.schedmd.com/mc_support.html>
مراجعه کنید.
.RS
روش توزیع اول (توزیع تسک‌ها در سراسر گره‌ها):

.TP
.B *
از روش پیش‌فرض برای توزیع تسک‌ها روی گره‌ها (block) استفاده می‌کند.
اگر یک افزونهٔ توپولوژی پیکربندی شده باشد و کاربر روش توزیعی را مشخص نکند، تسک‌ها به جای ترتیب نمایهٔ گره، بر اساس ترتیب توپولوژی توزیع می‌شوند. برای غیرفعال کردن این رفتار، به \fBCR_NO_DIST_TOPO_BLOCK\fR در \fBSelectTypeParameters\fR مراجعه کنید.
.IP

.TP
.B block
روش توزیع بلوکی (block) تسک‌ها را طوری روی یک گره توزیع می‌کند که تسک‌های متوالی یک گره را به اشتراک بگذارند. به عنوان مثال، تخصیص سه گره را در نظر بگیرید که هر یک دارای دو پردازنده هستند. یک درخواست توزیع بلوکی چهار تسکی، این تسک‌ها را طوری روی گره‌ها توزیع می‌کند که تسک‌های یک و دو روی گره اول، تسک سه روی گره دوم، و تسک چهار روی گره سوم قرار گیرند. اگر تعداد تسک‌ها از تعداد گره‌های تخصیص‌یافته فراتر رود، توزیع بلوکی رفتار پیش‌فرض خواهد بود.
.IP

.TP
.B cyclic
روش توزیع چرخشی (cyclic) تسک‌ها را طوری روی گره‌ها توزیع می‌کند که تسک‌های متوالی روی گره‌های متوالی توزیع شوند (به روش نوبت‌گردشی یا round\-robin). به عنوان مثال، تخصیص سه گره را در نظر بگیرید که هر یک دارای دو پردازنده هستند. یک درخواست توزیع چرخشی چهار تسکی، تسک‌ها را طوری توزیع خواهد کرد که تسک‌های یک و چهار روی گره اول، تسک دو روی گره دوم، و تسک سه روی گره سوم قرار گیرند.
توجه داشته باشید که اگر SelectType برابر با select/cons_tres باشد، ممکن است تعداد پردازنده‌های تخصیص‌یافته روی هر گره یکسان نباشد. توزیع تسک‌ها به صورت نوبت‌گردشی در میان تمام گره‌هایی خواهد بود که هنوز پردازنده‌هایی برای واگذاری به تسک‌ها دارند.
اگر تعداد تسک‌ها بزرگ‌تر از تعداد گره‌های تخصیص‌یافته نباشد، توزیع چرخشی رفتار پیش‌فرض است.
.IP

.TP
.B plane
تسک‌ها در بلوک‌هایی به اندازهٔ <\fIsize\fR> توزیع می‌شوند. اندازه باید مشخص شود یا اینکه متغیر SLURM_DIST_PLANESIZE مقداردهی شده باشد. تعداد تسک‌های توزیع‌شده روی هر گره همانند توزیع چرخشی است، اما شناسه‌های تسک (taskid) اختصاص‌یافته به هر گره به اندازهٔ plane بستگی دارد. مشخصات توزیع بیشتر را نمی‌توان با این گزینه ترکیب کرد.
برای جزئیات بیشتر (شامل مثال‌ها و نمودارها)، لطفاً به
<https://slurm.schedmd.com/mc_support.html>
و
<https://slurm.schedmd.com/dist_plane.html>
مراجعه فرمایید.
.IP

.TP
.B arbitrary
روش توزیع دلخواه (arbitrary) فرایندها را به ترتیب بر اساس ترتیبی که در فایل مشخص‌شده توسط متغیر محیطی SLURM_HOSTFILE فهرست شده‌اند، تخصیص می‌دهد. اگر این متغیر تعریف شده باشد، بر هر روش مشخص‌شدهٔ دیگری اولویت خواهد داشت. در صورت عدم تنظیم، روش به طور پیش‌فرض به block برمی‌گردد.
محتوای درون hostfile باید حداقل شامل تعداد میزبان‌های درخواست‌شده به صورت یک مورد در هر خط یا جداشده با ویرگول باشد. در صورت تعیین تعداد تسک (\fB\-n\fR, \fB\-\-ntasks\fR=<\fInumber\fR>)، تسک‌های شما به ترتیب فایل روی گره‌ها مستقر خواهند شد.
.br
\fBنکته\fR: گزینهٔ توزیع دلخواه تنها با روش تخصیص عمومی (generic) پشتیبانی می‌شود و با ویژگی‌هایی نظیر توپولوژی، CR_LLN، CR_Pack_Nodes یا pack_serial_at_end قابل استفاده نیست. هدف اصلی این گزینه کنترل نحوهٔ چیدمان تسک‌های یک مرحله از کار (job step) در یک تخصیص کار موجود برای دستور srun است.
.br
\fBنکته\fR: اگر تعداد تسک‌ها مشخص شده و فهرستی از گره‌های درخواستی نیز ارائه شده باشد، در صورتی که تعداد گره‌های موجود در فهرست بیشتر از تعداد تسک‌ها باشد، تعداد گره‌های مورد استفاده از آن فهرست کاهش می‌یابد تا با تعداد تسک‌ها همخوانی پیدا کند..IP

.LP
روش توزیع دوم (توزیع پردازنده‌ها میان سوکت‌ها برای مقیدسازی):

.TP
.B *
استفاده از روش پیش‌فرض برای توزیع پردازنده‌ها میان سوکت‌ها (cyclic).
.IP

.TP
.B block
روش توزیع block پردازنده‌های تخصیص‌یافته را پیش از استفاده از سوکت متوالی بعدی، به‌صورت پیاپی از همان سوکت برای مقیدسازی به تسک‌ها توزیع می‌کند.
.IP

.TP
.B cyclic
روش توزیع cyclic پردازنده‌های تخصیص‌یافته جهت مقیدسازی به یک تسک مشخص را به‌صورت پیاپی از همان سوکت، و برای تسک بعدی از سوکت متوالی بعدی، به شیوهٔ گردشی (round\-robin) در میان سوکت‌ها توزیع می‌کند.
برای تسک‌هایی که به بیش از یک پردازنده نیاز دارند، در صورت امکان تمام آن پردازنده‌ها روی یک سوکت واحد تخصیص داده خواهند شد.
.br
\fBنکته\fR: در گره‌هایی که hyper-threading در آن‌ها فعال است، تسکی که کل هسته‌ها را درخواست نکرده باشد ممکن است میان سوکت‌ها توزیع شود. می‌توان با مشخص کردن \fB\-\-ntasks\-per\-core=1\fR از این امر جلوگیری کرد، که تسک‌ها را مجبور به تخصیص هسته‌های کامل می‌کند.
.IP

.TP
.B fcyclic
روش توزیع fcyclic پردازنده‌های تخصیص‌یافته جهت مقیدسازی به تسک‌ها را از سوکت‌های متوالی به شیوهٔ گردشی (round\-robin) در میان سوکت‌ها توزیع می‌کند.
برای تسک‌هایی که به بیش از یک پردازنده نیاز دارند، هر یک از پردازنده‌ها به‌صورت چرخشی (cyclic) میان سوکت‌ها تخصیص می‌یابند.
.IP

.LP
روش توزیع سوم (توزیع پردازنده‌ها میان هسته‌ها برای مقیدسازی):

.TP
.B *
استفاده از روش پیش‌فرض برای توزیع پردازنده‌ها میان هسته‌ها (به ارث رسیده از روش توزیع دوم).
.IP

.TP
.B block
روش توزیع block پردازنده‌های تخصیص‌یافته را پیش از استفاده از هستهٔ متوالی بعدی، به‌صورت پیاپی از همان هسته برای مقیدسازی به تسک‌ها توزیع می‌کند.
.IP

.TP
.B cyclic
روش توزیع cyclic پردازنده‌های تخصیص‌یافته جهت مقیدسازی به یک تسک مشخص را به‌صورت پیاپی از همان هسته، و برای تسک بعدی از هستهٔ متوالی بعدی، به شیوهٔ گردشی (round\-robin) در میان هسته‌ها توزیع می‌کند.
.IP

.TP
.B fcyclic
روش توزیع fcyclic پردازنده‌های تخصیص‌یافته جهت مقیدسازی به تسک‌ها را از هسته‌های متوالی به شیوهٔ گردشی (round\-robin) در میان هسته‌ها توزیع می‌کند.
.IP

.LP
کنترل اختیاری برای توزیع تسک‌ها روی گره‌ها:

.TP
.B Pack
به‌جای توزیع یکنواخت تسک‌های یک مرحله از کار روی گره‌های تخصیص‌یافته، آن‌ها را تا حد امکان فشرده روی گره‌ها قرار می‌دهد.
این گزینه تنها زمانی اعمال می‌شود که از روش توزیع تسک «block» استفاده شده باشد.
.IP

.TP
.B NoPack
به‌جای قرار دادن تسک‌های یک مرحله از کار به فشرده‌ترین شکل ممکن روی گره‌ها، آن‌ها را به‌طور یکنواخت توزیع می‌کند.
این گزینهٔ کاربری بر پارامتر پیکربندی SelectTypeParameters CR_Pack_Nodes اولویت خواهد داشت.
.RE
.IP

.TP
\fB\-e\fR, \fB\-\-error\fR=<\fIfilename_pattern\fR>
به Slurm دستور می‌دهد خطای استاندارد (standard error) اسکریپت دسته‌ای (batch script) را مستقیماً به نام فایل مشخص‌شده در «\fIfilename pattern\fR» متصل کند.
به‌طور پیش‌فرض، هم خروجی استاندارد و هم خطای استاندارد به یک فایل هدایت می‌شوند.
برای آرایه‌های کار (job arrays)، نام فایل پیش‌فرض "slurm\-%A_%a.out" است که در آن "%A" با شناسهٔ کار (job ID) و "%a" با نمایهٔ آرایه جایگزین می‌شود.
برای سایر کارها، نام فایل پیش‌فرض "slurm\-%j.out" است که در آن "%j" با شناسهٔ کار جایگزین می‌شود.
برای گزینه‌های تعیین نام فایل، بخش \fBfilename pattern\fR در زیر را ببینید.
.IP

.TP
\fB\-x\fR, \fB\-\-exclude\fR=<\fInode_name_list\fR>
به‌طور صریح گره‌های خاصی را از منابع اعطاشده به کار مستثنی می‌کند.
.IP

.TP
\fB\-\-exclusive\fR[={user|mcs|topo}]
تخصیص کار نمی‌تواند گره‌ها (یا در صورت استفاده از "=topo"، بخش مکان‌نگاری) را با دیگر کارهای در حال اجرا (یا فقط با سایر کاربران در صورت استفاده از گزینهٔ "=user" یا گزینهٔ "=mcs") به اشتراک بگذارد.
اگر user/mcs/topo مشخص نشده باشند (یعنی تخصیص کار نتواند گره‌ها را با دیگر کارهای در حال اجرا به اشتراک بگذارد)، تمامی CPUها و GRESها روی تمام گره‌های تخصیص‌یافته به کار اختصاص می‌یابد، اما حافظه تنها به میزانی که درخواست شده تخصیص داده می‌شود. این طراحی برای پشتیبانی از زمان‌بندی گروهی (gang scheduling) است، زیرا کارهای تعلیق‌شده همچنان در حافظه باقی می‌مانند. برای درخواست تمام حافظهٔ یک گره، از \fB\-\-mem=0\fR استفاده کنید.
رفتار پیش‌فرض اشتراکی/انحصاری به پیکربندی سیستم بستگی دارد و گزینهٔ \fBOverSubscribe\fR در پارتیشن بر گزینهٔ کار اولویت دارد.
\fBنکته\fR: از آنجا که GRES اشتراکی (MPS) نمی‌تواند هم‌زمان با یک GRES به‌اشتراک‌گذارنده (GPU) تخصیص یابد، این گزینه تنها تمام GRESهای به‌اشتراک‌گذارنده را تخصیص می‌دهد و هیچ GRES اشتراکیِ زیرینی را تخصیص نخواهد داد.

\fBنکته\fR: این گزینه با \fB\-\-oversubscribe\fR ناسازگار (مانعة‌الجمع) است.
.IP

.TP
\fB\-\-export\fR={[ALL,]<\fIenvironment_variables\fR>|ALL|NIL|NONE}
مشخص می‌کند کدام متغیرهای محیطی از محیط ارسال (submission environment) به برنامهٔ اجراشده منتقل شوند. توجه داشته باشید که متغیرهای SLURM_* همیشه منتقل می‌شوند.
.IP
.RS
.TP 10
\fB\-\-export\fR=ALL
حالت پیش‌فرض در صورتی که \fB\-\-export\fR مشخص نشده باشد. تمام متغیرهای محیطی کاربر بارگذاری خواهند شد (یا از محیط فراخواننده، یا در صورت مشخص بودن \fI\-\-get\-user\-env\fR از یک محیط تمیز).
.IP

.TP
\fB\-\-export\fR=NIL
تنها متغیرهای SLURM_* و متغیرهای گزینهٔ SPANK از محیط کاربر تعریف خواهند شد. کاربر باید از مسیر مطلق برای باینری اجرایی استفاده کند که محیط را تعریف خواهد کرد.
کاربر نمی‌تواند با "NIL" متغیرهای محیطی صریحی را تعیین کند.

برخلاف NONE، مقدار NIL به‌طور خودکار محیط کاربر را با استفاده از سازوکار \fI\-\-get\-user\-env\fR ایجاد نخواهد کرد.
.IP

.TP
\fB\-\-export\fR=NONE
تنها متغیرهای SLURM_* و متغیرهای گزینهٔ SPANK از محیط کاربر تعریف خواهند شد. کاربر باید از مسیر مطلق برای باینری اجرایی استفاده کند که محیط را تعریف خواهد کرد.
کاربر نمی‌تواند با "NONE" متغیرهای محیطی صریحی را تعیین کند.
با این حال، Slurm سپس به‌طور ضمنی تلاش می‌کند تا محیط کاربر را روی گره‌ای که اسکریپت در حال اجرا روی آن است بارگذاری کند، گویی \fI\-\-get\-user\-env\fR مشخص شده است.

این گزینه به‌ویژه برای کارهایی اهمیت دارد که روی یک کلاستر ارسال شده و روی کلاستر دیگری اجرا می‌شوند (مثلاً با مسیرهای متفاوت).
جهت جلوگیری از به ارث بردن تنظیمات صدور متغیرهای محیطی (مانند "NONE") از دستور sbatch توسط مراحل کار، متغیر محیطی SLURM_EXPORT_ENV باید در اسکریپت کار روی "ALL" تنظیم شود.
.IP

.TP
\fB\-\-export\fR=[\fIALL\fR,]<\fIenvironment_variables\fR>
تمام متغیرهای محیطی SLURM_* و گزینه‌های SPANK را به همراه متغیرهای مشخص‌شده به‌طور صریح صادر می‌کند. نام چند متغیر محیطی باید با کاما از یکدیگر جدا شوند.
نام متغیرهای محیطی را می‌توان برای انتقال مقدار فعلی مشخص کرد (مانند "\-\-export=EDITOR") یا مقادیر خاصی را صادر کرد (مانند "\-\-export=EDITOR=/bin/emacs"). اگر "ALL" تعیین شود، تمام متغیرهای محیطی کاربر بارگذاری شده و بر هر متغیر محیطی که به‌صراحت داده شده اولویت خواهند داشت.
.IP
.RS 5
.TP 5
مثال: \fB\-\-export\fR=EDITOR,ARG1=test
در این مثال، محیط منتقل‌شده تنها شامل متغیر \fIEDITOR\fR از محیط کاربر، متغیرهای محیطی \fISLURM_*\fR، و \fIARG1\fR=test خواهد بود.
.IP

.TP
مثال: \fB\-\-export\fR=ALL,EDITOR=/bin/emacs
برای این مثال دو نتیجهٔ ممکن وجود دارد. اگر فراخواننده متغیر محیطی \fIEDITOR\fR را تعریف کرده باشد، محیط کار متغیر را از محیط فراخواننده به ارث می‌برد. اگر فراخواننده متغیر محیطی برای \fIEDITOR\fR تعریف نکرده باشد، محیط کار از مقدار ارائه‌شده توسط \fB\-\-export\fR استفاده خواهد کرد.
.RE

\fBنکته\fR: حالت‌های NONE و [\fIALL\fR,]<\fIenvironment_variables\fR> به‌طور ضمنی به گونه‌ای کار می‌کنند که گویی \fB--get-user-env\fR تعریف شده است. لطفاً برای پیامدهای این امر، بخش مربوط به آن را ببینید.

.RE.IP

.TP
\fB\-\-export\-file\fR={<\fIfilename\fR>|<\fIfd\fR>}
اگر عددی بین 3 و OPEN_MAX به عنوان آرگومان این گزینه مشخص شود، یک توصیف‌گر فایل (file descriptor) خواندنی در نظر گرفته می‌شود (STDIN و STDOUT به عنوان آرگومان‌های معتبر پشتیبانی نمی‌شوند). در غیر این صورت یک نام فایل در نظر گرفته می‌شود. متغیرهای محیطی تعریف‌شده در <\fIfilename\fR> یا خوانده‌شده از <\fIfd\fR> را به محیط اجرای کار (job) صادر می‌کند. محتوا شامل یک یا چند تعریف متغیر محیطی به فرم NAME=value است که هر یک با یک نویسه تهی (null) از دیگری جدا شده‌اند. این امر امکان استفاده از نویسه‌های خاص را در تعاریف محیطی فراهم می‌کند.
.IP

.TP
\fB\-\-extra\fR=<\fIstring\fR>
یک رشته دلخواه که در صورت استفاده از فاصله یا برخی نویسه‌های خاص، باید در علامت‌های نقل‌قول تکی یا دوتایی محصور شود.

اگر \fBSchedulerParameters=extra_constraints\fR فعال باشد، این رشته برای فیلتر کردن گره‌ها بر اساس فیلد \fIExtra\fR در هر گره استفاده می‌شود.
.IP

.TP
\fB\-B\fR, \fB\-\-extra\-node\-info\fR=<\fIsockets\fR>[:\fIcores\fR[:\fIthreads\fR]]
انتخاب گره را به گره‌هایی با دست‌کم تعداد مشخص‌شده از سوکت‌ها، هسته‌ها به ازای هر سوکت و/یا رشته‌ها (threads) به ازای هر هسته محدود می‌کند.
.br
\fBنکته\fR: این گزینه‌ها اندازه تخصیص منبع را مشخص نمی‌کنند. هر مقدار مشخص‌شده به عنوان یک حداقل در نظر گرفته می‌شود. از یک ستاره (*) می‌توان به عنوان جای‌نگهدار بدون محدود کردن انتخاب گره برای آن نوع استفاده کرد. سطوح مجزا را می‌توان در صورت تمایل در گزینه‌های جداگانه نیز مشخص نمود:
.nf
    \fB\-\-sockets\-per\-node\fR=<\fIsockets\fR>
    \fB\-\-cores\-per\-socket\fR=<\fIcores\fR>
    \fB\-\-threads\-per\-core\fR=<\fIthreads\fR>
.fi
اگر افزونه task/affinity فعال باشد، مشخص کردن تخصیص به این شیوه همچنین منجر به مقید شدن تسک‌های راه‌اندازی‌شده بعدی به threadها می‌شود، البته در صورتی که گزینه \fB\-B\fR تعداد رشته را مشخص کرده باشد؛ در غیر این صورت اگر تعداد هسته مشخص شده باشد به \fIcores\fR، و در غیر این صورت به \fIsockets\fR مقید خواهند شد.
اگر SelectType روی select/cons_tres پیکربندی شده باشد، باید پارامتری از نوع CR_Core، CR_Core_Memory، CR_Socket یا CR_Socket_Memory داشته باشد تا این گزینه اعمال شود.
در صورت عدم تعیین، دستور scontrol show job مقدار 'ReqS:C:T=*:*:*' را نمایش می‌دهد.
.br
\fBنکته\fR: این گزینه با \fB\-\-hint\fR، \fB\-\-threads\-per\-core\fR و \fB\-\-ntasks\-per\-core\fR مانعة‌الجمع است (نمی‌توانند هم‌زمان استفاده شوند).
.br
\fBنکته\fR: این گزینه ممکن است به صورت ضمنی تعداد تسک‌ها را (در صورتی که \fB\-n\fR مشخص نشده باشد) به صورت یک تسک به ازای هر رشته درخواستی تنظیم کند.
.IP

.TP
\fB\-\-get\-user\-env\fR
این گزینه به sbatch می‌گوید که متغیرهای محیط ورود به سیستم (login environment) را برای کاربر مشخص‌شده در گزینه \fB\-\-uid\fR بازیابی کند. متغیرهای محیطی با اجرای فرمانی مانند "su \- <username> \-c /usr/bin/env" و تجزیه خروجی آن به دست می‌آیند.
توجه داشته باشید که هر متغیر محیطی که از پیش در محیط sbatch تنظیم شده باشد، بر متغیرهای محیط ورود کاربر اولویت خواهد داشت. متغیرهای محیطی را که نمی‌خواهید به برنامه اجراشده منتقل شوند، پیش از فراخوانی sbatch پاک کنید. اگر بازیابی محیط کاربر با شکست مواجه شود یا مهلت زمانی آن به پایان برسد، کار لغو شده، مجدداً در صف قرار می‌گیرد و نگه داشته می‌شود (held).

\fBنکته\fR: استفاده صریح یا ضمنی از \fB\-\-get\-user\-env\fR به توانایی ایجاد فضاهای نام (namespaces) برای PID و mount متکی است. اکیداً توصیه می‌شود بررسی کنید که قابلیت ایجاد فضای نام PID و mount فعال بوده و محدود نشده باشد (بررسی کنید که \fB/proc/sys/user/max_[pid|mnt]_namespaces\fR مقدار 0 نباشد). اگرچه این موارد برای عملکرد \fB\-\-get\-user\-env\fR کاملاً اجباری نیستند، اما تضمین می‌کنند که پس از بازیابی محیط، هیچ فرآیند یتیمی (orphan process) باقی نماند.
.IP

.TP
\fB\-\-gid\fR=<\fIgroup\fR>
اگر \fBsbatch\fR به عنوان کاربر ریشه (root) اجرا شود و از گزینه \fB\-\-gid\fR استفاده شده باشد، کار با دسترسی‌های گروهیِ \fIgroup\fR ارسال (submit) می‌شود. \fIgroup\fR می‌تواند نام گروه یا شناسه عددی گروه باشد.
.br
\fBنکته\fR: آرگومان \fB\-\-gid\fR منسوخ شده است و در نسخه‌های آینده حذف خواهد شد.
.IP

.TP
\fB\-\-gpu\-bind\fR=[verbose,]<\fItype\fR>
معادل با \-\-tres\-bind=gres/gpu:[verbose,]<\fItype\fR>
برای مشاهده تمامی گزینه‌ها و مستندات، \fB\-\-tres\-bind\fR را ببینید.
.IP

.TP
\fB\-\-gpu\-freq\fR=[<\fItype\fR]=\fIvalue\fR>[,<\fItype\fR=\fIvalue\fR>][,verbose]
درخواست می‌کند که GPUهای تخصیص‌یافته به کار با مقادیر فرکانس خاصی پیکربندی شوند.
این گزینه می‌تواند برای پیکربندی مستقل فرکانس‌های GPU و حافظه آن استفاده شود.
پس از اتمام کار، فرکانس‌های همه GPUهای تحت تأثیر به بالاترین مقادیر ممکن بازنشانی خواهند شد.
در برخی موارد، محدودیت‌های توان مصرفی سیستم (power caps) ممکن است بر مقادیر درخواستی برتری داشته باشند.
فیلد \fItype\fR می‌تواند "memory" باشد.
اگر \fItype\fR مشخص نشود، فرکانس GPU در نظر گرفته می‌شود.
فیلد \fIvalue\fR می‌تواند "low"، "medium"، "high"، "highm1" یا یک مقدار عددی بر حسب مگاهرتز (MHz) باشد.
اگر مقدار عددی مشخص‌شده امکان‌پذیر نباشد، نزدیک‌ترین مقدار ممکن استفاده خواهد شد. برای مشاهده تعاریف مقادیر به بخش زیر مراجعه کنید.
گزینه \fIverbose\fR باعث می‌شود اطلاعات فرکانس فعلی GPU ثبت (log) شود.
نمونه‌های استفاده شامل "\-\-gpu\-freq=medium,memory=high" و "\-\-gpu\-freq=450" است.

تعاریف پشتیبانی‌شده برای \fIvalue\fR:
.IP
.RS
.TP 10
\fBlow\fR
کمترین فرکانس موجود.
.IP

.TP
\fBmedium\fR
تلاش می‌کند تا فرکانسی در میانه محدوده موجود تنظیم کند.
.IP

.TP
\fBhigh\fR
بالاترین فرکانس موجود.
.IP

.TP
\fBhighm1\fR
(بالا منهای یک) فرکانس بعدیِ نزدیک به بالاترین فرکانس موجود را انتخاب می‌کند.
.RE
.IP

.TP
\fB\-G\fR, \fB\-\-gpus\fR=[\fItype\fR:]<\fInumber\fR>
تعداد کل GPUهای مورد نیاز برای کار را مشخص می‌کند.
مشخص کردن نوع GPU به صورت اختیاری امکان‌پذیر است.
برای مثال "\-\-gpus=volta:3".
همچنین به گزینه‌های \fB\-\-gpus\-per\-node\fR، \fB\-\-gpus\-per\-socket\fR و \fB\-\-gpus\-per\-task\fR مراجعه کنید.
.br
\fBنکته\fR: تخصیص منابع باید دست‌کم شامل یک GPU به ازای هر گره، یا در صورت استفاده از انواع مختلف، شامل یکی از هر نوع GPU به ازای هر گره باشد. اگر گره‌های مختلف به انواع متفاوتی از GPU نیاز دارند، از کارهای ناهمگن (heterogeneous jobs) استفاده کنید.
.IP

.TP
\fB\-\-gpus\-per\-node\fR=[\fItype\fR:]<\fInumber\fR>
تعداد GPUهای مورد نیاز برای کار را در هر یک از گره‌های موجود در تخصیص منبع کار مشخص می‌کند.
مشخص کردن نوع GPU به صورت اختیاری امکان‌پذیر است.
برای مثال "\-\-gpus\-per\-node=volta:3".
امکان درخواست چند گزینه در یک فهرست جداشده با کاما وجود دارد، برای نمونه: "\-\-gpus\-per\-node=volta:3,kepler:1".
همچنین به گزینه‌های \fB\-\-gpus\fR، \fB\-\-gpus\-per\-socket\fR و \fB\-\-gpus\-per\-task\fR مراجعه کنید.

\fBنکته\fR: این گزینه با \fB\-\-gres=gpu\fR مانعة‌الجمع است (نمی‌توانند هم‌زمان استفاده شوند).
.IP

.TP
\fB\-\-gpus\-per\-socket\fR=[\fItype\fR:]<\fInumber\fR>
تعداد GPUهای مورد نیاز برای کار را در هر یک از سوکت‌های موجود در تخصیص منبع کار مشخص می‌کند.
مشخص کردن نوع GPU به صورت اختیاری امکان‌پذیر است.
برای مثال "\-\-gpus\-per\-socket=volta:3".
امکان درخواست چند گزینه در یک فهرست جداشده با کاما وجود دارد، برای نمونه: "\-\-gpus\-per\-socket=volta:3,kepler:1".
نیازمند آن است که کار تعداد سوکت‌ها به ازای هر گره (\-\-sockets\-per\-node) را مشخص کند.
همچنین به گزینه‌های \fB\-\-gpus\fR، \fB\-\-gpus\-per\-node\fR و \fB\-\-gpus\-per\-task\fR مراجعه کنید.
.IP

.TP
\fB\-\-gpus\-per\-task\fR=[\fItype\fR:]<\fInumber\fR>
تعداد GPUهای مورد نیاز برای کار را به ازای هر تسکی که قرار است در تخصیص منبع کار اجرا شود، مشخص می‌کند.
مشخص کردن نوع GPU به صورت اختیاری امکان‌پذیر است.
برای مثال "\-\-gpus\-per\-task=volta:1". امکان درخواست چند گزینه در یک فهرست جداشده با کاما وجود دارد، برای نمونه: "\-\-gpus\-per\-task=volta:3,kepler:1". همچنین به گزینه‌های \fB\-\-gpus\fR، \fB\-\-gpus\-per\-socket\fR و \fB\-\-gpus\-per\-node\fR مراجعه کنید.
این گزینه به یک تعداد تسک صریح نیاز دارد، مانند \-n، \-\-ntasks یا "\-\-gpus=X \-\-gpus\-per\-task=Y"، نه یک محدوده نامشخص از گره‌ها با \-N، \-\-nodes.
این گزینه به صورت ضمنی مقدار \-\-tres\-bind=gres/gpu:per_task:<gpus_per_task> را تنظیم می‌کند، یا در صورت تعیین چند نوع GPU، مقدار \-\-tres\-bind=gres/gpu:per_task:<gpus_per_task_type_sum> را تنظیم خواهد کرد. با این حال، می‌توان آن را با تعیین صریح \-\-tres\-bind=gres/gpu بازنویسی کرد.
.br
.IP

.TP
\fB\-\-gres\fR=<\fIlist\fR>
فهرستی جداشده با کاما از منابع مصرفی عمومی (generic consumable resources) درخواست‌شده به ازای هر گره را مشخص می‌کند.
قالب هر ورودی در این فهرست "name[[:type]:count]" است.
مقدار \fIname\fR نوع منبع مصرفی است (مانند gpu).
مقدار \fItype\fR یک طبقه‌بندی اختیاری برای منبع است (مانند a100).
مقدار \fIcount\fR تعداد آن منابع با مقدار پیش‌فرض 1 است.
شمارنده می‌تواند پسوندی از
"k" یا "K" (مضربی از 1024)،
"m" یا "M" (مضربی از 1024 × 1024)،
"g" یا "G" (مضربی از 1024 × 1024 × 1024)،
"t" یا "T" (مضربی از 1024 × 1024 × 1024 × 1024)،
"p" یا "P" (مضربی از 1024 × 1024 × 1024 × 1024 × 1024) داشته باشد.
منابع مشخص‌شده در هر گره به کار تخصیص داده می‌شوند.
منابع مصرفی عمومی موجود توسط مدیر سیستم قابل پیکربندی است.
اگر آرگومان گزینه "help" باشد، فهرستی از منابع مصرفی عمومی موجود چاپ شده و دستور خارج می‌شود.
نمونه‌های استفاده شامل "\-\-gres=gpu:2"، "\-\-gres=gpu:kepler:2" و "\-\-gres=help" است.

\fBنکته\fR: این گزینه با \fB\-\-gpus\-per\-node\fR مانعة‌الجمع است (نمی‌توانند هم‌زمان استفاده شوند)..IP

.TP
\fB\-\-gres\-flags\fR=<\fItype\fR>
گزینه‌های مقیدسازی وظیفه به منابع عمومی (GRES) را مشخص می‌کند.
.IP
.RS

.TP
.B multiple\-tasks\-per\-sharing
گزینهٔ \fBone\-task\-per\-sharing\fR را نقیض (لغو) می‌کند. این گزینه زمانی مفید است که این ویژگی به‌طور پیش‌فرض در \fBSelectTypeParameters\fR تنظیم شده باشد.
.IP

.TP
.B disable\-binding
گزینهٔ \fBenforce\-binding\fR را نقیض (لغو) می‌کند. این گزینه زمانی مفید است که این ویژگی به‌طور پیش‌فرض در \fBSelectTypeParameters\fR تنظیم شده باشد.
.IP

.TP
.B enforce\-binding
تنها CPUهایی در دسترس کار خواهند بود که به GRES انتخاب‌شده مقید باشند (یعنی CPUهای مشخص‌شده در فایل gres.conf به طور سخت‌گیرانه اعمال خواهند شد). این گزینه ممکن است باعث تأخیر در آغاز کار شود.
برای مثال، کاری که نیازمند دو GPU و یک CPU است، تا زمانی که هر دو GPU روی یک سوکت واحد در دسترس نباشند به تأخیر می‌افتد، به جای اینکه از GPUهای مقید به سوکت‌های مجزا استفاده کند؛ با این حال، کارایی برنامه به دلیل بهبود سرعت ارتباطات ممکن است ارتقا یابد.
نیازمند آن است که گره با بیش از یک سوکت پیکربندی شده باشد و پالایش منبع بر مبنای هر سوکت انجام خواهد شد.
.br
\fBنکته\fR: این گزینه می‌تواند به‌طور پیش‌فرض در \fBSelectTypeParameters\fR تنظیم شود.
.br
\fBنکته\fR: این گزینه مختص \fBSelectType=cons_tres\fR است.
.br
\fBنکته\fR: در صورت تلاش برای اعمال مقیدسازی روی چندین gres در چندین سوکت، این گزینه ممکن است نتایج نامشخصی در پی داشته باشد.
.IP

.TP
.B one\-task\-per\-sharing
اجازه نمی‌دهد به وظایف مختلف، gres اشتراکی از یک منبع اشتراکی یکسان تخصیص داده شود.
.br
\fBنکته\fR: این پرچم تنها در صورتی اعمال می‌شود که gresهای اشتراکی با \-\-tres\-per\-task درخواست شده باشند.
.br
\fBنکته\fR: این گزینه می‌تواند به‌طور پیش‌فرض با \fBSelectTypeParameters=ONE_TASK_PER_SHARING_GRES\fR تنظیم شود.
.br
\fBنکته\fR: این گزینه مختص \fBSelectTypeParameters=MULTIPLE_SHARING_GRES_PJ\fR است.
.RE
.IP

.TP
\fB\-h\fR, \fB\-\-help\fR
اطلاعات راهنما را نمایش داده و خارج می‌شود.
.IP

.TP
\fB\-\-hint\fR=<\fItype\fR>
وظایف را با توجه به رهنمودهای برنامه (application hints) مقید می‌کند.
.br
\fBنکته\fR: این گزینه متضمن مقادیر خاصی برای برخی گزینه‌های مرتبط است، که مانع از استفادهٔ هم‌زمان آن با هر مقدار تعیین‌شده توسط کاربر برای \fB\-\-ntasks\-per\-core\fR، \fB\-\-cores\-per\-socket\fR، \fB\-\-sockets\-per\-node\fR، \fB\-\-threads\-per\-core\fR یا \fB\-B\fR می‌شود.
این گزینه‌های متعارض در صورت مشخص شدن به عنوان آرگومان‌های خط فرمان، بر \fB\-\-hint\fR تقدم خواهند داشت و آن را بازنویسی می‌کنند. اگر یک گزینهٔ متعارض به عنوان متغیر محیطی تعیین شده باشد، \-\-hint به عنوان آرگومان خط فرمان اولویت خواهد داشت.
.IP
.RS
.TP
.B compute_bound
تنظیمات برنامه‌های وابسته به پردازش (compute bound) را انتخاب می‌کند:
استفاده از تمام هسته‌ها در هر سوکت، یک نخ به ازای هر هسته.
.IP

.TP
.B memory_bound
تنظیمات برنامه‌های وابسته به حافظه (memory bound) را انتخاب می‌کند:
استفاده از تنها یک هسته در هر سوکت، یک نخ به ازای هر هسته.
.IP

.TP
.B multithread
استفاده از نخ‌های اضافی همراه با چندنخی درون‌هسته‌ای (in\-core multi\-threading) که می‌تواند برای برنامه‌های با ارتباطات فشرده مفید باشد.
تنها با افزونهٔ task/affinity پشتیبانی می‌شود.
.IP

.TP
.B nomultithread
عدم استفاده از نخ‌های اضافی با چندنخی درون‌هسته‌ای؛ وظایف را به یک نخ به ازای هر هسته محدود می‌کند.
تنها با افزونهٔ task/affinity پشتیبانی می‌شود.
.IP

.TP
.B help
این پیام راهنما را نمایش می‌دهد
.RE
.IP

.TP
\fB\-H, \-\-hold\fR
مشخص می‌کند که کار باید در وضعیت نگه‌داشته‌شده (held با اولویت صفر) ارسال شود.
یک کار نگه‌داشته‌شده می‌تواند بعداً با استفاده از scontrol برای بازنشانی اولویتش آزاد شود (مانند «\fIscontrol release <job_id>\fR»).
.IP

.TP
\fB\-\-ignore\-pbs\fR
تمامی گزینه‌های «#PBS» و «#BSUB» مشخص‌شده در اسکریپت دسته‌ای (batch script) را نادیده می‌گیرد.
.IP

.TP
\fB\-i\fR, \fB\-\-input\fR=<\fIfilename_pattern\fR>
به Slurm دستور می‌دهد تا ورودی استاندارد اسکریپت دسته‌ای را مستقیماً به نام فایل مشخص‌شده در «\fIfilename pattern\fR» متصل کند.

به‌طور پیش‌فرض، «/dev/null» روی ورودی استاندارد اسکریپت دسته‌ای باز است و خروجی استاندارد و خطای استاندارد هر دو به فایلی با نام «slurm\-%j.out» هدایت می‌شوند که در آن «%j» با شمارهٔ تخصیص کار جایگزین می‌شود، همان‌طور که در ادامه در بخش \fBfilename pattern\fR شرح داده شده است.
.IP

.TP
\fB\-J\fR, \fB\-\-job\-name\fR=<\fIjobname\fR>
نامی را برای تخصیص کار مشخص می‌کند. نام تعیین‌شده هنگام استعلام کارهای در حال اجرا در سیستم، در کنار شمارهٔ شناسهٔ کار (job ID) نمایش داده خواهد شد. مقدار پیش‌فرض، نام اسکریپت دسته‌ای است یا در صورتی که اسکریپت از ورودی استاندارد sbatch خوانده شود، صرفاً «sbatch» خواهد بود.
.IP

.TP
\fB\-\-kill\-on\-invalid\-dep\fR=<yes|no>
اگر کاری وابستگی نامعتبری داشته باشد و هرگز نتواند اجرا شود، این پارامتر به Slurm مشخص می‌کند که آن را خاتمه دهد یا خیر. وضعیت یک کار خاتمه‌یافته JOB_CANCELLED خواهد بود.
اگر این گزینه مشخص نشود، رفتار سراسری سیستم اعمال می‌شود.
به‌طور پیش‌فرض، کار با علت DependencyNeverSatisfied در حالت معلق (pending) باقی می‌ماند، یا اگر kill_invalid_depend در slurm.conf مشخص شده باشد، کار خاتمه می‌یابد.
.IP

.TP
\fB\-L\fR, \fB\-\-licenses\fR=<\fIlicense\fR>[@\fIdb\fR][:\fIcount\fR][,\fIlicense\fR[@\fIdb\fR][:\fIcount\fR]...]
تعیین مجوزها (یا سایر منابع موجود در تمامی گره‌های خوشه) که باید به این کار تخصیص داده شوند.
نام‌های مجوز می‌توانند با یک دونقطه و تعداد همراه باشند (تعداد پیش‌فرض یک است).
می‌توان چندین مجوز را درخواست کرد. اگر آن‌ها با ویرگول جدا شوند (',' به معنای AND)، آن‌گاه تمامی مجوزهای درخواستی برای کار لازم خواهند بود؛ برای مثال «\-\-licenses=foo:4,bar». اگر با خط لوله جدا شوند ('|' به معنای OR)، آن‌گاه تنها یکی از درخواست‌های مجوز برای کار مورد نیاز است؛ برای مثال «\-\-licenses=foo:4|bar». امکان استفاده هم‌زمان از AND و OR وجود ندارد.
برای ارسال کارهایی که از مجوزهای راه دور (مجوزهایی که توسط slurmdbd ارائه می‌شوند) استفاده می‌کنند، نام سرور ارائه‌دهندهٔ مجوزها را مشخص کنید؛ برای مثال «\-\-license=nastran@slurmdb:12». اگر \fBLicenseParameters=RemoteFuzzyMatch\fR در slurm.conf تنظیم شده باشد، می‌توان از ذکر نام سرور صرف‌نظر کرد.

\fBنکته\fR: هنگام ارسال کارهای ناهمگن (heterogeneous jobs)، درخواست مجوز فقط می‌تواند روی مؤلفهٔ نخست کار انجام شود؛ برای مثال «sbatch \-L ansys:2 : script.sh».

\fBنکته\fR: اگر مجوزها در AccountingStorageTres ردیابی شوند و از OR استفاده شده باشد، مقدار ReqTRES تمام tresهای درخواستی را به صورت جداشده با ویرگول نمایش می‌دهد. AllocTRES تنها مجوزی را نمایش می‌دهد که به کار تخصیص یافته است.

\fBنکته\fR: هنگامی که یک کار مجوزهایی را با منطق OR درخواست می‌کند، Slurm تلاش خواهد کرد تا مجوزها را به ترتیبی که درخواست شده‌اند تخصیص دهد. این ترتیب تعیین‌شده اولویت خواهد داشت، حتی اگر مابقی مجوزهای درخواستی بر روی یک رزروِ درخواست‌شده قابل برآورده شدن باشند. این موضوع در برنامه‌ریزی backfill در زمانی که \fBSchedulerParameters=bf_licenses\fR پیکربندی شده باشد نیز صدق می‌کند.
.IP

.TP
\fB\-\-mail\-type\fR=<\fItype\fR>
هنگام رخ دادن انواع خاصی از رویدادها، کاربر را از طریق ایمیل مطلع می‌کند.
مقادیر معتبر \fItype\fR عبارتند از: NONE، BEGIN، END، FAIL، REQUEUE، ALL (معادل BEGIN، END، FAIL، INVALID_DEPEND، REQUEUE و STAGE_OUT)، INVALID_DEPEND (وابستگی هرگز برآورده نشود)، STAGE_OUT (مرحله‌بندی خروجی و آزادسازی burst buffer کامل شود)، TIME_LIMIT، TIME_LIMIT_90 (رسیدن به ۹۰ درصد محدودیت زمانی)، TIME_LIMIT_80 (رسیدن به ۸۰ درصد محدودیت زمانی)، TIME_LIMIT_50 (رسیدن به ۵۰ درصد محدودیت زمانی) و ARRAY_TASKS (ارسال ایمیل برای هر وظیفه از آرایه).
چندین مقدار \fItype\fR را می‌توان در یک فهرست جداشده با ویرگول مشخص کرد.
مقدار NONE تمام اعلان‌های رویداد را سرکوب کرده و هر مقدار دیگر مشخص‌شده را نادیده می‌گیرد.
به‌طور پیش‌فرض هیچ اعلان ایمیلی ارسال نمی‌شود.
کاربری که باید مطلع شود با \fB\-\-mail\-user\fR مشخص می‌گردد.

مگر اینکه گزینهٔ ARRAY_TASKS مشخص شده باشد، اعلان‌های ایمیلی هنگام BEGIN، END، FAIL و REQUEUE کار، به کل آرایهٔ کاری (job array) اعمال می‌شوند نه اینکه برای هر وظیفه در آرایهٔ کاری ایمیل‌های جداگانه‌ای ایجاد کنند.
.IP

.TP
\fB\-\-mail\-user\fR=<\fIuser\fR>
کاربری که اعلان ایمیلی تغییرات وضعیت را مطابق با تعریف \fB\-\-mail\-type\fR دریافت می‌کند. این مقدار می‌تواند یک نشانی ایمیل کامل یا یک نام کاربری باشد. اگر یک نام کاربری مشخص شود، مقدار \fBMailDomain\fR در slurm.conf برای ایجاد یک نشانی ایمیل به انتهای آن اضافه خواهد شد.
مقدار پیش‌فرض، کاربر ارسال‌کننده است..IP

.TP
\fB\-\-mcs\-label\fR=<\fImcs\fR>
تنها زمانی استفاده می‌شود که یک \fBMCSPlugin\fR سازگار فعال باشد. این پارامتر گروهی است که کاربر به آن تعلق دارد (\fBmcs/group\fR) یا یک رشته برچسب دلخواه (\fBmcs/label\fR). در هر دو حالت، به‌طور پیش‌فرض هیچ برچسبی اختصاص داده نخواهد شد. برای جزئیات بیشتر به مستندات MCS مراجعه کنید: <https://slurm.schedmd.com/mcs.html>
.IP

.TP
\fB\-\-mem\fR=<\fIsize\fR>[\fIunits\fR]
حافظه واقعی مورد نیاز به ازای هر گره (node) را مشخص می‌کند.
واحدهای پیش‌فرض مبی‌بایت (mebibytes) هستند.
واحدهای مختلف را می‌توان با استفاده از پسوند [K|M|G|T] مشخص کرد.
مقدار پیش‌فرض \fBDefMemPerNode\fR و حداکثر مقدار \fBMaxMemPerNode\fR است. در صورت پیکربندی، هر دو پارامتر را می‌توان با استفاده از دستور \fBscontrol show config\fR مشاهده کرد.
این پارامتر عموماً زمانی استفاده می‌شود که کل گره‌ها به کارها اختصاص داده شوند (\fBSelectType=select/linear\fR).
همچنین به \fB\-\-mem\-per\-cpu\fR و \fB\-\-mem\-per\-gpu\fR مراجعه کنید.
گزینه‌های \fB\-\-mem\fR، \fB\-\-mem\-per\-cpu\fR و \fB\-\-mem\-per\-gpu\fR مانعة‌الجمع هستند. اگر \fB\-\-mem\fR، \fB\-\-mem\-per\-cpu\fR یا \fB\-\-mem\-per\-gpu\fR به‌عنوان آرگومان‌های خط فرمان مشخص شوند، بر متغیرهای محیطی اولویت خواهند داشت.

\fBنکته\fR: تعیین اندازه حافظه برابر با صفر به عنوان یک حالت خاص در نظر گرفته می‌شود و به کار اجازه دسترسی به تمام حافظه موجود در هر گره را می‌دهد.

\fBنکته\fR: حافظه مصرفی توسط هر فرایند slurmstepd در مجموع حافظه مصرفی کار محاسبه می‌شود. این حافظه معمولاً بین 20MiB تا 200MiB مصرف می‌کند، هرچند بسته به پیکربندی سیستم و پلاگین‌های بارگذاری‌شده می‌تواند متغیر باشد.

\fBنکته\fR: درخواست‌های حافظه به‌طور سخت‌گیرانه اعمال نخواهند شد مگر اینکه Slurm برای استفاده از یک مکانیزم اجباری پیکربندی شده باشد. برای جزئیات بیشتر به \fBConstrainRAMSpace\fR در صفحه راهنمای \fBcgroup.conf\fR(5) و \fBOverMemoryKill\fR در صفحه راهنمای \fBslurm.conf\fR(5) مراجعه کنید.
.IP

.TP
\fB\-\-mem\-bind\fR=[{quiet|verbose},]<\fItype\fR>
اتصال (Bind) تسک‌ها به حافظه. تنها زمانی استفاده می‌شود که پلاگین task/affinity فعال بوده و توابع حافظه NUMA در دسترس باشند.
\fBتوجه داشته باشید که تفکیک‌پذیری اتصال پردازنده و حافظه ممکن است در برخی معماری‌ها متفاوت باشد.\fR برای مثال، اتصال پردازنده ممکن است در سطح هسته‌های درون یک پردازنده انجام شود در حالی که اتصال حافظه در سطح گره‌ها انجام خواهد شد، جایی که تعریف «گره‌ها» ممکن است از سیستمی به سیستم دیگر تفاوت داشته باشد.
به‌طور پیش‌فرض هیچ اتصالی به حافظه انجام نمی‌شود؛ هر تسکی با استفاده از هر پردازنده‌ای می‌تواند از هر حافظه‌ای استفاده کند. این گزینه معمولاً برای اطمینان از اینکه هر تسک به نزدیک‌ترین حافظه به پردازنده تخصیص‌یافته‌اش متصل شده است به کار می‌رود. \fBاستفاده از هر نوعی غیر از "none" یا "local" توصیه نمی‌شود.\fR

\fBنکته\fR: برای اینکه Slurm همیشه اتصال حافظه انتخاب‌شده را برای تمام دستورات اجرا شده در پوسته گزارش کند، می‌توانید با تنظیم مقدار متغیر محیطی SLURM_MEM_BIND روی "verbose"، حالت پرگو (verbose) را فعال کنید.

متغیرهای محیطی اطلاعاتی زیر هنگام استفاده از \fB\-\-mem\-bind\fR تنظیم می‌شوند:
.IP
.nf
   SLURM_MEM_BIND_LIST
   SLURM_MEM_BIND_PREFER
   SLURM_MEM_BIND_TYPE
   SLURM_MEM_BIND_VERBOSE
.fi

برای شرح دقیق‌تر هر یک از متغیرهای SLURM_MEM_BIND* به بخش \fBمتغیرهای محیطی (ENVIRONMENT VARIABLES)\fR مراجعه کنید.

گزینه‌های پشتیبانی‌شده عبارتند از:
.IP
.RS
.TP
.B help
نمایش این پیام راهنما
.IP

.TP
.B local
استفاده از حافظه محلی مربوط به پردازنده در حال استفاده
.IP

.TP
.B map_mem:<list>
اتصال با تنظیم ماسک‌های حافظه روی تسک‌ها (یا rankها) مطابق با مشخصات؛ جایی که <list> به صورت زیر است:
<numa_id_for_task_0>,<numa_id_for_task_1>,...
این نگاشت برای یک گره مشخص می‌شود و نگاشت یکسانی روی تسک‌های هر گره اعمال می‌گردد (یعنی کمترین شناسه تسک در هر گره به اولین شناسه مشخص‌شده در فهرست نگاشت می‌شود و الی آخر).
شناسه‌های NUMA به صورت مقادیر ده‌دهی (decimal) تفسیر می‌شوند مگر اینکه با '0x' شروع شوند که در این صورت به عنوان مقادیر شانزده‌شانزدهی (hexadecimal) تفسیر خواهند شد.
اگر تعداد تسک‌ها (یا rankها) بیشتر از تعداد عناصر موجود در این فهرست باشد، عناصر فهرست در صورت نیاز از ابتدای فهرست دوباره استفاده خواهند شد.
برای ساده‌سازی پشتیبانی از تعداد زیاد تسک‌ها، فهرست‌ها می‌توانند پس از یک نگاشت شامل علامت ستاره و شمارش تکرار باشند.
به عنوان مثال "map_mem:0x0f*4,0xf0*4".
برای دستیابی به نتایج اتصال قابل پیش‌بینی، تمام پردازنده‌های هر گره باید به کار تخصیص داده شوند.
.IP

.TP
.B mask_mem:<list>
اتصال با تنظیم ماسک‌های حافظه روی تسک‌ها (یا rankها) مطابق با مشخصات؛ جایی که <list> به صورت زیر است:
<numa_mask_for_task_0>,<numa_mask_for_task_1>,...
این نگاشت برای یک گره مشخص می‌شود و نگاشت یکسانی روی تسک‌های هر گره اعمال می‌گردد (یعنی کمترین شناسه تسک در هر گره به اولین ماسک مشخص‌شده در فهرست نگاشت می‌شود و الی آخر).
ماسک‌های NUMA \fBهمیشه\fR به عنوان مقادیر شانزده‌شانزدهی تفسیر می‌شوند.
توجه داشته باشید که اگر ماسک‌ها با [0\-9] شروع نمی‌شوند، باید پیشوند '0x' داشته باشند تا به عنوان مقادیر عددی شناخته شوند.
اگر تعداد تسک‌ها (یا rankها) بیشتر از تعداد عناصر موجود در این فهرست باشد، عناصر فهرست در صورت نیاز از ابتدای فهرست دوباره استفاده خواهند شد.
برای ساده‌سازی پشتیبانی از تعداد زیاد تسک‌ها، فهرست‌ها می‌توانند پس از یک ماسک شامل علامت ستاره و شمارش تکرار باشند.
به عنوان مثال "mask_mem:0*4,1*4".
برای دستیابی به نتایج اتصال قابل پیش‌بینی، تمام پردازنده‌های هر گره باید به کار تخصیص داده شوند.
.IP

.TP
.B no[ne]
عدم اتصال تسک‌ها به حافظه (پیش‌فرض)
.IP

.TP
.B p[refer]
ترجیح دادن استفاده از اولین گره NUMA مشخص‌شده، اما مجاز دانستن استفاده از سایر گره‌های NUMA موجود.
.IP

.TP
.B q[uiet]
اتصال در حالت بی‌صدا قبل از اجرای تسک (پیش‌فرض)
.IP

.TP
.B rank
اتصال بر اساس رتبه تسک (task rank) (توصیه نمی‌شود)
.IP

.TP
.B v[erbose]
گزارش اتصال با جزئیات کامل پیش از اجرای تسک
.RE
.IP

.TP
\fB\-\-mem\-per\-cpu\fR=<\fIsize\fR>[\fIunits\fR]
حداقل حافظه مورد نیاز به ازای هر پردازنده تخصیص‌یافته و قابل استفاده.
واحدهای پیش‌فرض مبی‌بایت هستند.
مقدار پیش‌فرض \fBDefMemPerCPU\fR و حداکثر مقدار \fBMaxMemPerCPU\fR است (استثنای زیر را ببینید). در صورت پیکربندی، هر دو پارامتر را می‌توان با استفاده از دستور \fBscontrol show config\fR مشاهده کرد.
توجه داشته باشید که اگر مقدار \fB\-\-mem\-per\-cpu\fR کار فراتر از مقدار پیکربندی‌شده \fBMaxMemPerCPU\fR باشد، حد تعیین‌شده توسط کاربر به عنوان حد حافظه به ازای تسک در نظر گرفته خواهد شد؛ مقدار \fB\-\-mem\-per\-cpu\fR به مقداری کاهش می‌یابد که بیشتر از \fBMaxMemPerCPU\fR نباشد؛ \fB\-\-cpus\-per\-task\fR تنظیم می‌شود و مقدار \fB\-\-cpus\-per\-task\fR ضرب در مقدار جدید \fB\-\-mem\-per\-cpu\fR برابر با مقدار اولیه \fB\-\-mem\-per\-cpu\fR مشخص‌شده توسط کاربر خواهد بود.
این پارامتر عموماً زمانی استفاده می‌شود که پردازنده‌های مجزا به کارها اختصاص داده شوند (\fBSelectType=select/cons_tres\fR).
اگر منابع بر اساس هسته (core)، سوکت (socket) یا کل گره‌ها تخصیص یابند، تعداد پردازنده‌های اختصاص‌یافته به یک کار ممکن است بیشتر از تعداد تسک‌ها باشد و مقدار \fB\-\-mem\-per\-cpu\fR باید بر این اساس تنظیم شود.
همچنین به \fB\-\-mem\fR و \fB\-\-mem\-per\-gpu\fR مراجعه کنید.
گزینه‌های \fB\-\-mem\fR، \fB\-\-mem\-per\-cpu\fR و \fB\-\-mem\-per\-gpu\fR مانعة‌الجمع هستند.

\fBنکته\fR: اگر مقدار نهایی حافظه درخواستی توسط یک کار، توسط هیچ‌یک از گره‌های پیکربندی‌شده در پارتیشن برآورده نشود، کار رد خواهد شد.
این مسئله می‌تواند زمانی رخ دهد که \fB\-\-mem\-per\-cpu\fR با گزینه \fB\-\-exclusive\fR برای یک تخصیص کار استفاده شود و حاصل‌ضرب \fB\-\-mem\-per\-cpu\fR در تعداد پردازنده‌های یک گره بیشتر از کل حافظه آن گره باشد.

\fBنکته\fR: این مورد برای پردازنده‌های تخصیص‌یافته \fBقابل استفاده\fR در یک تخصیص کار اعمال می‌شود.
این نکته زمانی که بیش از یک ریسه (thread) به ازای هر هسته پیکربندی شده باشد حائز اهمیت است.
اگر یک کار با استفاده از \-\-threads\-per\-core ریسه‌های کمتری را نسبت به ریسه‌های موجود روی یک هسته درخواست کند (یا با \-\-hint=nomultithread که به معنی \-\-threads\-per\-core=1 است)، کار قادر به استفاده از آن ریسه‌های اضافی روی هسته نخواهد بود و آن ریسه‌ها در محاسبه حافظه به ازای پردازنده لحاظ نمی‌شوند. اما اگر کار به تمام ریسه‌های روی هسته دسترسی داشته باشد، آن ریسه‌ها در محاسبه حافظه به ازای پردازنده گنجانده خواهند شد، حتی اگر کار صراحتاً آن ریسه‌ها را درخواست نکرده باشد.

در مثال‌های زیر، هر هسته دارای دو ریسه است.

در این مثال نخست، دو تسک می‌توانند روی هایپرتریدهای مجزا در همان هسته اجرا شوند زیرا از \-\-threads\-per\-core استفاده نشده است. تسک سوم از هر دو ریسه هسته دوم استفاده می‌کند. حافظه تخصیص‌یافته به ازای پردازنده شامل تمام ریسه‌ها می‌شود:

.nf
.ft B
$ salloc \-n3 \-\-mem\-per\-cpu=100
salloc: Granted job allocation 17199
$ sacct \-j $SLURM_JOB_ID \-X \-o jobid%7,reqtres%35,alloctres%35
  JobID                             ReqTRES                           AllocTRES
\-\-\-\-\-\-\- \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
  17199     billing=3,cpu=3,mem=300M,node=1     billing=4,cpu=4,mem=400M,node=1
.ft
.fi

در این مثال دوم، به دلیل \-\-threads\-per\-core=1، به هر تسک یک هسته کامل اختصاص داده می‌شود اما تنها قادر به استفاده از یک ریسه در هر هسته است. پردازنده‌های تخصیص‌یافته شامل تمام ریسه‌ها در هر هسته می‌شوند. با این حال، حافظه تخصیص‌یافته به ازای پردازنده تنها شامل ریسه قابل استفاده در هر هسته است.

.nf
.ft B
$ salloc \-n3 \-\-mem\-per\-cpu=100 \-\-threads\-per\-core=1
salloc: Granted job allocation 17200
$ sacct \-j $SLURM_JOB_ID \-X \-o jobid%7,reqtres%35,alloctres%35
  JobID                             ReqTRES                           AllocTRES
\-\-\-\-\-\-\- \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\- \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
  17200     billing=3,cpu=3,mem=300M,node=1     billing=6,cpu=6,mem=300M,node=1
.ft
.fi.IP

.TP
\fB\-\-mem\-per\-gpu\fR=<\fIsize\fR>[\fIunits\fR]
حداقل حافظهٔ مورد نیاز به ازای هر GPU تخصیص‌یافته.
واحدهای پیش‌فرض، مبی‌بایت (mebibytes) هستند.
واحدهای مختلف را می‌توان با استفاده از پسوند [K|M|G|T] تعیین کرد.
مقدار پیش‌فرض \fBDefMemPerGPU\fR است و هم به‌صورت سراسری و هم بر مبنای هر پارتیشن در دسترس است.
در صورت پیکربندی، این پارامترها با استفاده از دستورهای \fBscontrol show config\fR
و \fBscontrol show partition\fR قابل مشاهده هستند.
همچنین \fB\-\-mem\fR را ببینید.
گزینه‌های \fB\-\-mem\fR، \fB\-\-mem\-per\-cpu\fR و \fB\-\-mem\-per\-gpu\fR
مانعة‌الجمع (ناسازگار با یکدیگر) هستند.
.IP

.TP
\fB\-\-mem\-update\fR=<\fImargin\fR>@<\fIdelay\fR>
کاهش خودکار محدودیت حافظهٔ کار پس از سپری شدن مدت زمان مشخص‌شده توسط \fIdelay\fR
از اجرای آن. محدودیت جدید روی مقدار مصرف حافظهٔ فعلیِ کار به علاوهٔ \fImargin\fR
درصد تنظیم می‌شود. مقدار \fImargin\fR یک درصد است (به‌عنوان مثال، ۲۰ یعنی ۲۰٪
بالاتر از مصرف فعلی). پارامتر \fIdelay\fR مشخص می‌کند که چه مدت پس از شروع کار،
از میزان مصرف حافظه نمونه‌برداری شده و کاهش اعمال شود.
قالب‌های زمانی قابل قبول برای \fIdelay\fR شامل "minutes" ،"minutes:seconds" ،
"hours:minutes:seconds" ،"days\-hours" ،"days\-hours:minutes" و
"days\-hours:minutes:seconds" است.
محدودیت حافظه فقط می‌تواند کاهش یابد و هرگز افزایش نمی‌یابد. اگر محدودیت
جدیدِ محاسبه‌شده کمتر از محدودیت فعلی نباشد، هیچ تغییری اعمال نمی‌شود. کف ۱۰٪
از درخواست اولیهٔ حافظه اعمال می‌شود تا از کاهش محدودیت به مقداری بیش از اندازه
کوچک جلوگیری شود.
میزان مصرف حافظه فقط بر حسب RSS (حافظهٔ فیزیکی مقیم) اندازه‌گیری می‌شود؛ مصرف swap
لحاظ نمی‌گردد. هنگامی که \fBConstrainSwapSpace\fR پیکربندی شده باشد، محدودیت
فضای swap نیز متناسب با محدودیت حافظه کاهش می‌یابد.
این گزینه برای کارهای دارای هر دو تنظیم \fB\-\-mem\fR و \fB\-\-mem\-per\-cpu\fR
کار می‌کند. برای کارهای \fB\-\-mem\-per\-cpu\fR، محدودیت جدید به‌عنوان مقداری
به ازای هر گره (per\-node)، در مقایسه با بیشترین تخصیص به ازای هر گره در سراسر
تمامی گره‌ها اعمال می‌شود.
این یک عملیات یک‌باره است: کاهش حداکثر یک بار در طول اجرای کار اعمال می‌شود.
در صورت صف‌بندی مجدد کار (requeue)، کاهش خودکار ممکن است دوباره راه‌اندازی شود.
این گزینه نیازمند پیکربندی \fBSlurmctldParameters=enable_stepmgr\fR و
\fBJobAcctGatherType=jobacct_gather/cgroup\fR است.
.IP

.TP
\fB\-\-mincpus\fR=<\fIn\fR>
حداقل تعداد cpuها/پردازنده‌های منطقی به ازای هر گره را مشخص می‌کند.
.IP

.TP
\fB\-\-network\fR=<\fItype\fR>
مشخص کردن اطلاعات مربوط به سوئیچ یا شبکه.
تفسیر \fItype\fR وابسته به سیستم است.

گزینهٔ \fBnetwork\fR در سیستم‌های دارای شبکه‌های HPE Slingshot در دسترس است.
می‌توان از آن برای درخواست یک VNI کار (جهت استفاده برای ارتباط میان گام‌های
کاری در یک کار) استفاده کرد. همچنین می‌توان از آن برای بازنویسی منابع شبکهٔ
پیش‌فرضی که برای گام کاری تخصیص یافته است، استفاده نمود. می‌توان مقادیر متعدد
را در یک فهرست جداشده با کاما مشخص کرد.
.IP
.RS
.TP 6
\fBtcs\fR=<\fIclass1\fR>[:<\fIclass2\fR>]...
مجموعه‌ای از کلاس‌های ترافیک برای پیکربندی برنامه‌ها.
کلاس‌های ترافیک پشتیبانی‌شده عبارتند از DEDICATED_ACCESS ،LOW_LATENCY ،BULK_DATA
و BEST_EFFORT. این کلاس‌های ترافیک را می‌توان به‌صورت TC_DEDICATED_ACCESS ،
TC_LOW_LATENCY ،TC_BULK_DATA و TC_BEST_EFFORT نیز مشخص کرد.
.IP

.TP
\fBno_vni\fR
هیچ VNIای برای این کار تخصیص داده نشود (حتی اگر چندگره‌ای باشد).
.IP

.TP
\fBjob_vni\fR
تخصیص یک VNI کار برای این کار.
.IP

.TP
\fBsingle_node_vni\fR
تخصیص یک VNI کار برای این کار، حتی اگر یک کار تک‌گره‌ای باشد.
.IP

.TP
\fBadjust_limits\fR
در صورت تنظیم، slurmd با کم کردن مقادیر رزروشده یا مصرف‌شده (هرکدام که بیشتر باشد)
برای هر یک از خدمات شبکهٔ سیستمی از حداکثر مقدار منبع به ازای هر NIC، کران بالایی
برای رزرو منابع شبکه تعیین می‌کند؛ این حالت پیش‌فرض است.
.IP

.TP
\fBno_adjust_limits\fR
در صورت تنظیم، slurmd رزرو منابع شبکه را صرفاً بر مبنای مقدار پیش‌فرضِ پیکربندی
هر منبع و تعداد تسک‌های موجود در برنامه محاسبه می‌کند؛ این گزینه کران بالایی برای
آن درخواست‌های رزرو بر اساس مصرف منابع توسط خدمات شبکهٔ سیستمیِ از پیش موجود تعیین
نخواهد کرد. تنظیم این گزینه بدین معناست که ممکن است راه‌اندازی برنامه‌های بیشتری به دلیل
اتمام منابع شبکه با شکست مواجه شود، اما اگر برنامه برای کارکرد خود حتماً به مقدار
معینی از منابع نیاز داشته باشد، این گزینه آن را تضمین خواهد کرد.
.IP

.TP
\fBdisable_rdzv_get\fR
غیرفعال کردن rendezvous getها در NICهای Slingshot، که می‌تواند کارایی برخی
برنامه‌ها را بهبود بخشد.
.IP

.TP
\fBnic_distribution_count\fR=<\fIval\fR>
تعداد NICهایی که کاربر تسک‌های خود را به‌طور مساوی روی آن‌ها توزیع خواهد کرد.
مقدار پیش‌فرض برابر با تعداد NICها در هر گره است.
.IP

.TP
\fBdef_<rsrc>\fR=<\fIval\fR>
تخصیص رزروشده به ازای هر CPU برای این منبع.
.IP

.TP
\fBres_<rsrc>\fR=<\fIval\fR>
تخصیص رزروشده به ازای هر گره برای این منبع.
در صورت تنظیم، تخصیص به ازای هر CPU را لغو و بازنویسی می‌کند.
.IP

.TP
\fBmax_<rsrc>\fR=<\fIval\fR>
حداکثر حد مجاز به ازای هر گره برای این منبع.
.IP

.TP
\fBdepth\fR=<\fIdepth\fR>
ضریب برای تخصیص منابع به ازای هر CPU.
مقدار پیش‌فرض برابر با تعداد CPUهای رزروشده در گره است.
.RE
.IP

منابعی که می‌توان درخواست کرد عبارتند از:
.IP
.RS
.TP 6
\fBtxqs\fR
صف‌های فرمان ارسال (Transmit command queues). مقدار پیش‌فرض ۲ به ازای هر CPU و حداکثر ۱۰۲۴ به ازای هر گره است.
.IP

.TP
\fBtgqs\fR
صف‌های فرمان مقصد (Target command queues). مقدار پیش‌فرض ۱ به ازای هر CPU و حداکثر ۵۱۲ به ازای هر گره است.
.IP

.TP
\fBeqs\fR
صف‌های رویداد (Event queues). مقدار پیش‌فرض ۲ به ازای هر CPU و حداکثر ۲۰۴۷ به ازای هر گره است.
.IP

.TP
\fBcts\fR
شمارنده‌ها (Counters). مقدار پیش‌فرض ۱ به ازای هر CPU و حداکثر ۲۰۴۷ به ازای هر گره است.
.IP

.TP
\fBtles\fR
مدخل‌های فهرست تریگر (Trigger list entries). مقدار پیش‌فرض ۱ به ازای هر CPU و حداکثر ۲۰۴۸ به ازای هر گره است.
.IP

.TP
\fBptes\fR
مدخل‌های جدول پرتابل (Portable table entries). مقدار پیش‌فرض ۶ به ازای هر CPU و حداکثر ۲۰۴۸ به ازای هر گره است.
.IP

.TP
\fBles\fR
مدخل‌های فهرست (List entries). مقدار پیش‌فرض ۱۶ به ازای هر CPU و حداکثر ۱۶۳۸۴ به ازای هر گره است.
.IP

.TP
\fBacs\fR
زمینه‌های آدرس‌دهی (Addressing contexts). مقدار پیش‌فرض ۲ به ازای هر CPU و حداکثر ۱۰۲۲ به ازای هر گره است.
.RE
.IP

در سیستم‌هایی که با \fBSwitchType=switch/nvidia_imex\fR پیکربندی شده‌اند،
گزینه‌های زیر پشتیبانی می‌شوند:
.RS
.TP
\fBunique-channel-per-segment\fR
به‌جای یک کانال برای کل کار، یک کانال به ازای هر سگمنت در کار تخصیص داده می‌شود.
این مورد تنها زمانی اعمال می‌گردد که \fBtopology/block\fR پیکربندی شده باشد.
.RE
.IP

.IP

.TP
\fB\-\-nice\fR[=\fIadjustment\fR]
اجرای کار با یک اولویت زمان‌بندی تعدیل‌شده در Slurm. بدون مقدار تعدیل، اولویت
زمان‌بندی ۱۰۰ واحد کاهش می‌یابد. یک مقدار منفی برای nice اولویت را افزایش داده
و در غیر این صورت آن را کاهش می‌دهد. بازهٔ تعدیل +/\- 2147483645 است.
تنها کاربران ممتاز می‌توانند تعدیل منفی تعیین کنند.
.IP.TP
\fB\-k\fR, \fB\-\-no\-kill\fR[=off]
در صورتی که یکی از گره‌های تخصیص‌یافته به کار با شکست مواجه شد (از کار افتاد)، کار را به‌طور خودکار خاتمه نده. در صورت خرابی یک گره، مسئولیت تحمل خطا بر عهده کاربر خواهد بود.
تخصیص کار باطل نخواهد شد، بنابراین کاربر می‌تواند گام‌های شغلی جدیدی را روی گره‌های باقی‌مانده در تخصیص خود اجرا کند.
این گزینه متغیر محیطی \fBSLURM_NO_KILL\fR را مقداردهی نمی‌کند.
بنابراین، هنگامی که یک گره از کار می‌افتد، گام‌های در حال اجرا روی آن گره متوقف خواهند شد، مگر اینکه متغیر محیطی \fBSLURM_NO_KILL\fR صراحتاً تنظیم شده باشد یا فراخوانی‌های srun در درون تخصیص کار صراحتاً \-\-no\-kill را درخواست کرده باشند.

آرگومان اختیاری "off" را مشخص کنید تا اثر متغیر محیطی \fBSBATCH_NO_KILL\fR غیرفعال شود.

به‌طور پیش‌فرض Slurm در صورتی که هر گره‌ای در محدوده گره‌های تخصیص‌یافته از کار بیفتد، کل تخصیص کار را خاتمه می‌دهد.
.IP

.TP
\fB\-\-no\-requeue\fR
مشخص می‌کند که کار دسته‌ای تحت هیچ شرایطی نباید مجدداً در صف قرار گیرد (یادداشت زیر را ببینید).
تنظیم این گزینه مانع از آن می‌شود که مدیران سیستم بتوانند کار را بازراه‌اندازی کنند (برای مثال، پس از یک زمان توقف برنامه‌ریزی‌شده)، آن را پس از خرابی گره بازیابی کنند، یا پس از پیش‌دستی (preemption) توسط یک کار با اولویت بالاتر، مجدداً در صف قرار دهند.
هنگامی که یک کار مجدداً در صف قرار می‌گیرد، اسکریپت دسته‌ای از ابتدا آغاز می‌شود.
همچنین گزینه \fB\-\-requeue\fR را ببینید.
پارامتر پیکربندی \fIJobRequeue\fR رفتار پیش‌فرض را در کلاستر کنترل می‌کند.

\fBنکته\fR: در صورتی که \fBForceRequeueOnFail\fR به‌عنوان گزینه‌ای برای پارامتر PrologFlags در slurm.conf تنظیم شده باشد، می‌تواند این تنظیم را لغو و بازنویسی کند.
.IP

.TP
\fB\-F\fR, \fB\-\-nodefile\fR=<\fInode_file\fR>
بسیار شبیه به \fB\-\-nodelist\fR است، اما فهرست در فایلی با نام \fInode file\fR قرار دارد. نام‌های گره‌های فهرست می‌توانند در چندین خط در فایل نیز گسترش یابند. نام‌های تکراری گره‌ها در فایل نادیده گرفته خواهند شد.
ترتیب نام گره‌ها در فهرست مهم نیست؛ نام‌های گره‌ها توسط Slurm مرتب خواهند شد.
.IP

.TP
\fB\-w\fR, \fB\-\-nodelist\fR=<\fInode_name_list\fR>
درخواست فهرستی مشخص از گره‌ها.
کار شامل تا جای ممکن تعداد بیشتری از این گره‌ها بر اساس نیازمندی‌های منابع خواهد بود، و در صورت نیاز اجرای کار را برای دردسترس قرار گرفتن منابع به تاخیر می‌اندازد.

اگر حداقل تعداد گره یا پردازنده را بیشتر از مقداری مشخص کنید که فهرست گره‌های ارائه‌شده بتواند برآورده کند، منابع اضافی در صورت نیاز روی گره‌های دیگر تخصیص داده خواهد شد (مگر اینکه از \fB\-\-segment\fR نیز استفاده شده باشد). برعکس، تعداد کمتر گره یا پردازنده ممکن است تنها به زیرمجموعه‌ای از فهرست گره‌های ارائه‌شده نیاز داشته باشد.

فهرست می‌تواند به صورت یک فهرست جداشده با کاما از گره‌ها، محدوده‌ای از گره‌ها (مثلاً node[1\-5,7,...])، یا یک نام فایل مشخص شود.
اگر فهرست گره‌ها حاوی نویسه "/" باشد، یک نام فایل در نظر گرفته می‌شود.
نام‌های تکراری گره در فهرست نادیده گرفته خواهند شد.
ترتیب نام گره‌ها در فهرست مهم نیست؛ نام‌های گره‌ها توسط Slurm مرتب خواهند شد.
.IP

.TP
\fB\-N\fR, \fB\-\-nodes\fR=<\fIminnodes\fR>[\-\fImaxnodes\fR]|<\fIsize_string\fR>
درخواست می‌کند که حداقل \fIminnodes\fR گره به این کار تخصیص داده شود.
حداکثر تعداد گره نیز می‌تواند با \fImaxnodes\fR مشخص شود.
اگر فقط یک عدد مشخص شود، به عنوان هر دو مقدار حداقل و حداکثر تعداد گره استفاده می‌شود. تعداد گره می‌تواند به عنوان size_string نیز مشخص شود.
مشخصه size_string تعیین می‌کند که چه مقادیر گره‌ای باید استفاده شود.
مقادیر متعدد را می‌توان با استفاده از یک فهرست جداشده با کاما یا با یک تابع گام به وسیله پسوندی شامل دونقطه و مقادیر عددی با یک جداکننده "-" مشخص کرد.
برای مثال، "--nodes=1-15:4" معادل "--nodes=1,5,9,13" است.
محدودیت‌های گره در پارتیشن بر محدودیت‌های کار اولویت دارد.
اگر محدودیت‌های گره کار خارج از محدوده مجاز برای پارتیشن مرتبط با آن باشد، کار در وضعیت PENDING باقی خواهد ماند.
این امر امکان اجرای احتمالی در زمانی دیگر را که محدودیت پارتیشن تغییر کند، فراهم می‌سازد.
اگر محدودیت گره کار از تعداد گره‌های پیکربندی‌شده در پارتیشن تجاوز کند، کار رد خواهد شد.
توجه داشته باشید که متغیر محیطی \fBSLURM_JOB_NUM_NODES\fR بر روی تعداد گره‌هایی که در واقعیت به کار تخصیص یافته‌اند تنظیم خواهد شد. برای اطلاعات بیشتر بخش \fBENVIRONMENT VARIABLES \fR را ببینید. اگر \fB\-N\fR مشخص نشده باشد، رفتار پیش‌فرض تخصیص گره‌های کافی برای برآورده کردن منابع درخواستیِ بیان‌شده توسط گزینه‌های مشخصه کار است، مانند \fB\-n\fR، \fB\-c\fR و \fB--gpus\fR.
به کار تا جای ممکن بیشترین تعداد گره در محدوده مشخص‌شده و بدون به تاخیر انداختن شروع کار تخصیص داده خواهد شد.
مشخصه تعداد گره می‌تواند شامل یک مقدار عددی و به دنبال آن پسوند "k" (ضرب مقدار عددی در ۱٬۰۲۴) یا "m" (ضرب مقدار عددی در ۱٬۰۴۸٬۵۷۶) باشد.

\fBنکته\fR: این گزینه نمی‌تواند همراه با توزیع اختیاری (arbitrary distribution) استفاده شود.
.IP

.TP
\fB\-n\fR, \fB\-\-ntasks\fR=<\fInumber\fR>
دستور sbatch وظایف (تسک‌ها) را راه‌اندازی نمی‌کند، بلکه درخواست تخصیص منابع داده و یک اسکریپت دسته‌ای ارسال می‌کند. این گزینه به کنترل‌کننده Slurm اطلاع می‌دهد که گام‌های شغلی اجراشده در این تخصیص حداکثر \fInumber\fR تسک را راه‌اندازی خواهند کرد و منابع کافی را فراهم کند.
مقدار پیش‌فرض یک تسک به ازای هر گره است، اما توجه داشته باشید که گزینه \fB\-\-cpus\-per\-task\fR این پیش‌فرض را تغییر خواهد داد.
.IP

.TP
\fB\-\-ntasks\-per\-core\fR=<\fIntasks\fR>
درخواست می‌کند که حداکثر \fIntasks\fR تسک روی هر هسته فراخوانی شود.
برای استفاده به همراه گزینه \fB\-\-ntasks\fR در نظر گرفته شده است.
مرتبط با \fB\-\-ntasks\-per\-node\fR است با این تفاوت که به جای سطح گره، در سطح هسته اعمال می‌شود. این گزینه توسط srun به ارث برده خواهد شد.
نرم‌افزار Slurm ممکن است برای رعایت این گزینه، پردازنده‌های بیشتری (cpus) نسبت به آنچه درخواست شده تخصیص دهد.
.br
\fBنکته\fR: این گزینه هنگام استفاده از \fISelectType=select/linear\fR پشتیبانی نمی‌شود. این مقدار نمی‌تواند بزرگتر از \fB\-\-threads\-per\-core\fR باشد.
.IP

.TP
\fB\-\-ntasks\-per\-gpu\fR=<\fIntasks\fR>
درخواست می‌کند که به ازای هر GPU تعداد \fIntasks\fR تسک فراخوانی شود.
این گزینه می‌تواند به دو روش کار کند: ۱) علاوه بر این \fB\-\-ntasks\fR را مشخص کنید، که در این حالت یک مشخصه GPU بدون نوع به‌طور خودکار برای برآورده کردن \fB\-\-ntasks\-per\-gpu\fR تعیین خواهد شد، یا ۲) GPUهای مورد نظر را (مثلاً از طریق \fB\-\-gpus\fR یا \fB\-\-gres\fR) بدون مشخص کردن \fB\-\-ntasks\fR مشخص کنید، و تعداد کل تسک‌ها به‌طور خودکار تعیین خواهد شد.
تعداد CPUهای مورد نیاز در صورت لزوم به‌طور خودکار افزایش می‌یابد تا تعداد تسک‌های محاسبه‌شده فراهم شود.
این گزینه به‌طور ضمنی \fB\-\-tres\-bind=gres/gpu:single:<ntasks>\fR را تنظیم می‌کند، اما می‌توان آن را با یک مشخصه صریح \fB\-\-tres\-bind=gres/gpu\fR لغو و جایگزین کرد.
این گزینه با بازه گره (یعنی \-N<\fIminnodes\fR\-\fImaxnodes\fR>) سازگار نیست.
این گزینه با \fB\-\-gpus\-per\-task\fR، \fB\-\-gpus\-per\-socket\fR، یا \fB\-\-ntasks\-per\-node\fR سازگار نیست.
این گزینه پشتیبانی نمی‌شود مگر اینکه \fISelectType=cons_tres\fR پیکربندی شده باشد (چه به‌طور مستقیم یا غیرمستقیم در سامانه‌های Cray).
.IP

.TP
\fB\-\-ntasks\-per\-node\fR=<\fIntasks\fR>
درخواست می‌کند که روی هر گره \fIntasks\fR تسک فراخوانی شود.
اگر همراه با گزینه \fB\-\-ntasks\fR استفاده شود، گزینه \fB\-\-ntasks\fR اولویت خواهد داشت و \fB\-\-ntasks\-per\-node\fR به عنوان \fIحداکثر\fR تعداد تسک در هر گره در نظر گرفته خواهد شد.
برای استفاده به همراه گزینه \fB\-\-nodes\fR در نظر گرفته شده است.
این گزینه به \fB\-\-cpus\-per\-task\fR=\fIncpus\fR مرتبط است، اما نیازی به دانستن تعداد واقعی cpus در هر گره ندارد. در برخی موارد، راحت‌تر است که بتوان درخواست کرد بیش از یک تعداد مشخص تسک روی هر گره فراخوانی نشود. نمونه‌هایی از این مورد عبارتند از ارسال یک برنامه ترکیبی MPI/OpenMP که در آن تنها یک "task/rank" از MPI باید به هر گره اختصاص داده شود در حالی که بخش OpenMP اجازه می‌یابد از تمام موازی‌سازی موجود در گره استفاده کند، یا ارسال یک کار منفرد آماده‌سازی/پاک‌سازی/پایش به هر گره از یک تخصیص موجود از پیش، به عنوان یک گام در یک اسکریپت کار بزرگتر.
.IP

.TP
\fB\-\-ntasks\-per\-socket\fR=<\fIntasks\fR>
درخواست می‌کند که حداکثر \fIntasks\fR تسک روی هر سوکت فراخوانی شود.
برای استفاده به همراه گزینه \fB\-\-ntasks\fR در نظر گرفته شده است.
مرتبط با \fB\-\-ntasks\-per\-node\fR است با این تفاوت که به جای سطح گره، در سطح سوکت اعمال می‌شود.
\fBنکته\fR: این گزینه هنگام استفاده از \fISelectType=select/linear\fR پشتیبانی نمی‌شود.
.IP

.TP
\fB\-\-oom\-kill\-step\fR[={0|1}]
تعیین می‌کند که در صورت تشخیص یک رخداد OOM در هر تسک از یک گام، آیا کل گام خاتمه داده شود یا خیر. این گزینه تنظیم "OOMKillStep" در TaskPluginParam از slurm.conf را بازنویسی می‌کند. هنگامی که تنظیم نشده باشد، از مقدار slurm.conf استفاده خواهد کرد. هنگام تنظیم، مقدار "0" خاتمه کل گام را غیرفعال کرده و مقدار "1" آن را فعال می‌کند. این مورد برای کل تخصیص به جز گام خارجی (external step) اعمال می‌شود.
در صورتی که این گزینه بدون مقدار درج شود، مقدار پیش‌فرض "1" (فعال) است.
.IP

.TP
\fB\-\-open\-mode\fR={append|truncate}
باز کردن فایل‌های خروجی و خطا در حالت الحاق (append) یا بازنویسی (truncate) مطابق با مقدار مشخص‌شده.
مقدار پیش‌فرض توسط پارامتر پیکربندی سامانه \fIJobFileAppend\fR مشخص می‌شود.
.IP

.TP
\fB\-o\fR, \fB\-\-output\fR=<\fIfilename_pattern\fR>
به Slurm دستور می‌دهد خروجی استاندارد اسکریپت دسته‌ای را مستقیماً به نام فایل مشخص‌شده در "\fIfilename pattern\fR" متصل کند.
به‌طور پیش‌فرض، هر دو خروجی استاندارد و خطای استاندارد به همان فایل هدایت می‌شوند.
برای آرایه‌های کاری، نام فایل پیش‌فرض "slurm\-%A_%a.out" است، "%A" با شناسه کار و "%a" با اندیس آرایه جایگزین می‌شود.
برای سایر کارها، نام فایل پیش‌فرض "slurm\-%j.out" است، که در آن "%j" با شناسه کار جایگزین می‌شود.
برای گزینه‌های مشخص‌سازی نام فایل، بخش \fBfilename pattern\fR را در زیر ببینید.
.IP.TP
\fB\-O\fR, \fB\-\-overcommit\fR
تخصیص بیش از حد منابع (Overcommit).

هنگامی که بر یک تخصیص کار اعمال می‌شود (به‌استثنای کارهایی که درخواست دسترسی انحصاری به گره‌ها را دارند)، منابع به‌گونه‌ای تخصیص می‌یابند که گویی تنها یک تسک به ازای هر گره درخواست شده است. این بدان معناست که تعداد پردازنده‌های درخواست‌شده به ازای هر تسک (\fB\-c\fR، \fB\-\-cpus\-per\-task\fR) به‌جای ضرب شدن در تعداد تسک‌ها، به ازای هر گره تخصیص می‌یابد. گزینه‌هایی که برای تعیین تعداد تسک‌ها به ازای هر گره، سوکت، هسته و غیره استفاده می‌شوند، نادیده گرفته خواهند شد.

هنگامی که بر تخصیص‌های گام کار (دستور \fBsrun\fR در هنگام اجرا درون یک تخصیص کار موجود) اعمال شود، این گزینه می‌تواند برای راه‌اندازی بیش از یک تسک به ازای هر پردازنده استفاده شود.
در حالت عادی، \fBsrun\fR بیش از یک فرایند را به ازای هر پردازنده تخصیص نمی‌دهد.
با مشخص کردن \fB\-\-overcommit\fR، شما صریحاً اجازه اجرای بیش از یک فرایند به ازای هر پردازنده را می‌دهید. با این حال، اجرای بیش از \fBMAX_TASKS_PER_NODE\fR تسک به ازای هر گره مجاز نیست. \fBنکته\fR: مقدار \fBMAX_TASKS_PER_NODE\fR در فایل \fIslurm.h\fR تعریف شده است و یک متغیر نیست، بلکه در زمان ساخت Slurm تنظیم می‌شود.
.IP

.TP
\fB\-s\fR, \fB\-\-oversubscribe\fR
تخصیص کار می‌تواند منابع را با سایر کارهای در حال اجرا به اشتراک مضاعف (over\-subscribe) بگذارد.
منابعی که مشمول اشتراک مضاعف می‌شوند، بسته به پیکربندی می‌توانند گره‌ها، سوکت‌ها، هسته‌ها و/یا رشته‌های هایپرتردینگ (hyperthreads) باشند.
رفتار پیش‌فرض اشتراک مضاعف به پیکربندی سیستم بستگی دارد و گزینه \fBOverSubscribe\fR مربوط به پارتیشن نسبت به گزینه کار اولویت دارد.
این گزینه ممکن است منجر به این شود که تخصیص منابع سریع‌تر از زمانی که گزینه \-\-oversubscribe تنظیم نشده انجام گیرد و امکان بهره‌وری بالاتری از سیستم را فراهم کند، اما عملکرد برنامه احتمالاً به دلیل رقابت بر سر منابع کاهش خواهد یافت.
همچنین گزینه \-\-exclusive را ببینید.

\fBنکته\fR: این گزینه با \fB\-\-exclusive\fR ناسازگار و مانعة‌الجمع است.
.IP

.TP
\fB\-\-parsable\fR
تنها شماره شناسه کار و در صورت وجود، نام کلاستر را در خروجی نمایش می‌دهد.
مقادیر با یک نقطه‌ویرگول از یکدیگر جدا می‌شوند. خطاها همچنان نمایش داده خواهند شد.
توجه داشته باشید که \fB\-\-quiet\fR شناسه کار را نیز همراه با سایر پیام‌های اطلاعاتی پنهان می‌کند.
.IP

.TP
\fB\-p\fR, \fB\-\-partition\fR=<\fIpartition_names\fR>
درخواست یک پارتیشن خاص برای تخصیص منابع. اگر مشخص نشود، رفتار پیش‌فرض این است که به کنترلر Slurm اجازه داده می‌شود پارتیشن پیش‌فرضی را که توسط مدیر سیستم تعیین شده انتخاب کند. اگر کار بتواند از بیش از یک پارتیشن استفاده کند، نام آن‌ها را در یک فهرست جداشده با کاما مشخص کنید؛ پارتیشنی که زودترین زمان آغاز را ارائه دهد بدون در نظر گرفتن ترتیب نام پارتیشن‌ها استفاده خواهد شد (اگرچه پارتیشن‌های با اولویت بالاتر ابتدا در نظر گرفته می‌شوند).
هنگامی که کار آغاز شود، نام پارتیشن استفاده‌شده در ابتدای رشته پارتیشن در رکورد کار قرار خواهد گرفت.
.IP

.TP
\fB\-\-prefer\fR=<\fIlist\fR>
گره‌ها می‌توانند دارای \fBویژگی‌هایی\fR (\fBfeatures\fR) باشند که توسط مدیر Slurm به آن‌ها اختصاص داده شده است.
کاربران می‌توانند با استفاده از گزینه prefer مشخص کنند که کدام‌یک از این \fBویژگی‌ها\fR برای کارشان مطلوب است اما الزامی نیست.
این گزینه مستقل از \fB\-\-constraint\fR عمل کرده و در صورت امکان، هر آنچه در آنجا تنظیم شده را بازنویسی می‌کند.
هنگام زمان‌بندی، ویژگی‌های موجود در \fB\-\-prefer\fR ابتدا بررسی می‌شوند. اگر مجموعه‌ای از گره‌ها با آن ویژگی‌ها در دسترس نباشد، سپس \fB\-\-constraint\fR ارزیابی می‌شود.
برای اطلاعات بیشتر \fB\-\-constraint\fR را ببینید؛ این گزینه به همان شیوه عمل می‌کند.

.TP
\fB\-\-priority\fR=<\fIvalue\fR>
درخواست اولویت خاص برای کار.
ممکن است تابع محدودیت‌های خاص پیکربندی باشد.
\fIvalue\fR باید یک مقدار عددی یا "TOP" (برای بالاترین مقدار ممکن) باشد.
تنها اپراتورها و مدیران Slurm می‌توانند اولویت یک کار را تنظیم کنند.
.IP

.TP
\fB\-\-profile\fR={all|none|<\fItype\fR>[,<\fItype\fR>...]}
جمع‌آوری جزئیات داده‌ها توسط افزونه acct_gather_profile را فعال می‌کند.
داده‌های تفصیلی معمولاً سری‌های زمانی هستند که بسته به افزونه پیکربندی‌شده، در یک فایل HDF5 برای کار یا در یک پایگاه داده InfluxDB ذخیره می‌شوند.
.IP
.RS
.TP 10
\fBAll\fR
تمام انواع داده‌ها جمع‌آوری می‌شوند. (نمی‌توان با مقادیر دیگر ترکیب کرد.)
.IP

.TP
\fBNone\fR
هیچ نوع داده‌ای جمع‌آوری نمی‌شود. این حالت پیش‌فرض است.
(نمی‌توان با مقادیر دیگر ترکیب کرد.)
.RE
.IP

مقادیر معتبر \fItype\fR عبارتند از:
.IP
.RS
.TP
\fBEnergy\fR
داده‌های مصرف انرژی جمع‌آوری می‌شود.
.IP

.TP
\fBTask\fR
داده‌های تسک (ورودی/خروجی، حافظه و...) جمع‌آوری می‌شود.
.IP

.TP
\fBLustre\fR
داده‌های Lustre جمع‌آوری می‌شود.
.IP

.TP
\fBNetwork\fR
داده‌های شبکه (InfiniBand) جمع‌آوری می‌شود.
.RE
.IP

.TP
\fB\-\-propagate\fR[=\fIrlimit\fR[,\fIrlimit\fR...]]
به کاربران اجازه می‌دهد مشخص کنند کدام‌یک از محدودیت‌های منابع قابل‌تغییر (نرم یا soft) به گره‌های محاسباتی انتقال یابند (propagate شوند) و بر کارهای آن‌ها اعمال گردند. اگر هیچ
\fIrlimit\fR مشخص نشود، تمام محدودیت‌های منابع انتقال خواهند یافت.
نام‌های rlimit زیر توسط Slurm پشتیبانی می‌شوند (اگرچه ممکن است برخی
گزینه‌ها در برخی سیستم‌ها پشتیبانی نشوند):
.IP
.RS
.TP 10
\fBALL\fR
تمام محدودیت‌های فهرست‌شده در زیر (پیش‌فرض)
.IP

.TP
\fBNONE\fR
هیچ‌یک از محدودیت‌های فهرست‌شده در زیر
.IP

.TP
\fBAS\fR
حداکثر فضای آدرس‌دهی (حافظه مجازی) برای یک فرایند.
.IP

.TP
\fBCORE\fR
حداکثر اندازه فایل core (تخلیه حافظه).
.IP

.TP
\fBCPU\fR
حداکثر مدت زمان پردازنده (CPU time).
.IP

.TP
\fBDATA\fR
حداکثر اندازه بخش داده (data segment) یک فرایند.
.IP

.TP
\fBFSIZE\fR
حداکثر اندازه فایل‌های ایجادشده. توجه داشته باشید که اگر کاربر FSIZE را به مقداری کمتر
از اندازه فعلی slurmd.log تنظیم کند، راه‌اندازی کار با خطای
\(aqFile size limit exceeded\(aq شکست خواهد خورد.
.IP

.TP
\fBMEMLOCK\fR
حداکثر اندازه‌ای که می‌توان در حافظه قفل کرد.
.IP

.TP
\fBNOFILE\fR
حداکثر تعداد فایل‌های باز.
.IP

.TP
\fBNPROC\fR
حداکثر تعداد فرایندهای در دسترس.
.IP

.TP
\fBRSS\fR
حداکثر اندازه مجموعه مقیم (RSS). توجه داشته باشید که این گزینه تنها در هسته‌های لینوکس
نسخه 2.4.30 یا قدیمی‌تر یا BSD تأثیر دارد.
.IP

.TP
\fBSTACK\fR
حداکثر اندازه پشته (stack size).
.RE
.IP

.TP
\fB\-q\fR, \fB\-\-qos\fR=<\fIqos\fR>
درخواست کیفیت خدمات (QOS) برای کار، یا یک فهرست جداشده با کاما از QOSها.
در صورت درخواست یک فهرست، مرتب‌سازی بر اساس اولویت QOSهای مشخص‌شده انجام می‌شود و
اولین مورد بالاترین اولویت را خواهد داشت.
مقادیر QOS می‌توانند
برای هر انتساب کاربر/کلاستر/حساب در پایگاه داده Slurm تعریف شوند.
کاربران به مجموعه qosهای تعریف‌شده برای انتساب خود محدود خواهند بود هرگاه
پارامتر پیکربندی Slurm، یعنی AccountingStorageEnforce، مقدار
"qos" را در تعریف خود داشته باشد..IP

.TP
\fB\-Q\fR, \fB\-\-quiet\fR
جلوگیری از نمایش پیام‌های اطلاعاتی sbatch مانند شناسه کار (Job ID). تنها خطاها همچنان نمایش داده خواهند شد.
.IP

.TP
\fB\-\-reboot\fR
راه‌اندازی مجدد (reboot) اجباری گره‌های تخصیص‌یافته پیش از شروع کار.
این قابلیت تنها با برخی از پیکربندی‌های سیستم پشتیبانی می‌شود و در غیر این صورت بدون هیچ هشداری نادیده گرفته خواهد شد. تنها کاربر ریشه (root)، \fISlurmUser\fR یا مدیران سیستم می‌توانند گره‌ها را بازنشانی کنند.
.IP

.TP
\fB\-\-requeue\fR[=\fIexpedite\fR]
مشخص می‌کند که کار دسته‌ای (batch job) باید واجد شرایط قرارگیری مجدد در صف (requeuing) باشد.
کار ممکن است به‌طور صریح توسط مدیر سیستم، پس از خرابی گره، یا هنگام پیش‌دستی (preemption) توسط یک کار با اولویت بالاتر، مجدداً در صف قرار گیرد.
هنگامی که یک کار دوباره در صف قرار می‌گیرد، اسکریپت دسته‌ای از ابتدای آن با همان شناسه کار آغاز می‌شود. همچنین گزینه \fB\-\-no\-requeue\fR را ببینید.
پارامتر پیکربندی \fIJobRequeue\fR رفتار پیش‌فرض را روی کلاستر کنترل می‌کند.

پارامتر اختیاری \fBexpedite\fR درخواست می‌کند که کار بلافاصله دوباره واجد شرایط شروع باشد و با بالاترین اولویت ممکن زمان‌بندی شود.
این اتفاق تنها در صورتی رخ خواهد داد که قرارگیری مجدد سریع در صف به‌صورت سراسری با \fBSlurmctldParameters=enable_expedited_requeue\fR در \fIslurm.conf\fR مجاز شده باشد.
.IP

.TP
\fB\-\-reservation\fR=<\fIreservation_names\fR>
تخصیص منابع برای کار از رزرو (reservation) نام‌برده‌شده. اگر کار بتواند از بیش از یک رزرو استفاده کند، نام‌های آن‌ها را در یک فهرست جداشده با کاما مشخص کنید؛ رزروی که زودترین زمان آغاز را ارائه دهد انتخاب می‌شود. هر رزرو به ترتیبی که درخواست شده است بررسی خواهد شد.
تمام رزروها در طول عمر کار در scontrol/squeue فهرست خواهند شد.
در حسابداری (accounting)، رزرو اول دیده می‌شود و پس از شروع کار، رزرو استفاده‌شده جایگزین آن خواهد شد.
.IP

.TP
\fB\-\-resources\fR=<\fIresource_names\fR>
مشخص کردن منابع سلسله‌مراتبی که باید به این کار تخصیص داده شوند.
نام منابع می‌تواند با دونقطه و یک تعداد همراه باشد (تعداد پیش‌فرض یک است).
منابع چندگانه در Mode 1 و Mode 2 را می‌توان در یک فهرست جداشده با کاما درخواست کرد، اما تنها یکی از Mode 3 را می‌توان درخواست نمود.
برای مثال، "\-\-resources=flat:2,natural:1".

برای اطلاعات بیشتر درباره استفاده از منابع سلسله‌مراتبی در Slurm به \fIhttps://slurm.schedmd.com/hres.html\fR مراجعه کنید.
.IP

.TP
\fB\-\-resv\-ports\fR[=\fIcount\fR]
رزرو درگاه‌های ارتباطی برای این کار. کاربران می‌توانند تعداد درگاه‌هایی را که می‌خواهند رزرو کنند مشخص نمایند. پارامتر MpiParams=ports=12000\-12999 باید در \fIslurm.conf\fR مشخص شده باشد. اگر تعداد درگاه‌های رزرو شده صفر باشد، هیچ درگاهی رزرو نمی‌شود. این گزینه تنها برای PMI بومی Cray استفاده می‌شود.
این گزینه تنها زمانی قابل استفاده است که مدیریت گام slurmstepd فعال باشد.
گزینه \fB\-\-stepmgr\fR را ببینید.
.IP

.TP
\fB\-\-segment\fR=<\fIsegment_size\fR>
هنگامی که از توپولوژی بلوکی یا حلقه‌ای استفاده می‌شود، این گزینه اندازه بخش‌هایی (segments) را که برای ایجاد تخصیص کار استفاده می‌شوند، تعیین می‌کند.
هیچ الزامی وجود نخواهد داشت که تمام بخش‌های یک کار درون همان بلوک سطح بالاتر قرار گیرند.

\fBنکته\fR: اگر تعداد گره‌های درخواست‌شده (\fB\-\-nodes\fR) بزرگتر از اندازه بخش درخواستی باشد، باید بر اندازه بخش بخش‌پذیر باشد.
اگر تمام گره‌ها درون یک بخش جای گیرند، این گزینه هیچ اثری نخواهد داشت.

\fBنکته\fR: هنگام استفاده همراه با \fB\-\-nodelist=<node_list>\fR:
تعداد گره‌های درخواستی باید کمتر یا مساوی تعداد کل گره‌های یکتای مشخص‌شده در آرگومان \fB\-\-nodelist\fR باشد.
درخواست گره‌های بیشتر از گره‌های یکتای موجود در \fB\-\-nodelist\fR ارائه‌شده، منجر به رد کار توسط slurmctld خواهد شد.
.IP

.TP
\fB\-\-signal\fR=[{R|B}:]<\fIsig_num\fR>[@\fIsig_time\fR]
هنگامی که کار در فاصله \fIsig_time\fR ثانیه‌ای تا زمان پایان خود قرار دارد، سیگنال \fIsig_num\fR به آن ارسال می‌شود.
به دلیل دقت تفکیک رسیدگی به رویدادها توسط Slurm، ممکن است سیگنال تا ۶۰ ثانیه زودتر از زمان مشخص‌شده ارسال شود.
\fIsig_num\fR می‌تواند شماره سیگنال یا نام آن باشد (مانند "10" یا "USR1").
\fIsig_time\fR باید مقداری صحیح بین 0 تا 65535 داشته باشد.
به‌طور پیش‌فرض، پیش از زمان پایان کار هیچ سیگنالی ارسال نمی‌شود.
اگر \fIsig_num\fR بدون هیچ \fIsig_time\fR مشخص شود، زمان پیش‌فرض ۶۰ ثانیه خواهد بود.
از گزینه "B:" برای ارسال سیگنال فقط به شل دسته‌ای (batch shell) استفاده کنید؛ به هیچ‌یک از فرایندهای دیگر سیگنال ارسال نخواهد شد. به‌طور پیش‌فرض، به تمام گام‌های کار سیگنال ارسال می‌شود، اما به خود شل دسته‌ای ارسال نمی‌شود.
از گزینه "R:" استفاده کنید تا به این کار اجازه دهید با یک رزرو که دارای MaxStartDelay تنظیم‌شده است هم‌پوشانی داشته باشد. اگر گزینه "R:" استفاده شود، پیش‌دستی (preemption) باید روی سیستم فعال باشد، و اگر کار پیش‌دستی شود، در صورت مجاز بودن دوباره در صف قرار می‌گیرد وگرنه لغو خواهد شد.
برای اینکه سیگنال در زمان پیش‌دستی ارسال شود، \fBsend_user_signal\fR در \fBPreemptParameter\fR را ببینید.
.IP

.TP
\fB\-\-sockets\-per\-node\fR=<\fIsockets\fR>
محدود کردن انتخاب گره به گره‌هایی با حداقل تعداد مشخص‌شده سوکت. در صورت فعال بودن پلاگین task/affinity، اطلاعات بیشتر را زیر گزینه \fB\-B\fR در بالا ببینید.
.br
\fBنکته\fR: این گزینه ممکن است در صورت عدم تعیین \fB\-n\fR، تعداد وظایف (tasks) را به‌طور ضمنی برابر با یک وظیفه به ازای هر نخ درخواستی قرار دهد.
.IP

.TP
\fB\-\-spread\-job\fR
پخش کردن تخصیص کار روی بیشترین تعداد ممکن از گره‌ها و تلاش برای توزیع یکنواخت وظایف میان گره‌های تخصیص‌یافته.
این گزینه پلاگین topology/tree را غیرفعال می‌کند.
.IP

.TP
\fB\-\-spread\-segments\fR
جلوگیری از تخصیص گره‌های درون یک بلوک پایه به بخش‌های مجزا درون همان بلوک.

\fBنکته\fR: این گزینه تنها با پلاگین \fBtopology/block\fR کار خواهد کرد.
.IP

.TP
\fB\-\-stepmgr\fR
فعال کردن مدیریت گام slurmstepd به ازای هر کار در صورتی که در سراسر سیستم فعال نباشد.
این گزینه امکان مدیریت گام‌های کار را توسط یک extern slurmstepd منفرد مرتبط با کار فراهم می‌کند. این قابلیت برای کارهایی که گام‌های زیادی را درون تخصیص‌های خود ارسال می‌کنند مفید است. \fBPrologFlags=contain\fR باید تنظیم شده باشد.
.IP

.TP
\fB\-\-switches\fR=<\fIcount\fR>[@\fImax\-time\fR]
هنگامی که از توپولوژی درختی استفاده می‌شود، این گزینه حداکثر تعداد سوئیچ‌های برگ (leaf switches) مورد نظر برای تخصیص کار و به‌صورت اختیاری حداکثر زمان انتظار برای آن تعداد سوئیچ را مشخص می‌کند. اگر Slurm تخصیصی حاوی سوئیچ‌های بیشتری از تعداد مشخص‌شده پیدا کند، کار در وضعیت معلق (pending) باقی می‌ماند تا زمانی که یا تخصیصی با تعداد سوئیچ مورد نظر بیابد یا محدودیت زمانی به پایان برسد.
اگر محدودیتی برای تعداد سوئیچ وجود نداشته باشد، هیچ تأخیری در شروع کار نخواهد بود.
قالب‌های زمانی قابل قبول شامل "minutes"، "minutes:seconds"، "hours:minutes:seconds"، "days\-hours"، "days\-hours:minutes" و "days\-hours:minutes:seconds" هستند.
حداکثر زمان تأخیر کار ممکن است توسط مدیر سیستم با استفاده از پارامتر پیکربندی \fBSchedulerParameters\fR و گزینه پارامتری \fBmax_switch_wait\fR محدود شود.
در یک شبکه dragonfly تنها تعداد سوئیچ پشتیبانی‌شده ۱ است، زیرا کارایی ارتباطی زمانی در بالاترین حد خواهد بود که به کار منابعی روی یک سوئیچ برگ یا بیش از ۲ سوئیچ برگ تخصیص داده شود.
زمان max\-time پیش‌فرض، برابر با مقدار max_switch_wait در SchedulerParameters است.
.IP

.TP
\fB\-\-test\-only\fR
اعتبارسنجی اسکریپت دسته‌ای و بازگرداندن تخمینی از زمانی که کار با توجه به صف فعلی کارها و تمام آرگومان‌های دیگر مشخص‌کننده نیازمندی‌های کار زمان‌بندی می‌شود. در عمل هیچ کاری ارسال نمی‌شود.
.IP

.TP
\fB\-\-thread\-spec\fR=<\fInum\fR>
تعداد نخ‌های اختصاصی به ازای هر گره که توسط کار برای عملیات سیستم رزرو شده و توسط برنامه استفاده نمی‌شوند. برنامه از این نخ‌ها استفاده نخواهد کرد، اما هزینه تخصیص آن‌ها محاسبه خواهد شد.
این گزینه نمی‌تواند همراه با گزینه \fB\-\-core\-spec\fR استفاده شود.

\fBنکته\fR: تنظیم صریح مقدار نخ‌های اختصاصی یک کار، به‌طور ضمنی گزینه --exclusive آن را فعال کرده و کل گره‌ها را برای کار رزرو می‌کند.
.IP

.TP
\fB\-\-threads\-per\-core\fR=<\fIthreads\fR>
محدود کردن انتخاب گره به گره‌هایی با حداقل تعداد مشخص‌شده نخ به ازای هر هسته. در چیدمان وظایف، از حداکثر تعداد نخ‌های مشخص‌شده در هر هسته استفاده کنید. \fBنکته\fR: واژه «نخ‌ها» به تعداد واحدهای پردازشی روی هر هسته اشاره دارد، نه تعداد وظایف برنامه‌ای که قرار است در هر هسته اجرا شوند.
در صورت فعال بودن پلاگین task/affinity، اطلاعات بیشتر را زیر گزینه \fB\-B\fR در بالا ببینید.
.br
\fBنکته\fR: این گزینه ممکن است در صورت عدم تعیین \fB\-n\fR، تعداد وظایف را به‌طور ضمنی برابر با یک وظیفه به ازای هر نخ درخواستی قرار دهد.
.IP

.TP
\fB\-t\fR, \fB\-\-time\fR=<\fItime\fR>
تعیین محدودیت برای زمان کل اجرای تخصیص کار. اگر محدودیت زمانی درخواست‌شده از محدودیت زمانی پارتیشن فراتر رود، کار در وضعیت PENDING باقی خواهد ماند (احتمالاً برای همیشه). محدودیت زمانی پیش‌فرض، محدودیت زمانی پیش‌فرض پارتیشن است. هنگامی که محدودیت زمانی فرا برسد، به هر وظیفه در هر گام کار ابتدا SIGTERM و سپس SIGKILL ارسال می‌شود. فاصله زمانی میان این سیگنال‌ها با پارامتر پیکربندی Slurm یعنی \fBKillWait\fR مشخص می‌شود. پارامتر پیکربندی \fBOverTimeLimit\fR ممکن است به کار اجازه دهد طولانی‌تر از زمان زمان‌بندی‌شده اجرا شود. دقت زمان یک دقیقه است و مقادیر ثانیه به بالا (به دقیقه بعدی) گرد می‌شوند.

محدودیت زمانی صفر درخواست می‌کند که هیچ محدودیت زمانی اعمال نشود. قالب‌های زمانی قابل قبول شامل "minutes"، "minutes:seconds"، "hours:minutes:seconds"، "days\-hours"، "days\-hours:minutes" و "days\-hours:minutes:seconds" هستند..IP

.TP
\fB\-\-time\-min\fR=<\fItime\fR>
تعیین حداقل محدودیت زمانی برای تخصیص منبع کار.
در صورت مشخص شدن، چنانچه کاهش محدودیت زمانی کار امکان شروع اجرای آن را زودتر
از حالت معمول فراهم کند، ممکن است محدودیت \fB\-\-time\fR آن تا مقداری نه کمتر
از \fB\-\-time\-min\fR کاهش یابد.
پس از تخصیص منابع به کار، محدودیت زمانی کار تغییر نخواهد کرد.
این کار توسط الگوریتم زمان‌بندی بازپردازی (backfill scheduling) انجام می‌شود تا
منابعی را تخصیص دهد که در غیر این صورت برای کارهای با اولویت بالاتر رزرو می‌شدند.
قالب‌های زمانی پذیرفته‌شده شامل «minutes»، «minutes:seconds»،
«hours:minutes:seconds»، «days\-hours»، «days\-hours:minutes» و
«days\-hours:minutes:seconds» هستند.
.IP

.TP
\fB\-\-tmp\fR=<\fIsize\fR>[\fIunits\fR]
مشخص کردن حداقل فضای دیسک موقت به ازای هر گره (node).
واحد پیش‌فرض مبی‌بایت (mebibytes) است.
واحدهای مختلف را می‌توان با استفاده از پسوند [K|M|G|T] مشخص کرد.
.IP

.TP
\fB\-\-tres\-bind\fR=<\fItres\fR>:[verbose,]<\fItype\fR>[+<\fItres\fR>:
[verbose,]<\fItype\fR>...]
فهرستی از tres را به همراه گزینه‌های اتصال وظیفه (task binding) آن‌ها مشخص می‌کند.
در حال حاضر gres تنها tres پشتیبانی‌شده برای این گزینه است. gres را به صورت
"gres/<gres_name>" (مانند gres/gpu) مشخص کنید.

مثال: \-\-tres\-bind=gres/gpu:verbose,map:0,1,2,3+gres/nic:closest

به‌طور پیش‌فرض، اکثر tresها به وظایف منفرد متصل نمی‌شوند.

گزینه‌های نوع (\fItype\fR) اتصال پشتیبانی‌شده برای \fBgres\fR:
.IP
.RS
.TP 10
\fBclosest\fR
هر وظیفه (task) را به نزدیک‌ترین gres(ها) متصل می‌کند.
در یک محیط NUMA، هر وظیفه ممکن است به بیش از یک gres متصل شود (یعنی
تمام gresهای موجود در آن محیط NUMA).
.IP

.TP
\fBmap:<list>\fR
اتصال با تنظیم ماسک‌های gres روی وظایف (یا رتبه‌ها/ranks) به صورت مشخص‌شده انجام می‌شود،
به‌طوری‌که <list> به صورت <gres_id_for_task_0>,<gres_id_for_task_1>,... است. شناسه‌های gres
به عنوان مقادیر ده‌دهی (decimal) تفسیر می‌شوند. اگر تعداد وظایف (یا رتبه‌ها) از تعداد
عناصر موجود در این فهرست بیشتر شود، عناصر موجود در فهرست بر حسب نیاز از ابتدای فهرست
دوباره استفاده خواهند شد. برای ساده‌سازی پشتیبانی از تعداد وظایف بالا، فهرست‌ها می‌توانند
پس از map از ستاره و تعداد تکرار استفاده کنند؛ برای مثال "map:0*4,1*4".
اگر از افزونه task/cgroup استفاده شود و ConstrainDevices در cgroup.conf تنظیم شده باشد،
شناسه‌های gres نمایه‌های با مبنای صفر (zero\-based) نسبت به gresهای تخصیص‌یافته به کار
هستند (برای مثال اولین gres برابر با 0 است، حتی اگر شناسه سراسری آن 3 باشد). در غیر
این صورت، شناسه‌های gres شناسه‌های سراسری هستند و برای دریافت نتایج اتصال قابل‌پیش‌بینی،
تمام gresهای روی هر گره در کار باید تخصیص داده شوند.
.IP

.TP
\fBmask:<list>\fR
اتصال با تنظیم ماسک‌های gres روی وظایف (یا رتبه‌ها) به صورت مشخص‌شده انجام می‌شود که در آن
<list> برابر با <gres_mask_for_task_0>,<gres_mask_for_task_1>,... است. این نگاشت برای یک
گره مشخص می‌شود و نگاشت یکسانی بر روی وظایف در هر گره اعمال می‌گردد (یعنی پایین‌ترین شناسه
وظیفه در هر گره به اولین ماسک مشخص‌شده در فهرست نگاشت می‌شود و غیره). ماسک‌های gres همیشه
به عنوان مقادیر شانزده‌شانزدهی (hexadecimal) تفسیر می‌شوند، اما می‌توانند یک '0x' اختیاری در
ابتدا داشته باشند. برای ساده‌سازی پشتیبانی از تعداد وظایف بالا، فهرست‌ها می‌توانند پس از mask
از یک ستاره و تعداد تکرار استفاده کنند؛ برای مثال "mask:0x0f*4,0xf0*4".
اگر از افزونه task/cgroup استفاده شود و ConstrainDevices در cgroup.conf تنظیم شده باشد،
شناسه‌های gres نمایه‌های با مبنای صفر نسبت به gresهای تخصیص‌یافته به کار هستند (برای مثال
اولین gres برابر با 0 است، حتی اگر شناسه سراسری آن 3 باشد). در غیر این صورت، شناسه‌های
gres شناسه‌های سراسری هستند و برای دریافت نتایج اتصال قابل‌پیش‌بینی، تمام gresهای روی هر
گره در کار باید تخصیص داده شوند.
.IP

.TP
\fBnone\fR
وظایف به این gres متصل نشوند (اتصال ضمنی حاصل از \-\-tres\-per\-task و
\-\-gpus\-per\-task را غیرفعال می‌کند).
.IP

.TP
\fBper_task:<gres_per_task>\fR
هر وظیفه به تعداد gres مشخص‌شده در \fI<gres_per_task>\fR متصل خواهد شد. وظایف ترجیحاً به
gresهایی با همبستگی (affinity) با هسته‌ها در تخصیص خود اختصاص می‌یابند (مشابه \fIclosest\fR)،
اگرچه در صورت در دسترس نبودن، هر gres دیگری را دریافت خواهند کرد. اگر هیچ همبستگی وجود نداشته
باشد، به وظیفه اول تعداد x تا از اولین gresهای روی گره اختصاص می‌یابد و الی آخر.
gres اشتراکی در صورت امکان ترجیح می‌دهد یک دستگاه به اشتراک‌گذاشته‌شده را به ازای هر وظیفه متصل کند.
.IP

.TP
\fBsingle:<tasks_per_gres>\fR
مشابه \fIclosest\fR است، با این تفاوت که هر وظیفه تنها می‌تواند به یک gres واحد متصل شود،
حتی زمانی که بتواند به چند gres که به یک اندازه نزدیک هستند متصل گردد. gres مورد نظر برای
اتصال توسط \fI<tasks_per_gres>\fR تعیین می‌شود، که در آن اولین وظایف به تعداد
\fI<tasks_per_gres>\fR به اولین gres موجود متصل می‌شوند، دومین دسته از وظایف به تعداد
\fI<tasks_per_gres>\fR به دومین gres موجود متصل می‌شوند و الی آخر.
این در واقع یک توزیع بلوکی وظایف بر روی gresهای موجود است، که در آن gresهای موجود توسط
همبستگی سوکتِ وظیفه و همبستگی سوکتِ gres طبق پارامتر \fICores\fR در gres.conf تعیین می‌شوند.
.IP

\fBنکته\fR: اتصال gres اشتراکی در حال حاضر به per_task یا none محدود است.
.RE
.IP

.TP
\fB\-\-tres\-per\-task\fR=<\fIlist\fR>
فهرستی جداشده با کاما از منابع قابل‌ردیابی مورد نیاز کار به ازای هر وظیفه‌ای که در
تخصیص منابع کار ایجاد خواهد شد را مشخص می‌کند.
قالب هر مدخل در فهرست به صورت "trestype[/tresname]=count" است.
مقدار \fItrestype\fR نوع منبع قابل‌ردیابی درخواستی است (مانند cpu، gres، license و غیره).
مقدار \fItresname\fR نام منبع قابل‌ردیابی است، همان‌طور که با \fIsacctmgr show tres\fR قابل
مشاهده است. این مقدار در صورت وجود برای انواع tres مانند gres، license و غیره الزامی است
(مانند gpu، gpu:a100).
به منظور درخواست مجوز (license) با این گزینه، مجوز(ها) باید در پارامتر
\fBAccountingStorageTRES\fR فایل slurm.conf تعریف شده باشند.
مقدار \fIcount\fR تعداد آن منابع است.
.br
تعداد می‌تواند دارای پسوندی از موارد زیر باشد:
.br
"k" یا "K" (مضرب ۱۰۲۴)،
.br
"m" یا "M" (مضرب ۱۰۲۴ × ۱۰۲۴)،
.br
"g" یا "G" (مضرب ۱۰۲۴ × ۱۰۲۴ × ۱۰۲۴)،
.br
"t" یا "T" (مضرب ۱۰۲۴ × ۱۰۲۴ × ۱۰۲۴ × ۱۰۲۴)،
.br
"p" یا "P" (مضرب ۱۰۲۴ × ۱۰۲۴ × ۱۰۲۴ × ۱۰۲۴ × ۱۰۲۴).
.br
مثال‌ها:
.nf
\-\-tres\-per\-task=cpu=4
\-\-tres\-per\-task=cpu=8,license/ansys=1
\-\-tres\-per\-task=gres/gpu=1
\-\-tres\-per\-task=gres/gpu:a100=2
.fi
منابع مشخص‌شده روی هر گره به کار تخصیص داده خواهند شد.
منابع قابل‌ردیابیِ در دسترس توسط مدیر سیستم قابل‌پیکربندی هستند.
.br
\fBنکته\fR: این گزینه به همراه gres/gpu یا gres/shard به طور ضمنی
\-\-tres\-bind=gres/[gpu|shard]:per_task:<tres_per_task> را تنظیم می‌کند، یا اگر چند
نوع gpu مشخص شده باشد، \-\-tres\-bind=gres/gpu:per_task:<gpus_per_task_type_sum> را
تنظیم خواهد کرد. این مقدار را می‌توان با مشخص کردن صریح \-\-tres\-bind لغو کرد.
.br
\fBنکته\fR: منابع TRES نامعتبر برای \-\-tres\-per\-task شامل bb، billing، energy،
fs، mem، node، pages و vmem هستند.
.br
.IP

.TP
\fB\-\-uid\fR=<\fIuser\fR>
تلاش برای ارسال و/یا اجرای یک کار به عنوان \fIuser\fR به جای شناسه کاربر فراخواننده.
از اعتبارنامه‌های کاربر فراخواننده برای بررسی مجوزهای دسترسی به پارتیشن هدف استفاده
خواهد شد. برای مثال، کاربر root می‌تواند از این گزینه برای اجرای کارها به عنوان یک کاربر
عادی در یک پارتیشن RootOnly استفاده کند. در صورت اجرا به عنوان root، دستور \fBsbatch\fR
پس از تخصیص موفقیت‌آمیز گره، دسترسی‌های خود را به uid مشخص‌شده کاهش می‌دهد.
\fIuser\fR ممکن است نام کاربری یا شناسه کاربری عددی باشد.
.br
\fBنکته\fR: آرگومان \fB\-\-uid\fR منسوخ شده است و در نسخه‌های آینده حذف خواهد شد.
.IP

.TP
\fB\-\-usage\fR
نمایش پیام راهنمای مختصر و خروج.
.IP

.TP
\fB\-\-use\-min\-nodes\fR
در صورت ارائه محدوده‌ای از تعداد گره‌ها، اولویت با تعداد کمتر خواهد بود.
.IP

.TP
\fB\-v\fR, \fB\-\-verbose\fR
افزایش میزان جزئیات پیام‌های اطلاعاتی sbatch. استفاده از چندین \fB\-v\fR میزان
جزئیات sbatch را بیشتر افزایش می‌دهد. به‌طور پیش‌فرض تنها خطاها نمایش داده خواهند شد.
.IP

.TP
\fB\-V\fR, \fB\-\-version\fR
نمایش اطلاعات نسخه و خروج.
.IP

.TP
\fB\-W\fR, \fB\-\-wait\fR
تا زمان پایان کار ارسال‌شده خارج نشوید.
کد وضعیت خروج دستور sbatch مشابه وضعیت خروج کار ارسال‌شده خواهد بود. اگر کار به
جای خروج عادی به دلیل دریافت یک سیگنال خاتمه یابد، وضعیت خروج برابر با 1 تنظیم خواهد شد.
در مورد یک آرایه کار (job array)، وضعیت خروج ثبت‌شده بالاترین مقدار در میان تمام وظایف
موجود در آرایه کار خواهد بود.
.IP.TP
\fB\-\-wait\-all\-nodes\fR=<\fIvalue\fR>
زمان شروع اجرای دستور را کنترل می‌کند.
به‌طور پیش‌فرض، کار به محض انجام تخصیص، اجرا را آغاز خواهد کرد.
.IP
.RS
.TP 5
0
به محض اینکه امکان تخصیص فراهم شود، اجرا را آغاز کن.
برای آماده‌سازی و در دسترس قرار گرفتن همه گره‌ها (یعنی بوت شدن آن‌ها) منتظر نمان.
.IP

.TP
1
تا زمانی که همه گره‌ها آماده استفاده نشده‌اند، اجرا را آغاز نکن.
.RE
.IP

.TP
\fB\-\-wckey\fR=<\fIwckey\fR>
مقدار wckey مورد استفاده برای کار را مشخص می‌کند. اگر در slurm.conf مقدار TrackWCKey=no (پیش‌فرض) باشد، این مقدار نادیده گرفته می‌شود.
.IP

.TP
\fB\-\-wrap\fR=<\fIcommand_string\fR>
دستور sbatch رشته دستور مشخص‌شده را در یک اسکریپت شل ساده «sh» قرار می‌دهد (wrap می‌کند) و آن اسکریپت را به کنترل‌کننده slurm ارسال می‌نماید. هنگامی که از \-\-wrap استفاده می‌شود، نمی‌توان نام اسکریپت و آرگومان‌ها را در خط فرمان مشخص کرد؛ در عوض از اسکریپت پوششی تولیدشده توسط sbatch استفاده می‌شود.
.IP

.SH "الگوی نام فایل (FILENAME PATTERN)"
.PP
دستور \fBsbatch\fR اجازه می‌دهد الگوی نام فایل شامل یک یا چند نماد جایگزینی باشد که به صورت یک علامت درصد «%» به همراه یک حرف هستند (مانند %j).

.TP
\fB\\\\\fR
هیچ‌یک از نمادهای جایگزینی را پردازش نکن.
.IP

.TP
\fB%%\fR
نویسه «%».
.IP

.TP
\fB%A\fR
شماره تخصیص کار اصلی در آرایه کارها (Job array).
.IP

.TP
\fB%a\fR
شناسه (شاخص) آرایه کارها.
.IP

.TP
\fB%b\fR
شناسه (شاخص) آرایه کارها به پیمانه ۱۰ (modulo 10).
.IP

.TP
\fB%J\fR
مقدار jobid.stepid کار در حال اجرا (مانند «128.0»). مقدار stepid تنها برای گام‌های عادی بسط داده می‌شود، نه برای گام‌های ویژه مانند «batch» یا «extern».
.IP

.TP
\fB%j\fR
مقدار jobid کار در حال اجرا.
.IP

.TP
\fB%N\fR
نام کوتاه میزبان (short hostname). این گزینه برای هر گره یک فایل IO جداگانه ایجاد می‌کند.
.IP

.TP
\fB%n\fR
شناسه گره نسبت به کار جاری (برای نمونه «0» اولین گره از کار در حال اجرا است). این گزینه برای هر گره یک فایل IO جداگانه ایجاد می‌کند.
.IP

.TP
\fB%r\fR
تعداد دفعات راه‌اندازی مجدد (restart) کار در حال اجرا.
.IP

.TP
\fB%S\fR
مقدار SLUID کار در حال اجرا.
.IP

.TP
\fB%s\fR
مقدار stepid کار در حال اجرا.
.IP

.TP
\fB%t\fR
شناسه تسک/وظیفه (رتبه یا rank) نسبت به کار جاری. این گزینه برای هر وظیفه یک فایل IO جداگانه ایجاد می‌کند.
.IP

.TP
\fB%u\fR
نام کاربر.
.IP

.TP
\fB%x\fR
نام کار.
.IP

.PP
عددی که بین نویسه درصد و تعیین‌کننده قالب قرار می‌گیرد، می‌تواند برای پر کردن نتیجه با صفر (zero\-pad) در نام فایل IO به حداقل تعداد ارقام مشخص‌شده استفاده شود. اگر تعیین‌کننده قالب مربوط به داده‌های غیرعددی باشد (برای نمونه %N)، این عدد نادیده گرفته می‌شود. بیشترین مقدار ۱۰ است؛ اگر مقداری بزرگ‌تر از ۱۰ استفاده شود، نتیجه حداکثر تا ۱۰ نویسه پر خواهد شد.
در زیر مثال‌هایی از نحوه استفاده از رشته قالب برای یک گام کاری با ۴ وظیفه (task)، شناسه کار (JobID) برابر ۱۲۸ و شناسه گام (step id) برابر ۰ آورده شده است:

.TP 15
job%J.out
job128.0.out
.IP

.TP
job%4j.out
job0128.out
.IP

.TP
job%2j\-%2t.out
job128\-00.out, job128\-01.out, ...
.IP.SH "کارایی (PERFORMANCE)"
.PP
اجرای \fBsbatch\fR یک فراخوانی روال از راه دور (RPC) به \fBslurmctld\fR ارسال می‌کند. اگر
تعداد فراخوانی‌های هم‌زمان از سوی \fBsbatch\fR یا سایر دستورهای کلاینت Slurm که فراخوانی‌های
روال از راه دور به دیمن \fBslurmctld\fR می‌فرستند به حد کافی زیاد باشد، می‌تواند منجر به
افت کارایی دیمن \fBslurmctld\fR و احتمالاً بروز وضعیت منع سرویس (denial of service) شود.
.PP
دستور \fBsbatch\fR یا سایر دستورهای کلاینت Slurm را که فراخوانی‌های روال از راه دور
به \fBslurmctld\fR ارسال می‌کنند، از درون حلقه‌ها در اسکریپت‌های شل یا دیگر برنامه‌ها
اجرا نکنید. اطمینان حاصل کنید که برنامه‌ها فراخوانی‌های \fBsbatch\fR را به حداقل میزان
لازم برای اطلاعاتی که در پی گردآوری آن هستید محدود کنند.

.SH "متغیرهای محیطی ورودی (INPUT ENVIRONMENT VARIABLES)"
.PP
هنگام راه‌اندازی، sbatch گزینه‌های تعیین‌شده در متغیرهای محیطی زیر را خوانده و پردازش خواهد کرد.
بخش عمده‌ای از این متغیرها به همان شیوه‌ای که گزینه‌ها در بالا تعریف شده‌اند، مقداردهی می‌شوند.
برای گزینه‌های پرچمی که به‌گونه‌ای تعریف شده‌اند که هیچ آرگومانی نمی‌پذیرند، می‌توان گزینه را با
تنظیم متغیر محیطی بدون مقدار (رشته خالی یا NULL)، رشته \(aqyes\(aq یا یک عدد غیرصفر فعال کرد.
هر مقدار دیگری برای متغیر محیطی منجر به فعال نشدن گزینه خواهد شد.
چندین استثنا برای این قواعد وجود دارد که در ادامه ذکر شده‌اند.
.br
\fBنکته\fR: متغیرهای محیطی بر هر گزینه‌ای که در یک اسکریپت batch تنظیم شده باشد اولویت دارند (آن را بازنویسی می‌کنند)،
و گزینه‌های خط فرمان نیز بر تمامی متغیرهای محیطی اولویت خواهند داشت.

.TP 22
\fBSBATCH_ACCOUNT\fR
مشابه \fB\-A, \-\-account\fR
.IP

.TP
\fBSBATCH_ACCTG_FREQ\fR
مشابه \fB\-\-acctg\-freq\fR
.IP

.TP
\fBSBATCH_ARRAY_INX\fR
مشابه \fB\-a, \-\-array\fR
.IP

.TP
\fBSBATCH_BATCH\fR
مشابه \fB\-\-batch\fR
.IP

.TP
\fBSBATCH_CLUSTERS\fR یا \fBSLURM_CLUSTERS\fR
مشابه \fB\-\-clusters\fR
.IP

.TP
\fBSBATCH_CONSTRAINT\fR
مشابه \fB\-C\fR, \fB\-\-constraint\fR
.IP

.TP
\fBSBATCH_CONTAINER\fR
مشابه \fB\-\-container\fR.
.IP

.TP
\fBSBATCH_CONTAINER_ID\fR
مشابه \fB\-\-container-id\fR.
.IP

.TP
\fBSBATCH_CONTAINER_TYPE\fR
مشابه \fB\-\-container-type\fR.
.IP

.TP
\fBSBATCH_CORE_SPEC\fR
مشابه \fB\-\-core\-spec\fR
.IP

.TP
\fBSBATCH_CPUS_PER_GPU\fR
مشابه \fB\-\-cpus\-per\-gpu\fR
.IP

.TP
\fBSBATCH_DEBUG\fR
مشابه \fB\-v, \-\-verbose\fR هنگام تنظیم روی ۱؛ تنظیم روی ۲ معادل \-vv خواهد بود، و غیره.
.IP

.TP
\fBSBATCH_DELAY_BOOT\fR
مشابه \fB\-\-delay\-boot\fR
.IP

.TP
\fBSBATCH_DISTRIBUTION\fR
مشابه \fB\-m, \-\-distribution\fR
.IP

.TP
\fBSBATCH_ERROR\fR
مشابه \fB-e, \-\-error\fR
.IP

.TP
\fBSBATCH_EXCLUSIVE\fR
مشابه \fB\-\-exclusive\fR
.IP

.TP
\fBSBATCH_EXPORT\fR
مشابه \fB\-\-export\fR
.IP

.TP
\fBSBATCH_GET_USER_ENV\fR
مشابه \fB\-\-get\-user\-env\fR
.IP

.TP
\fBSBATCH_GPU_BIND\fR
مشابه \fB\-\-gpu\-bind\fR
.IP

.TP
\fBSBATCH_GPU_FREQ\fR
مشابه \fB\-\-gpu\-freq\fR
.IP

.TP
\fBSBATCH_GPUS\fR
مشابه \fB\-G, \-\-gpus\fR
.IP

.TP
\fBSBATCH_GPUS_PER_NODE\fR
مشابه \fB\-\-gpus\-per\-node\fR
.IP

.TP
\fBSBATCH_GPUS_PER_TASK\fR
مشابه \fB\-\-gpus\-per\-task\fR
.IP

.TP
\fBSBATCH_GRES\fR
مشابه \fB\-\-gres\fR
.IP

.TP
\fBSBATCH_GRES_FLAGS\fR
مشابه \fB\-\-gres\-flags\fR
.IP

.TP
\fBSBATCH_HINT\fR یا \fBSLURM_HINT\fR
مشابه \fB\-\-hint\fR
.IP

.TP
\fBSBATCH_IGNORE_PBS\fR
مشابه \fB\-\-ignore\-pbs\fR
.IP

.TP
\fBSBATCH_INPUT\fR
مشابه \fB\-i, \-\-input\fR
.IP

.TP
\fBSBATCH_JOB_NAME\fR
مشابه \fB\-J, \-\-job\-name\fR
.IP

.TP
\fBSBATCH_MEM_BIND\fR
مشابه \fB\-\-mem\-bind\fR
.IP

.TP
\fBSBATCH_MEM_PER_CPU\fR
مشابه \fB\-\-mem\-per\-cpu\fR
.IP

.TP
\fBSBATCH_MEM_PER_GPU\fR
مشابه \fB\-\-mem\-per\-gpu\fR
.IP

.TP
\fBSBATCH_MEM_PER_NODE\fR
مشابه \fB\-\-mem\fR
.IP

.TP
\fBSBATCH_NETWORK\fR
مشابه \fB\-\-network\fR
.IP

.TP
\fBSBATCH_NO_KILL\fR
مشابه \fB\-k\fR, \fB\-\-no\-kill\fR.IP

.TP
\fBSBATCH_NO_REQUEUE\fR
همانند \fB\-\-no\-requeue\fR
.IP

.TP
\fBSBATCH_OPEN_MODE\fR
همانند \fB\-\-open\-mode\fR
.IP

.TP
\fBSBATCH_OUTPUT\fR
همانند \fB-o, \-\-output\fR
.IP

.TP
\fBSBATCH_OVERCOMMIT\fR
همانند \fB\-O, \-\-overcommit\fR
.IP

.TP
\fBSBATCH_PARTITION\fR
همانند \fB\-p, \-\-partition\fR
.IP

.TP
\fBSBATCH_POWER\fR
همانند \fB\-\-power\fR
.IP

.TP
\fBSBATCH_PROFILE\fR
همانند \fB\-\-profile\fR
.IP

.TP
\fBSBATCH_QOS\fR
همانند \fB\-\-qos\fR
.IP

.TP
\fBSBATCH_REQ_SWITCH\fR
هنگامی که از هم‌بندی (توپولوژی) درختی استفاده می‌شود، این متغیر بیشینهٔ تعداد سوییچ‌های موردنظر برای تخصیص کار و به صورت اختیاری، بیشینهٔ زمان انتظار برای این تعداد سوییچ را مشخص می‌کند. به \fB\-\-switches\fR مراجعه کنید.
.IP

.TP
\fBSBATCH_REQUEUE\fR
همانند \fB\-\-requeue\fR
.IP

.TP
\fBSBATCH_RESERVATION\fR
همانند \fB\-\-reservation\fR
.IP

.TP
\fBSBATCH_SEGMENT_SIZE\fR
همانند \fB\-\-segment\fR
.IP

.TP
\fBSBATCH_SIGNAL\fR
همانند \fB\-\-signal\fR
.IP

.TP
\fBSBATCH_SPREAD_JOB\fR
همانند \fB\-\-spread\-job\fR
.IP

.TP
\fBSBATCH_THREAD_SPEC\fR
همانند \fB\-\-thread\-spec\fR
.IP

.TP
\fBSBATCH_THREADS_PER_CORE\fR
همانند \fB\-\-threads\-per\-core\fR
.IP

.TP
\fBSBATCH_TIMELIMIT\fR
همانند \fB\-t, \-\-time\fR
.IP

.TP
\fBSBATCH_TRES_BIND\fR
همانند \fB\-\-tres\-bind\fR
.IP

.TP
\fBSBATCH_TRES_PER_TASK\fR
همانند \fB\-\-tres\-per\-task\fR
.IP

.TP
\fBSBATCH_USE_MIN_NODES\fR
همانند \fB\-\-use\-min\-nodes\fR
.IP

.TP
\fBSBATCH_WAIT\fR
همانند \fB\-W\fR، \fB\-\-wait\fR
.IP

.TP
\fBSBATCH_WAIT_ALL_NODES\fR
همانند \fB\-\-wait\-all\-nodes\fR. برای غیرفعال یا فعال کردن گزینه باید روی 0 یا 1 تنظیم شود.
.IP

.TP
\fBSBATCH_WAIT4SWITCH\fR
بیشینهٔ زمان انتظار برای سوییچ‌های درخواستی. به \fB\-\-switches\fR مراجعه کنید.
.IP

.TP
\fBSBATCH_WCKEY\fR
همانند \fB\-\-wckey\fR
.IP

.TP
\fBSLURM_CONF\fR
مکان فایل پیکربندی Slurm.
.IP

.TP
\fBSLURM_DEBUG_FLAGS\fR
پرچم‌های اشکال‌زدایی مورد استفادهٔ sbatch را مشخص می‌کند. برای فهرست کامل پرچم‌ها به DebugFlags در صفحهٔ راهنمای \fBslurm.conf\fR(5) مراجعه کنید. این متغیر محیطی بر تنظیمات موجود در slurm.conf اولویت دارد.
.IP

.TP
\fBSLURM_EXIT_ERROR\fR
کد خروجی تولیدشده هنگام وقوع خطای Slurm (مانند گزینه‌های نامعتبر) را مشخص می‌کند.
اسکریپت‌ها می‌توانند از این متغیر برای تمایز بین کدهای خروج برنامه کاربردی و شرایط خطای گوناگون Slurm استفاده کنند.
.IP

.TP
\fBSLURM_STEP_KILLED_MSG_NODE_ID\fR=ID
در صورت تنظیم، تنها گره (node) مشخص‌شده هنگام کشته شدن کار یا گام توسط سیگنال، پیام لاگ ثبت خواهد کرد.
.IP

.TP
\fBSLURM_UMASK\fR
در صورت تعریف شدن، Slurm هنگام ایجاد فایل‌های خروجی/خطای کار، از \fIumask\fR تعریف‌شده برای تنظیم مجوزها استفاده خواهد کرد.
.IP.SH "متغیرهای محیطی خروجی (OUTPUT ENVIRONMENT VARIABLES)"
.PP
کنترل‌کننده Slurm متغیرهای زیر را در محیط اسکریپت دسته‌ای (batch script)
تنظیم خواهد کرد.

.TP
\fBSBATCH_MEM_BIND\fR
برابر با مقدار گزینه \fB\-\-mem\-bind\fR تنظیم می‌شود.
.IP

.TP
\fBSBATCH_MEM_BIND_LIST\fR
برابر با ماسک بیتی مورد استفاده برای مقیدسازی حافظه (memory binding) تنظیم می‌شود.
.IP

.TP
\fBSBATCH_MEM_BIND_PREFER\fR
اگر گزینه \fB\-\-mem\-bind\fR شامل گزینه prefer باشد، برابر با \(lqprefer\(rq تنظیم می‌شود.
.IP

.TP
\fBSBATCH_MEM_BIND_TYPE\fR
برابر با نوع مقیدسازی حافظه تعیین‌شده با گزینه \fB\-\-mem\-bind\fR تنظیم می‌شود.
مقادیر ممکن عبارتند از \(lqnone\(rq،‏ \(lqrank\(rq،‏ \(lqmap_mem:\(rq،‏ \(lqmask_mem:\(rq و \(lqlocal\(rq.
.IP

.TP
\fBSBATCH_MEM_BIND_VERBOSE\fR
اگر گزینه \fB\-\-mem\-bind\fR شامل گزینه verbose باشد، برابر با \(lqverbose\(rq تنظیم می‌شود.
در غیر این صورت برابر با \(lqquiet\(rq تنظیم می‌گردد.
.IP

.TP
\fBSLURM_*_HET_GROUP_#\fR
برای تخصیص کار ناهمگن (heterogeneous job allocation)، متغیرهای محیطی برای هر مؤلفه به‌صورت جداگانه مقداردهی می‌شوند.
.IP

.TP
\fBSLURM_ARRAY_JOB_ID\fR
شناسه کار اصلی (master job ID) آرایه کار (job array).
.IP

.TP
\fBSLURM_ARRAY_TASK_COUNT\fR
تعداد کل وظایف در یک آرایه کار.
.IP

.TP
\fBSLURM_ARRAY_TASK_ID\fR
شماره شناسه (نمایه) وظیفه در آرایه کار.
.IP

.TP
\fBSLURM_ARRAY_TASK_MAX\fR
بیشترین شماره شناسه (نمایه) آرایه کار.
.IP

.TP
\fBSLURM_ARRAY_TASK_MIN\fR
کمترین شماره شناسه (نمایه) آرایه کار.
.IP

.TP
\fBSLURM_ARRAY_TASK_STEP\fR
اندازه گام نمایه در آرایه کار.
.IP

.TP
\fBSLURM_CLUSTER_NAME\fR
نام کلاستری که کار روی آن در حال اجرا است.
.IP

.TP
\fBSLURM_CPUS_ON_NODE\fR
تعداد CPUهای اختصاص‌یافته به گام دسته‌ای.
\fBنکته\fR: پلاگین \fBselect/linear\fR گره‌های کامل را به کارها تخصیص می‌دهد، بنابراین این مقدار بیانگر تعداد کل CPUهای موجود روی گره است.
برای پلاگین \fBcons/tres\fR، این مقدار بیانگر تعداد CPUهای تخصیص‌یافته به این گام روی این گره است.
.IP

.TP
\fBSLURM_CPUS_PER_GPU\fR
تعداد CPUهای درخواستی به ازای هر GPU تخصیص‌یافته.
تنها در صورتی تنظیم می‌شود که گزینه \fB\-\-cpus\-per\-gpu\fR مشخص شده باشد.
.IP

.TP
\fBSLURM_CPUS_PER_TASK\fR
تعداد CPUهای درخواستی به ازای هر وظیفه.
تنها در صورتی تنظیم می‌شود که گزینه \fB\-\-cpus\-per\-task\fR یا گزینه
\fB\-\-tres\-per\-task=cpu=#\fR مشخص شده باشد.
.IP

.TP
\fBSLURM_CONTAINER\fR
بسته OCI (OCI Bundle) برای کار.
تنها در صورتی تنظیم می‌شود که \fB\-\-container\fR مشخص شده باشد.
.IP

.TP
\fBSLURM_CONTAINER_ID\fR
شناسه OCI برای کار.
تنها در صورتی تنظیم می‌شود که \fB\-\-container\-id\fR مشخص شده باشد.
.IP

.TP
\fBSLURM_CONTAINER_TYPE\fR
نوع کانتینر برای کار.
تنها در صورتی تنظیم می‌شود که \fB\-\-container\-type\fR مشخص شده باشد.
.IP

.TP
\fBSLURM_DIST_PLANESIZE\fR
اندازه توزیع صفحه‌ای (plane distribution size). تنها برای توزیع‌های صفحه‌ای تنظیم می‌شود.
به \fB\-m, \-\-distribution\fR مراجعه کنید.
.IP

.TP
\fBSLURM_DISTRIBUTION\fR
مشابه \fB\-m, \-\-distribution\fR.
.IP

.TP
\fBSLURM_EXPORT_ENV\fR
مشابه \fB\-\-export\fR.
.IP

.TP
\fBSLURM_GPU_BIND\fR
مقیدسازی درخواستی وظایف به GPU.
تنها در صورتی تنظیم می‌شود که گزینه \fB\-\-gpu\-bind\fR مشخص شده باشد.
.IP

.TP
\fBSLURM_GPU_FREQ\fR
فرکانس درخواستی GPU.
تنها در صورتی تنظیم می‌شود که گزینه \fB\-\-gpu\-freq\fR مشخص شده باشد.
.IP

.TP
\fBSLURM_GPUS\fR
تعداد GPUهای درخواستی.
تنها در صورتی تنظیم می‌شود که گزینه \fB\-G, \-\-gpus\fR مشخص شده باشد.
.IP

.TP
\fBSLURM_GPUS_ON_NODE\fR
تعداد GPUهای تخصیص‌یافته به گام دسته‌ای.
.IP

.TP
\fBSLURM_GPUS_PER_NODE\fR
تعداد GPUهای درخواستی به ازای هر گره تخصیص‌یافته.
تنها در صورتی تنظیم می‌شود که گزینه \fB\-\-gpus\-per\-node\fR مشخص شده باشد.
.IP

.TP
\fBSLURM_GPUS_PER_SOCKET\fR
تعداد GPUهای درخواستی به ازای هر سوکت تخصیص‌یافته.
تنها در صورتی تنظیم می‌شود که گزینه \fB\-\-gpus\-per\-socket\fR مشخص شده باشد.
.IP

.TP
\fBSLURM_GTIDS\fR
شناسه‌های وظیفه سراسری (global task IDs) در حال اجرا روی این گره. شروع از صفر و جداشده با کاما.
اگر Slurm با پشتیبانی از pmi ساخته شده باشد، این متغیر به‌صورت داخلی توسط pmi خوانده می‌شود. رها کردن متغیر در حالت مقداردهی‌شده ممکن است هنگام استفاده از بسته‌های خارجی از داخل کار باعث بروز مشکل شود (مشخص شده است که Abaqus و Ansys در صورت تنظیم بودن آن دچار مشکل می‌شوند \- به مستندات مربوط به نرم‌افزارهای شخص ثالث مراجعه کنید).
.IP

.TP
\fBSLURM_HET_SIZE\fR
برابر با تعداد مؤلفه‌ها در یک کار ناهمگن تنظیم می‌شود.
.IP

.TP
\fBSLURM_JOB_ACCOUNT\fR
نام حساب کاربری (account) مرتبط با تخصیص کار.
.IP

.TP
\fBSLURM_JOB_CPUS_PER_NODE\fR
تعداد CPUهای در دسترس کار روی گره‌های موجود در تخصیص، با فرمت
\fICPU_count\fR[(x\fInumber_of_nodes\fR)][,\fICPU_count\fR
[(x\fInumber_of_nodes\fR)] ...].
برای مثال: SLURM_JOB_CPUS_PER_NODE=\(aq72(x2),36\(aq نشان می‌دهد که در
گره اول و دوم (همان‌طور که توسط SLURM_JOB_NODELIST فهرست شده است) تخصیص
دارای ۷۲ پردازنده است، در حالی که گره سوم دارای ۳۶ پردازنده است.
\fBنکته\fR: پلاگین \fBselect/linear\fR کل گره‌ها را به کارها تخصیص می‌دهد، بنابراین
این مقدار بیانگر تعداد کل CPUها روی گره‌های تخصیص‌یافته است. پلاگین
\fBselect/cons_tres\fR پردازنده‌های جداگانه را به کارها تخصیص می‌دهد، بنابراین این عدد بیانگر تعداد CPUهای تخصیص‌یافته به کار است.
.IP

.TP
\fBSLURM_JOB_DEPENDENCY\fR
برابر با مقدار گزینه \fB\-\-dependency\fR تنظیم می‌شود..IP

.TP
\fBSLURM_JOB_END_TIME\fR
برچسب زمانی یونیکس (UNIX timestamp) برای زمان تخمینی پایان کار.
.IP

.TP
\fBSLURM_JOB_GPUS\fR
شناسه‌های سراسری GPUهای اختصاص‌یافته به این کار. شناسه‌های GPU نسبت به هیچ cgroup دستگاهی سنجیده نمی‌شوند، حتی اگر دستگاه‌ها با task/cgroup محدود شده باشند. فقط در کارهای دسته‌ای (batch) و تعاملی (interactive) مقداردهی می‌شود.
.IP

.TP
\fBSLURM_JOB_ID\fR
شناسهٔ تخصیص کار.
.IP

.TP
\fBSLURM_JOB_LICENSES\fR
نام و تعداد هر مجوزی که درخواست شده است.
.IP

.TP
\fBSLURM_JOB_NAME\fR
نام کار.
.IP

.TP
\fBSLURM_JOB_NODELIST\fR
فهرست گره‌های اختصاص‌یافته به کار.
.IP

.TP
\fBSLURM_JOB_NUM_NODES\fR
تعداد کل گره‌ها در تخصیص منابع کار.
.IP

.TP
\fBSLURM_JOB_PARTITION\fR
نام پارتیشنی که کار در آن در حال اجرا است.
.IP

.TP
\fBSLURM_JOB_QOS\fR
کیفیت خدمات (QOS) تخصیص کار.
.IP

.TP
\fBSLURM_JOB_RESERVATION\fR
رزرو پیشرفته (Advanced reservation) دربرگیرندهٔ تخصیص کار، در صورت وجود.
.IP

.TP
\fBSLURM_JOB_SEGMENT_SIZE\fR
اندازهٔ بخش‌هایی (segments) که برای ایجاد تخصیص کار استفاده شده است.
تنها در صورتی تنظیم می‌شود که \fB\-\-segment\fR مشخص شده باشد.
.IP

.TP
\fBSLURM_JOB_START_TIME\fR
برچسب زمانی یونیکس (UNIX timestamp) برای زمان شروع کار.
.IP

.TP
\fBSLURM_JOBID\fR
شناسهٔ تخصیص کار. \fBSLURM_JOB_ID\fR را ببینید. برای سازگاری با نسخه‌های پیشین گنجانده شده است.
.IP

.TP
\fBSLURM_LOCALID\fR
شناسهٔ محلی وظیفه روی گره (Node local task ID) برای فرایند درون یک کار.
.IP

.TP
\fBSLURM_MEM_PER_CPU\fR
مشابه \fB\-\-mem\-per\-cpu\fR
.IP

.TP
\fBSLURM_MEM_PER_GPU\fR
حافظهٔ درخواستی به ازای هر GPU تخصیص‌یافته.
تنها در صورتی تنظیم می‌شود که گزینهٔ \fB\-\-mem\-per\-gpu\fR مشخص شده باشد.
.IP

.TP
\fBSLURM_MEM_PER_NODE\fR
مشابه \fB\-\-mem\fR
.IP

.TP
\fBSLURM_NETWORK\fR
در صورت تعیین، با مقدار گزینهٔ \fB\-\-network\fR تنظیم می‌شود.
.IP

.TP
\fBSLURM_NNODES\fR
تعداد کل گره‌ها در تخصیص منابع کار. \fBSLURM_JOB_NUM_NODES\fR را ببینید. برای سازگاری با نسخه‌های پیشین گنجانده شده است.
.IP

.TP
\fBSLURM_NODEID\fR
شناسهٔ گره‌های تخصیص‌یافته.
.IP

.TP
\fBSLURM_NODELIST\fR
فهرست گره‌های اختصاص‌یافته به کار. \fBSLURM_JOB_NODELIST\fR را ببینید. برای سازگاری با نسخه‌های پیشین گنجانده شده است.
.IP

.TP
\fBSLURM_NPROCS\fR
مشابه \fBSLURM_NTASKS\fR. برای سازگاری با نسخه‌های پیشین گنجانده شده است.
.IP

.TP
\fBSLURM_NTASKS\fR
در صورت تعیین، با مقدار گزینهٔ \fB\-\-ntasks\fR تنظیم می‌شود؛ یا در صورتی که هر یک از گزینه‌های \fB\-\-ntasks\-per\-*\fR مشخص شده باشند، با تعداد وظایف درون کار تنظیم می‌شود.

\fBنکته\fR: این متغیر همچنین یک متغیر ورودی برای srun است، بنابراین در صورت تعیین، هنگامی که از اسکریپت دسته‌ای (batch) فراخوانی شود، گزینهٔ \fB\-\-ntasks\fR را به طور موثر برای srun تنظیم خواهد کرد.
.IP

.TP
\fBSLURM_NTASKS_PER_CORE\fR
تعداد وظایف درخواستی به ازای هر هسته.
تنها در صورتی تنظیم می‌شود که گزینهٔ \fB\-\-ntasks\-per\-core\fR مشخص شده باشد.

.IP

.TP
\fBSLURM_NTASKS_PER_GPU\fR
تعداد وظایف درخواستی به ازای هر GPU.
تنها در صورتی تنظیم می‌شود که گزینهٔ \fB\-\-ntasks\-per\-gpu\fR مشخص شده باشد.
.IP

.TP
\fBSLURM_NTASKS_PER_NODE\fR
تعداد وظایف درخواستی به ازای هر گره.
تنها در صورتی تنظیم می‌شود که گزینهٔ \fB\-\-ntasks\-per\-node\fR مشخص شده باشد.
.IP

.TP
\fBSLURM_NTASKS_PER_SOCKET\fR
تعداد وظایف درخواستی به ازای هر سوکت.
تنها در صورتی تنظیم می‌شود که گزینهٔ \fB\-\-ntasks\-per\-socket\fR مشخص شده باشد.
.IP

.TP
\fBSLURM_OOMKILLSTEP\fR
مشابه \fB\-\-oom\-kill\-step\fR
.IP

.TP
\fBSLURM_OVERCOMMIT\fR
در صورتی که \fB\-\-overcommit\fR مشخص شده باشد، روی \fB1\fR تنظیم می‌شود.
.IP

.TP
\fBSLURM_PRIO_PROCESS\fR
اولویت زمان‌بندی (مقدار nice) در زمان ارسال کار.
این مقدار به فرایندهای ایجادشده منتقل می‌شود.
.IP

.TP
\fBSLURM_PROCID\fR
رتبهٔ MPI (یا شناسهٔ نسبی فرایند) برای فرایند کنونی.
.IP

.TP
\fBSLURM_PROFILE\fR
مشابه \fB\-\-profile\fR
.IP

.TP
\fBSLURM_RESTART_COUNT\fR
اگر کار به دلیل خرابی سیستم دوباره راه‌اندازی شده باشد یا به طور صریح مجدداً در صف قرار گرفته باشد (requeued)، این متغیر با تعداد دفعاتی که کار مجدداً آغاز شده تنظیم می‌شود.
.IP

.TP
\fBSLURM_SHARDS_ON_NODE\fR
تعداد GPU Shardهای در دسترس برای این گام در این گره.
.IP

.TP
\fBSLURM_SUBMIT_DIR\fR
دایرکتوری‌ای که \fBsbatch\fR از آن فراخوانی شده است.
.IP

.TP
\fBSLURM_SUBMIT_HOST\fR
نام میزبان (hostname) رایانه‌ای که \fBsbatch\fR از آن فراخوانی شده است..IP

.TP
\fBSLURM_TASK_PID\fR
شناسه فرایند (PID) تسکی که راه‌اندازی می‌شود.
.IP

.TP
\fBSLURM_TASKS_PER_NODE\fR
تعداد تسک‌هایی که باید روی هر گره اجرا شوند. مقادیر با کاما
از هم جدا شده و به همان ترتیب SLURM_JOB_NODELIST هستند.
اگر دو یا چند گره متوالی تعداد تسک یکسانی داشته باشند،
آن تعداد با «(x#)» دنبال می‌شود که در آن «#» تعداد
تکرار است. برای مثال، «SLURM_TASKS_PER_NODE=2(x3),1»
نشان می‌دهد که سه گره اول هر کدام دو تسک و گره چهارم
یک تسک را اجرا خواهند کرد.
.IP

.TP
\fBSLURM_THREADS_PER_CORE\fR
این متغیر تنها زمانی تنظیم می‌شود که \fB\-\-threads\-per\-core\fR یا
\fBSBATCH_THREADS_PER_CORE\fR مشخص شده باشند. مقدار آن برابر با
مقدار تعیین‌شده توسط \fB\-\-threads\-per\-core\fR یا
\fBSBATCH_THREADS_PER_CORE\fR خواهد بود. این متغیر توسط فراخوانی‌های بعدی srun
درون تخصیص کار استفاده می‌شود.
.IP

.TP
\fBSLURM_TOPOLOGY_ADDR\fR
این متغیر تنها زمانی تنظیم می‌شود که سیستم دارای افزونه topology/tree
پیکربندی‌شده باشد. مقدار آن روی نام سوئیچ‌های شبکه‌ای تنظیم می‌شود
که ممکن است در ارتباطات کار دخیل باشند؛ از سوئیچ بالاترین سطح سیستم
تا سوئیچ برگ (leaf) و در پایان نام گره. از یک نقطه برای جداسازی
نام هر جزء سخت‌افزاری استفاده می‌شود.
.IP

.TP
\fBSLURM_TOPOLOGY_ADDR_PATTERN\fR
این متغیر تنها زمانی تنظیم می‌شود که سیستم دارای افزونه topology/tree
پیکربندی‌شده باشد. مقدار آن انواع اجزای فهرست‌شده در
SLURM_TOPOLOGY_ADDR خواهد بود. هر جزء به عنوان «switch» یا «node»
مشخص می‌شود. از یک نقطه برای جداسازی نوع هر جزء سخت‌افزاری استفاده می‌شود.
.IP

.TP
\fBSLURM_TRES_PER_TASK\fR
روی مقدار \fB\-\-tres\-per\-task\fR تنظیم می‌شود. اگر \fB\-\-cpus\-per\-task\fR یا
\fB\-\-gpus\-per\-task\fR مشخص شده باشد، در \fBSLURM_TRES_PER_TASK\fR نیز
تنظیم می‌شود، گویی در \fB\-\-tres\-per\-task\fR مشخص شده بود.
.IP

.TP
\fBSLURMD_NODENAME\fR
نام گره‌ای که اسکریپت کار را اجرا می‌کند.
.IP

.SH "مثال‌ها (EXAMPLES)"

.TP
تعیین یک اسکریپت دسته‌ای با استفاده از نام فایل در خط فرمان. \
این اسکریپت دسته‌ای یک محدودیت زمانی ۱ دقیقه‌ای برای کار تعیین می‌کند.
.IP
.nf
$ cat myscript
#!/bin/sh
#SBATCH \-\-time=1
srun hostname |sort

$ sbatch \-N4 myscript
salloc: Granted job allocation 65537

$ cat slurm\-65537.out
host1
host2
host3
host4
.fi

.TP
ارسال یک اسکریپت دسته‌ای به sbatch از طریق ورودی استاندارد:
.IP
.nf
$ sbatch \-N4 <<EOF
> #!/bin/sh
> srun hostname |sort
> EOF
sbatch: Submitted batch job 65541

$ cat slurm\-65541.out
host1
host2
host3
host4
.fi

.TP
برای ایجاد یک کار ناهمگن با ۳ جزء، به طوری که هر یک مجموعه‌ای یکتا \
از گره‌ها را تخصیص دهند:
.IP
.nf
$ sbatch \-w node[2\-3] : \-w node4 : \-w node[5\-7] work.bash
Submitted batch job 34987
.fi

.SH "کپی‌رایت و تکثیر (COPYING)"
Copyright (C) 2006\-2007 The Regents of the University of California.
تولید شده در Lawrence Livermore National Laboratory (ر.ک. DISCLAIMER).
.br
Copyright (C) 2008\-2010 Lawrence Livermore National Security.
.br
Copyright (C) 2010\-2022 SchedMD LLC.
.LP
این فایل بخشی از Slurm، یک برنامه مدیریت منابع است.
برای جزئیات بیشتر، <https://slurm.schedmd.com> را ببینید.
.LP
نرم‌افزار Slurm یک نرم‌افزار آزاد است؛ شما می‌توانید آن را تحت شرایط
«GNU General Public License» همان‌طور که توسط بنیاد نرم‌افزارهای آزاد
منتشر شده است، چه نسخه ۲ مجوز یا (به انتخاب خودتان) هر نسخه بعدی،
بازتوزیع کرده یا تغییر دهید.
.LP
نرم‌افزار Slurm به این امید که مفید واقع شود توزیع شده است، اما بدون
هرگونه ضمانت؛ حتی بدون ضمانت ضمنی قابلیت فروش یا مناسب بودن برای
یک هدف خاص. برای جزئیات بیشتر GNU General Public License را ببینید..SH "همچنین ببینید (SEE ALSO)"
.LP
\fBsinfo\fR(1), \fBsattach\fR(1), \fBsalloc\fR(1), \fBsqueue\fR(1), \fBscancel\fR(1), \fBscontrol\fR(1),
\fBslurm.conf\fR(5), \fBsched_setaffinity\fR (2), \fBnuma\fR (3)