sbatch(1)                       Slurm Commands                       sbatch(1)



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


خلاصه دستور (SYNOPSIS)
       sbatch [OPTIONS(0)...] [ : [OPTIONS(N)...]] script(0) [args(0)...]

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


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

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

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

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

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

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


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


تفکیک مسیر اسکریپت (SCRIPT PATH RESOLUTION)
       مسیر اسکریپت دسته‌ای به ترتیب زیر تفکیک می‌شود:

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

       دایرکتوری کاری جاری همان دایرکتوری کاری فرایند فراخواننده است، مگر
       اینکه آرگومان --chdir ارسال شده باشد، که دایرکتوری کاری جاری را
       بازنویسی خواهد کرد.


گزینه‌ها (OPTIONS)
       -A, --account=<account>
              منابع استفاده‌شده توسط این کار را به حساب مشخص‌شده شارژ می‌کند.
              account یک رشته دلخواه است. نام حساب می‌تواند پس از ارسال کار با
              استفاده از دستور scontrol تغییر یابد.



       --acctg-freq=<datatype>=<interval>[,<datatype>=<interval>...]
              فواصل نمونه‌برداری حسابداری کار و پروفایل‌سازی را به ثانیه تعیین
              می‌کند.  این گزینه می‌تواند برای بازنویسی پارامتر
              JobAcctGatherFrequency در فایل slurm.conf استفاده شود.
              <datatype>=<interval> فاصله نمونه‌برداری وظیفه را برای پلاگین
              jobacct_gather یا فاصله نمونه‌برداری را برای یک نوع پروفایل‌سازی
              توسط پلاگین acct_gather_profile مشخص می‌کند. چندین جفت
              <datatype>=<interval> جداشده با کاما می‌توانند مشخص شوند. مقادیر
              پشتیبانی‌شده برای datatype عبارتند از:

              task        فاصله نمونه‌برداری برای پلاگین‌های jobacct_gather و
                          برای پروفایل‌سازی وظیفه توسط پلاگین
                          acct_gather_profile.
                          نکته: این بسامد برای پایش مصرف حافظه استفاده می‌شود.
                          در صورت اعمال محدودیت‌های حافظه، بالاترین بسامدی که
                          کاربر می‌تواند درخواست کند همان است که در فایل
                          slurm.conf پیکربندی شده است. این مقدار را نمی‌توان
                          غیرفعال کرد.



              energy      فاصله نمونه‌برداری برای پروفایل‌سازی مصرف انرژی با
                          استفاده از پلاگین acct_gather_energy.



              network     فاصله نمونه‌برداری برای پروفایل‌سازی infiniband با
                          استفاده از پلاگین acct_gather_interconnect.



              filesystem  فاصله نمونه‌برداری برای پروفایل‌سازی سیستم‌فایل با
                          استفاده از پلاگین acct_gather_filesystem.



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



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



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



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



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



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

              زمان می‌تواند به شکل HH:MM:SS باشد تا یک کار در ساعت مشخصی از روز
              اجرا شود (ثانیه‌ها اختیاری هستند).  (اگر آن زمان گذشته باشد، روز
              بعد در نظر گرفته می‌شود.)  همچنین می‌توانید midnight (نیمه‌شب)،
              noon (ظهر)، elevenses (ساعت ۱۱ صبح)، fika (ساعت ۳ بعدازظهر) یا
              teatime (ساعت ۴ بعدازظهر) را مشخص کنید و می‌توانید زمان روز را با
              پسوند AM یا PM برای اجرا در صبح یا عصر همراه کنید.  همچنین
              می‌توانید با مشخص کردن تاریخی به شکل MMDDYY یا MM/DD/YY یا
              YYYY-MM-DD تعیین کنید که کار در چه روزی اجرا شود. تاریخ و زمان
              را با استفاده از قالب زیر ترکیب کنید: YYYY-MM-DD[THH:MM[:SS]].
              همچنین می‌توانید زمان‌هایی مانند now + count time-units بدهید، که
              در آن time-units می‌تواند seconds (پیش‌فرض)، minutes، hours، days،
              یا weeks باشد.  کلمات کلیدی today و tomorrow نیز ممکن است
              استفاده شوند.  این مقدار می‌تواند پس از ارسال کار با استفاده از
              دستور scontrol تغییر یابد.  برای مثال:.IP
                 --begin=16:00
                 --begin=now+1hour
                 --begin=now+60           (پیش‌فرض برحسب ثانیه)
                 --begin=2010-01-20T12:34:00


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



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



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



       -M, --clusters=<string>
              خوشه‌هایی که دستورها باید برای آن‌ها صادر شوند. نام چند خوشه را
              می‌توان با کاما از هم جدا کرد. کار به خوشه‌ای ارسال خواهد شد که
              زودترین زمان مورد انتظار برای آغاز کار را ارائه دهد. مقدار
              پیش‌فرض، خوشهٔ فعلی است. مقدار 'all' برای استعلام اجرای کار روی
              تمام خوشه‌ها به کار می‌رود. برای کنترل متغیرهای محیطی صادرشده بین
              خوشه‌ها، به گزینهٔ --export توجه کنید.  توجه داشته باشید که برای
              عملکرد صحیح این گزینه، slurmdbd باید فعال و در حال اجرا باشد،
              مگر اینکه در یک فدراسیون با پیکربندی
              FederationParameters=fed_display اجرا شود.



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



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

              نکته: این گزینه تنها با پلاگین topology/block کار خواهد کرد.



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

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

              گزینه‌های پشتیبانی‌شدهٔ --constraint عبارتند از:


              نام تکی (Single Name)
                     تنها گره‌هایی که دارای ویژگی مشخص‌شده باشند استفاده خواهند
                     شد.  برای نمونه، --constraint="intel"



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

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



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



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



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



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

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

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



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

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

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



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



       --container=<path_to_container>
              مسیر مطلق به بستهٔ کانتینر OCI (OCI container bundle).



       --container-id=<container_id>
              نام یکتا برای کانتینر OCI..IP


       --container-type=<container_type>
              نوع کانتینر برای استفاده در کار.



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

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



       -S, .IP


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



       -d, --dependency=<dependency_list>
              شروع این کار را تا زمانی که وابستگی‌های مشخص‌شده برآورده شوند، به
              تعویق بیندازید. به محض اینکه یک وابستگی برآورده شود، از کار حذف
              خواهد شد.  <dependency_list> به فرم
              <type:job_id[:job_id][,type:job_id[:job_id]]> یا
              <type:job_id[:job_id][?type:job_id[:job_id]]> است.  اگر از
              جداکنندهٔ «,» استفاده شود، تمام وابستگی‌ها باید برآورده شوند.  اگر
              از جداکنندهٔ «?» استفاده شود، برآورده شدن هر یک از وابستگی‌ها کافی
              خواهد بود.  تنها می‌توان از یک جداکننده استفاده کرد. برای نمونه:
              -d afterok:20:21,afterany:23

              بدین معناست که کار تنها پس از بازگشت کد خروج ۰ از کارهای ۲۰ و ۲۱
              و همچنین اتمام کار ۲۳ می‌تواند اجرا شود. با این حال:
              -d afterok:20:21?afterany:23
              بدین معناست که برآورده شدن هر یک از شرایط (afterok:20 یا
              afterok:21 یا afterany:23) برای آزاد شدن کار کافی خواهد بود.
              کارهای متعددی می‌توانند یک وابستگی یکسان را به اشتراک بگذارند و
              این کارها حتی ممکن است متعلق به کاربران مختلفی باشند. این مقدار
              را می‌توان پس از ثبت کار با استفاده از دستور scontrol تغییر داد.
              وابستگی به کارهای راه‌دور در یک فدراسیون مجاز است.  به محض اینکه
              وابستگی یک کار به دلیل وضعیت خاتمهٔ کار پیشین ناموفق شود، کار
              وابسته هرگز اجرا نخواهد شد، حتی اگر کار پیشین دوباره در صف قرار
              گیرد (requeued) و در اجرای بعدی دارای وضعیت خاتمهٔ متفاوتی باشد.


              after:job_id[[+time][:jobid[+time]...]]
                     پس از شروع یا لغو کارهای مشخص‌شده و سپری شدن زمان 'time'
                     به دقیقه از شروع یا لغو کار، این کار می‌تواند اجرای خود را
                     آغاز کند. اگر مقداری برای 'time' داده نشود، هیچ تاخیری پس
                     از شروع یا لغو اعمال نمی‌شود.



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



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



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



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



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



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



       -m,
       --distribution={*|block|cyclic|arbitrary|plane=<size>}[:{*|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> مراجعه کنید.
              روش توزیع اول (توزیع تسک‌ها در سراسر گره‌ها):


              *      از روش پیش‌فرض برای توزیع تسک‌ها روی گره‌ها (block) استفاده
                     می‌کند.  اگر یک افزونهٔ توپولوژی پیکربندی شده باشد و کاربر
                     روش توزیعی را مشخص نکند، تسک‌ها به جای ترتیب نمایهٔ گره، بر
                     اساس ترتیب توپولوژی توزیع می‌شوند. برای غیرفعال کردن این
                     رفتار، به CR_NO_DIST_TOPO_BLOCK در SelectTypeParameters
                     مراجعه کنید.



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



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



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



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


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


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



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



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



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



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


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



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



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



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



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


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



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



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



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



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

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



       --export={[ALL,]<environment_variables>|ALL|NIL|NONE}
              مشخص می‌کند کدام متغیرهای محیطی از محیط ارسال (submission
              environment) به برنامهٔ اجراشده منتقل شوند. توجه داشته باشید که
              متغیرهای SLURM_* همیشه منتقل می‌شوند.

              --export=ALL
                        حالت پیش‌فرض در صورتی که --export مشخص نشده باشد. تمام
                        متغیرهای محیطی کاربر بارگذاری خواهند شد (یا از محیط
                        فراخواننده، یا در صورت مشخص بودن --get-user-env از یک
                        محیط تمیز).



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

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



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

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



              --export=[ALL,]<environment_variables>
                        تمام متغیرهای محیطی SLURM_* و گزینه‌های SPANK را به
                        همراه متغیرهای مشخص‌شده به‌طور صریح صادر می‌کند. نام چند
                        متغیر محیطی باید با کاما از یکدیگر جدا شوند.  نام
                        متغیرهای محیطی را می‌توان برای انتقال مقدار فعلی مشخص
                        کرد (مانند "--export=EDITOR") یا مقادیر خاصی را صادر
                        کرد (مانند "--export=EDITOR=/bin/emacs"). اگر "ALL"
                        تعیین شود، تمام متغیرهای محیطی کاربر بارگذاری شده و بر
                        هر متغیر محیطی که به‌صراحت داده شده اولویت خواهند داشت.

                   مثال: --export=EDITOR,ARG1=test
                        در این مثال، محیط منتقل‌شده تنها شامل متغیر EDITOR از
                        محیط کاربر، متغیرهای محیطی SLURM_*، و ARG1=test خواهد
                        بود.



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

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



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



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

                        اگر SchedulerParameters=extra_constraints فعال باشد،
                        این رشته برای فیلتر کردن گره‌ها بر اساس فیلد Extra در
                        هر گره استفاده می‌شود.



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



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

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



              --gid=<group>
                        اگر sbatch به عنوان کاربر ریشه (root) اجرا شود و از
                        گزینه --gid استفاده شده باشد، کار با دسترسی‌های گروهیِ
                        group ارسال (submit) می‌شود. group می‌تواند نام گروه یا
                        شناسه عددی گروه باشد.
                        نکته: آرگومان --gid منسوخ شده است و در نسخه‌های آینده
                        حذف خواهد شد.



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



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

                        تعاریف پشتیبانی‌شده برای value:

                        low       کمترین فرکانس موجود.



                        medium    تلاش می‌کند تا فرکانسی در میانه محدوده موجود
                                  تنظیم کند.



                        high      بالاترین فرکانس موجود.



                        highm1    (بالا منهای یک) فرکانس بعدیِ نزدیک به
                                  بالاترین فرکانس موجود را انتخاب می‌کند.



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



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

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



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



              --gpus-per-task=[type:]<number>
                        تعداد GPUهای مورد نیاز برای کار را به ازای هر تسکی که
                        قرار است در تخصیص منبع کار اجرا شود، مشخص می‌کند.  مشخص
                        کردن نوع GPU به صورت اختیاری امکان‌پذیر است.  برای مثال
                        "--gpus-per-task=volta:1". امکان درخواست چند گزینه در
                        یک فهرست جداشده با کاما وجود دارد، برای نمونه:
                        "--gpus-per-task=volta:3,kepler:1". همچنین به گزینه‌های
                        --gpus، --gpus-per-socket و --gpus-per-node مراجعه
                        کنید.  این گزینه به یک تعداد تسک صریح نیاز دارد، مانند
                        -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 بازنویسی کرد.



              --gres=<list>
                        فهرستی جداشده با کاما از منابع مصرفی عمومی (generic
                        consumable resources) درخواست‌شده به ازای هر گره را
                        مشخص می‌کند.  قالب هر ورودی در این فهرست
                        "name[[:type]:count]" است.  مقدار name نوع منبع مصرفی
                        است (مانند gpu).  مقدار type یک طبقه‌بندی اختیاری برای
                        منبع است (مانند a100).  مقدار count تعداد آن منابع با
                        مقدار پیش‌فرض 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" است.

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


              --gres-flags=<type>
                        گزینه‌های مقیدسازی وظیفه به منابع عمومی (GRES) را مشخص
                        می‌کند.


                        multiple-tasks-per-sharing
                               گزینهٔ one-task-per-sharing را نقیض (لغو) می‌کند.
                               این گزینه زمانی مفید است که این ویژگی به‌طور
                               پیش‌فرض در SelectTypeParameters تنظیم شده باشد.



                        disable-binding
                               گزینهٔ enforce-binding را نقیض (لغو) می‌کند. این
                               گزینه زمانی مفید است که این ویژگی به‌طور پیش‌فرض
                               در SelectTypeParameters تنظیم شده باشد.



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



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



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



              --hint=<type>
                        وظایف را با توجه به رهنمودهای برنامه (application
                        hints) مقید می‌کند.
                        نکته: این گزینه متضمن مقادیر خاصی برای برخی گزینه‌های
                        مرتبط است، که مانع از استفادهٔ هم‌زمان آن با هر مقدار
                        تعیین‌شده توسط کاربر برای --ntasks-per-core،
                        --cores-per-socket، --sockets-per-node،
                        --threads-per-core یا -B می‌شود.  این گزینه‌های متعارض
                        در صورت مشخص شدن به عنوان آرگومان‌های خط فرمان، بر
                        --hint تقدم خواهند داشت و آن را بازنویسی می‌کنند. اگر
                        یک گزینهٔ متعارض به عنوان متغیر محیطی تعیین شده باشد،
                        --hint به عنوان آرگومان خط فرمان اولویت خواهد داشت.

                        compute_bound
                               تنظیمات برنامه‌های وابسته به پردازش (compute
                               bound) را انتخاب می‌کند: استفاده از تمام هسته‌ها
                               در هر سوکت، یک نخ به ازای هر هسته.



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



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



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



                        help   این پیام راهنما را نمایش می‌دهد



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



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



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

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



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



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



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

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

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

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



              --mail-type=<type>
                        هنگام رخ دادن انواع خاصی از رویدادها، کاربر را از طریق
                        ایمیل مطلع می‌کند.  مقادیر معتبر type عبارتند از: 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 (ارسال ایمیل برای هر وظیفه از آرایه).
                        چندین مقدار type را می‌توان در یک فهرست جداشده با
                        ویرگول مشخص کرد.  مقدار NONE تمام اعلان‌های رویداد را
                        سرکوب کرده و هر مقدار دیگر مشخص‌شده را نادیده می‌گیرد.
                        به‌طور پیش‌فرض هیچ اعلان ایمیلی ارسال نمی‌شود.  کاربری که
                        باید مطلع شود با --mail-user مشخص می‌گردد.

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



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


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



              --mem=<size>[units]
                        حافظه واقعی مورد نیاز به ازای هر گره (node) را مشخص
                        می‌کند.  واحدهای پیش‌فرض مبی‌بایت (mebibytes) هستند.
                        واحدهای مختلف را می‌توان با استفاده از پسوند [K|M|G|T]
                        مشخص کرد.  مقدار پیش‌فرض DefMemPerNode و حداکثر مقدار
                        MaxMemPerNode است. در صورت پیکربندی، هر دو پارامتر را
                        می‌توان با استفاده از دستور scontrol show config مشاهده
                        کرد.  این پارامتر عموماً زمانی استفاده می‌شود که کل
                        گره‌ها به کارها اختصاص داده شوند
                        (SelectType=select/linear).  همچنین به --mem-per-cpu و
                        --mem-per-gpu مراجعه کنید.  گزینه‌های --mem،
                        --mem-per-cpu و --mem-per-gpu مانعة‌الجمع هستند. اگر
                        --mem، --mem-per-cpu یا --mem-per-gpu به‌عنوان
                        آرگومان‌های خط فرمان مشخص شوند، بر متغیرهای محیطی
                        اولویت خواهند داشت.

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

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

                        نکته: درخواست‌های حافظه به‌طور سخت‌گیرانه اعمال نخواهند
                        شد مگر اینکه Slurm برای استفاده از یک مکانیزم اجباری
                        پیکربندی شده باشد. برای جزئیات بیشتر به
                        ConstrainRAMSpace در صفحه راهنمای cgroup.conf(5) و
                        OverMemoryKill در صفحه راهنمای slurm.conf(5) مراجعه
                        کنید.



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

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

                        متغیرهای محیطی اطلاعاتی زیر هنگام استفاده از
                        --mem-bind تنظیم می‌شوند:

                           SLURM_MEM_BIND_LIST
                           SLURM_MEM_BIND_PREFER
                           SLURM_MEM_BIND_TYPE
                           SLURM_MEM_BIND_VERBOSE

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

                        گزینه‌های پشتیبانی‌شده عبارتند از:

                        help   نمایش این پیام راهنما



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



                        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".  برای دستیابی به نتایج
                               اتصال قابل پیش‌بینی، تمام پردازنده‌های هر گره
                               باید به کار تخصیص داده شوند.



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



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



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



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



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



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



              --mem-per-cpu=<size>[units]
                        حداقل حافظه مورد نیاز به ازای هر پردازنده تخصیص‌یافته و
                        قابل استفاده.  واحدهای پیش‌فرض مبی‌بایت هستند.  مقدار
                        پیش‌فرض DefMemPerCPU و حداکثر مقدار MaxMemPerCPU است
                        (استثنای زیر را ببینید). در صورت پیکربندی، هر دو
                        پارامتر را می‌توان با استفاده از دستور scontrol show
                        config مشاهده کرد.  توجه داشته باشید که اگر مقدار
                        --mem-per-cpu کار فراتر از مقدار پیکربندی‌شده
                        MaxMemPerCPU باشد، حد تعیین‌شده توسط کاربر به عنوان حد
                        حافظه به ازای تسک در نظر گرفته خواهد شد؛ مقدار
                        --mem-per-cpu به مقداری کاهش می‌یابد که بیشتر از
                        MaxMemPerCPU نباشد؛ --cpus-per-task تنظیم می‌شود و
                        مقدار --cpus-per-task ضرب در مقدار جدید --mem-per-cpu
                        برابر با مقدار اولیه --mem-per-cpu مشخص‌شده توسط کاربر
                        خواهد بود.  این پارامتر عموماً زمانی استفاده می‌شود که
                        پردازنده‌های مجزا به کارها اختصاص داده شوند
                        (SelectType=select/cons_tres).  اگر منابع بر اساس هسته
                        (core)، سوکت (socket) یا کل گره‌ها تخصیص یابند، تعداد
                        پردازنده‌های اختصاص‌یافته به یک کار ممکن است بیشتر از
                        تعداد تسک‌ها باشد و مقدار --mem-per-cpu باید بر این
                        اساس تنظیم شود.  همچنین به --mem و --mem-per-gpu
                        مراجعه کنید.  گزینه‌های --mem، --mem-per-cpu و
                        --mem-per-gpu مانعة‌الجمع هستند.

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

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

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

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

                        $ 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

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

                        $ 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


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



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



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



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

                        گزینهٔ network در سیستم‌های دارای شبکه‌های HPE Slingshot در دسترس است.
                        می‌توان از آن برای درخواست یک VNI کار (جهت استفاده برای ارتباط میان گام‌های
                        کاری در یک کار) استفاده کرد. همچنین می‌توان از آن برای بازنویسی منابع شبکهٔ
                        پیش‌فرضی که برای گام کاری تخصیص یافته است، استفاده نمود. می‌توان مقادیر متعدد
                        را در یک فهرست جداشده با کاما مشخص کرد.

                        tcs=<class1>[:<class2>]...
                              مجموعه‌ای از کلاس‌های ترافیک برای پیکربندی برنامه‌ها.
                              کلاس‌های ترافیک پشتیبانی‌شده عبارتند از DEDICATED_ACCESS ،LOW_LATENCY ،BULK_DATA
                              و BEST_EFFORT. این کلاس‌های ترافیک را می‌توان به‌صورت TC_DEDICATED_ACCESS ،
                              TC_LOW_LATENCY ،TC_BULK_DATA و TC_BEST_EFFORT نیز مشخص کرد.



                        no_vni
                              هیچ VNIای برای این کار تخصیص داده نشود (حتی اگر چندگره‌ای باشد).



                        job_vni
                              تخصیص یک VNI کار برای این کار.



                        single_node_vni
                              تخصیص یک VNI کار برای این کار، حتی اگر یک کار تک‌گره‌ای باشد.



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



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



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



                        nic_distribution_count=<val>
                              تعداد NICهایی که کاربر تسک‌های خود را به‌طور مساوی روی آن‌ها توزیع خواهد کرد.
                              مقدار پیش‌فرض برابر با تعداد NICها در هر گره است.



                        def_<rsrc>=<val>
                              تخصیص رزروشده به ازای هر CPU برای این منبع.



                        res_<rsrc>=<val>
                              تخصیص رزروشده به ازای هر گره برای این منبع.
                              در صورت تنظیم، تخصیص به ازای هر CPU را لغو و بازنویسی می‌کند.



                        max_<rsrc>=<val>
                              حداکثر حد مجاز به ازای هر گره برای این منبع.



                        depth=<depth>
                              ضریب برای تخصیص منابع به ازای هر CPU.
                              مقدار پیش‌فرض برابر با تعداد CPUهای رزروشده در گره است.


                        منابعی که می‌توان درخواست کرد عبارتند از:

                        txqs  صف‌های فرمان ارسال (Transmit command queues). مقدار پیش‌فرض ۲ به ازای هر CPU و حداکثر ۱۰۲۴ به ازای هر گره است.



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



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



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



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



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



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



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


                        در سیستم‌هایی که با SwitchType=switch/nvidia_imex پیکربندی شده‌اند،
                        گزینه‌های زیر پشتیبانی می‌شوند:

                        unique-channel-per-segment
                               به‌جای یک کانال برای کل کار، یک کانال به ازای هر سگمنت در کار تخصیص داده می‌شود.
                               این مورد تنها زمانی اعمال می‌گردد که topology/block پیکربندی شده باشد.





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

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

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



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

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



              -F, --nodefile=<node_file>
                        بسیار شبیه به --nodelist است، اما فهرست در فایلی با نام node file قرار دارد. نام‌های گره‌های فهرست می‌توانند در چندین خط در فایل نیز گسترش یابند. نام‌های تکراری گره‌ها در فایل نادیده گرفته خواهند شد.
                        ترتیب نام گره‌ها در فهرست مهم نیست؛ نام‌های گره‌ها توسط Slurm مرتب خواهند شد.



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

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

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



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

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



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



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



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



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



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



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



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



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

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

                        هنگامی که بر تخصیص‌های گام کار (دستور srun در هنگام اجرا درون یک تخصیص کار موجود) اعمال شود، این گزینه می‌تواند برای راه‌اندازی بیش از یک تسک به ازای هر پردازنده استفاده شود.
                        در حالت عادی، srun بیش از یک فرایند را به ازای هر پردازنده تخصیص نمی‌دهد.
                        با مشخص کردن --overcommit، شما صریحاً اجازه اجرای بیش از یک فرایند به ازای هر پردازنده را می‌دهید. با این حال، اجرای بیش از MAX_TASKS_PER_NODE تسک به ازای هر گره مجاز نیست. نکته: مقدار MAX_TASKS_PER_NODE در فایل slurm.h تعریف شده است و یک متغیر نیست، بلکه در زمان ساخت Slurm تنظیم می‌شود.



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

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



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



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



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


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



              --profile={all|none|<type>[,<type>...]}
                        جمع‌آوری جزئیات داده‌ها توسط افزونه acct_gather_profile را فعال می‌کند.
                        داده‌های تفصیلی معمولاً سری‌های زمانی هستند که بسته به افزونه پیکربندی‌شده، در یک فایل HDF5 برای کار یا در یک پایگاه داده InfluxDB ذخیره می‌شوند.

                        All       تمام انواع داده‌ها جمع‌آوری می‌شوند. (نمی‌توان با مقادیر دیگر ترکیب کرد.)



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


                        مقادیر معتبر type عبارتند از:

                        Energy داده‌های مصرف انرژی جمع‌آوری می‌شود.



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



                        Lustre داده‌های Lustre جمع‌آوری می‌شود.



                        Network
                               داده‌های شبکه (InfiniBand) جمع‌آوری می‌شود.



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

                        ALL       تمام محدودیت‌های فهرست‌شده در زیر (پیش‌فرض)



                        NONE      هیچ‌یک از محدودیت‌های فهرست‌شده در زیر



                        AS        حداکثر فضای آدرس‌دهی (حافظه مجازی) برای یک فرایند.



                        CORE      حداکثر اندازه فایل core (تخلیه حافظه).



                        CPU       حداکثر مدت زمان پردازنده (CPU time).



                        DATA      حداکثر اندازه بخش داده (data segment) یک فرایند.



                        FSIZE     حداکثر اندازه فایل‌های ایجادشده. توجه داشته باشید که اگر کاربر FSIZE را به مقداری کمتر
                                  از اندازه فعلی slurmd.log تنظیم کند، راه‌اندازی کار با خطای
                                  'File size limit exceeded' شکست خواهد خورد.



                        MEMLOCK   حداکثر اندازه‌ای که می‌توان در حافظه قفل کرد.



                        NOFILE    حداکثر تعداد فایل‌های باز.



                        NPROC     حداکثر تعداد فرایندهای در دسترس.



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



                        STACK     حداکثر اندازه پشته (stack size).



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


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



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



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

                        پارامتر اختیاری expedite درخواست می‌کند که کار بلافاصله دوباره واجد شرایط شروع باشد و با بالاترین اولویت ممکن زمان‌بندی شود.
                        این اتفاق تنها در صورتی رخ خواهد داد که قرارگیری مجدد سریع در صف به‌صورت سراسری با SlurmctldParameters=enable_expedited_requeue در slurm.conf مجاز شده باشد.



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



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

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



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



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

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

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



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



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



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



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

                        نکته: این گزینه تنها با پلاگین topology/block کار خواهد کرد.



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



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



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



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

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



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



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

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


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



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



              --tres-bind=<tres>:[verbose,]<type>[+<tres>:
                        [verbose,]<type>...]
                        فهرستی از 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ها به وظایف منفرد متصل نمی‌شوند.

                        گزینه‌های نوع (type) اتصال پشتیبانی‌شده برای gres:

                        closest   هر وظیفه (task) را به نزدیک‌ترین gres(ها) متصل می‌کند.
                                  در یک محیط NUMA، هر وظیفه ممکن است به بیش از یک gres متصل شود (یعنی
                                  تمام gresهای موجود در آن محیط NUMA).



                        map:<list>
                                  اتصال با تنظیم ماسک‌های 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های روی هر گره در کار باید تخصیص داده شوند.



                        mask:<list>
                                  اتصال با تنظیم ماسک‌های 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های روی هر
                                  گره در کار باید تخصیص داده شوند.



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



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



                        single:<tasks_per_gres>
                                  مشابه closest است، با این تفاوت که هر وظیفه تنها می‌تواند به یک gres واحد متصل شود،
                                  حتی زمانی که بتواند به چند gres که به یک اندازه نزدیک هستند متصل گردد. gres مورد نظر برای
                                  اتصال توسط <tasks_per_gres> تعیین می‌شود، که در آن اولین وظایف به تعداد
                                  <tasks_per_gres> به اولین gres موجود متصل می‌شوند، دومین دسته از وظایف به تعداد
                                  <tasks_per_gres> به دومین gres موجود متصل می‌شوند و الی آخر.
                                  این در واقع یک توزیع بلوکی وظایف بر روی gresهای موجود است، که در آن gresهای موجود توسط
                                  همبستگی سوکتِ وظیفه و همبستگی سوکتِ gres طبق پارامتر Cores در gres.conf تعیین می‌شوند.


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



              --tres-per-task=<list>
                        فهرستی جداشده با کاما از منابع قابل‌ردیابی مورد نیاز کار به ازای هر وظیفه‌ای که در
                        تخصیص منابع کار ایجاد خواهد شد را مشخص می‌کند.
                        قالب هر مدخل در فهرست به صورت "trestype[/tresname]=count" است.
                        مقدار trestype نوع منبع قابل‌ردیابی درخواستی است (مانند cpu، gres، license و غیره).
                        مقدار tresname نام منبع قابل‌ردیابی است، همان‌طور که با sacctmgr show tres قابل
                        مشاهده است. این مقدار در صورت وجود برای انواع tres مانند gres، license و غیره الزامی است
                        (مانند gpu، gpu:a100).
                        به منظور درخواست مجوز (license) با این گزینه، مجوز(ها) باید در پارامتر
                        AccountingStorageTRES فایل slurm.conf تعریف شده باشند.
                        مقدار count تعداد آن منابع است.
                        تعداد می‌تواند دارای پسوندی از موارد زیر باشد:
                        "k" یا "K" (مضرب ۱۰۲۴)،
                        "m" یا "M" (مضرب ۱۰۲۴ × ۱۰۲۴)،
                        "g" یا "G" (مضرب ۱۰۲۴ × ۱۰۲۴ × ۱۰۲۴)،
                        "t" یا "T" (مضرب ۱۰۲۴ × ۱۰۲۴ × ۱۰۲۴ × ۱۰۲۴)،
                        "p" یا "P" (مضرب ۱۰۲۴ × ۱۰۲۴ × ۱۰۲۴ × ۱۰۲۴ × ۱۰۲۴).
                        مثال‌ها:
                        --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
                        منابع مشخص‌شده روی هر گره به کار تخصیص داده خواهند شد.
                        منابع قابل‌ردیابیِ در دسترس توسط مدیر سیستم قابل‌پیکربندی
                        هستند.
                        نکته: این گزینه به همراه 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 لغو کرد.
                        نکته: منابع TRES نامعتبر برای --tres-per-task شامل bb،
                        billing، energy، fs، mem، node، pages و vmem هستند.



              --uid=<user>
                        تلاش برای ارسال و/یا اجرای یک کار به عنوان user به جای
                        شناسه کاربر فراخواننده.  از اعتبارنامه‌های کاربر
                        فراخواننده برای بررسی مجوزهای دسترسی به پارتیشن هدف
                        استفاده خواهد شد. برای مثال، کاربر root می‌تواند از این
                        گزینه برای اجرای کارها به عنوان یک کاربر عادی در یک
                        پارتیشن RootOnly استفاده کند. در صورت اجرا به عنوان
                        root، دستور sbatch پس از تخصیص موفقیت‌آمیز گره،
                        دسترسی‌های خود را به uid مشخص‌شده کاهش می‌دهد.  user ممکن
                        است نام کاربری یا شناسه کاربری عددی باشد.
                        نکته: آرگومان --uid منسوخ شده است و در نسخه‌های آینده
                        حذف خواهد شد.



              --usage   نمایش پیام راهنمای مختصر و خروج.



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



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



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



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

                        0    به محض اینکه امکان تخصیص فراهم شود، اجرا را آغاز
                             کن.  برای آماده‌سازی و در دسترس قرار گرفتن همه
                             گره‌ها (یعنی بوت شدن آن‌ها) منتظر نمان.



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



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



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



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


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



       %%     نویسه «%».



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



       %a     شناسه (شاخص) آرایه کارها.



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



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



       %j     مقدار jobid کار در حال اجرا.



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



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



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



       %S     مقدار SLUID کار در حال اجرا.



       %s     مقدار stepid کار در حال اجرا.



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



       %u     نام کاربر.



       %x     نام کار.



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


       job%J.out      job128.0.out



       job%4j.out     job0128.out



       job%2j-%2t.out job128-00.out, job128-01.out, ...

       اجرای sbatch یک فراخوانی روال از راه دور (RPC) به slurmctld ارسال
       می‌کند. اگر تعداد فراخوانی‌های هم‌زمان از سوی sbatch یا سایر دستورهای
       کلاینت Slurm که فراخوانی‌های روال از راه دور به دیمن slurmctld می‌فرستند
       به حد کافی زیاد باشد، می‌تواند منجر به افت کارایی دیمن slurmctld و
       احتمالاً بروز وضعیت منع سرویس (denial of service) شود.

       دستور sbatch یا سایر دستورهای کلاینت Slurm را که فراخوانی‌های روال از
       راه دور به slurmctld ارسال می‌کنند، از درون حلقه‌ها در اسکریپت‌های شل یا
       دیگر برنامه‌ها اجرا نکنید. اطمینان حاصل کنید که برنامه‌ها فراخوانی‌های
       sbatch را به حداقل میزان لازم برای اطلاعاتی که در پی گردآوری آن هستید
       محدود کنند.


متغیرهای محیطی ورودی (INPUT ENVIRONMENT VARIABLES)
       هنگام راه‌اندازی، sbatch گزینه‌های تعیین‌شده در متغیرهای محیطی زیر را
       خوانده و پردازش خواهد کرد.  بخش عمده‌ای از این متغیرها به همان شیوه‌ای که
       گزینه‌ها در بالا تعریف شده‌اند، مقداردهی می‌شوند.  برای گزینه‌های پرچمی که
       به‌گونه‌ای تعریف شده‌اند که هیچ آرگومانی نمی‌پذیرند، می‌توان گزینه را با
       تنظیم متغیر محیطی بدون مقدار (رشته خالی یا NULL)، رشته 'yes' یا یک عدد
       غیرصفر فعال کرد.  هر مقدار دیگری برای متغیر محیطی منجر به فعال نشدن
       گزینه خواهد شد.  چندین استثنا برای این قواعد وجود دارد که در ادامه ذکر
       شده‌اند.
       نکته: متغیرهای محیطی بر هر گزینه‌ای که در یک اسکریپت batch تنظیم شده
       باشد اولویت دارند (آن را بازنویسی می‌کنند)، و گزینه‌های خط فرمان نیز بر
       تمامی متغیرهای محیطی اولویت خواهند داشت.


       SBATCH_ACCOUNT        مشابه -A, --account



       SBATCH_ACCTG_FREQ     مشابه --acctg-freq



       SBATCH_ARRAY_INX      مشابه -a, --array



       SBATCH_BATCH          مشابه --batch



       SBATCH_CLUSTERS یا SLURM_CLUSTERS
                             مشابه --clusters



       SBATCH_CONSTRAINT     مشابه -C, --constraint



       SBATCH_CONTAINER      مشابه --container.



       SBATCH_CONTAINER_ID   مشابه --container-id.



       SBATCH_CONTAINER_TYPE مشابه --container-type.



       SBATCH_CORE_SPEC      مشابه --core-spec



       SBATCH_CPUS_PER_GPU   مشابه --cpus-per-gpu



       SBATCH_DEBUG          مشابه -v, --verbose هنگام تنظیم روی ۱؛ تنظیم روی
                             ۲ معادل -vv خواهد بود، و غیره.



       SBATCH_DELAY_BOOT     مشابه --delay-boot



       SBATCH_DISTRIBUTION   مشابه -m, --distribution



       SBATCH_ERROR          مشابه -e, --error



       SBATCH_EXCLUSIVE      مشابه --exclusive



       SBATCH_EXPORT         مشابه --export



       SBATCH_GET_USER_ENV   مشابه --get-user-env



       SBATCH_GPU_BIND       مشابه --gpu-bind



       SBATCH_GPU_FREQ       مشابه --gpu-freq



       SBATCH_GPUS           مشابه -G, --gpus



       SBATCH_GPUS_PER_NODE  مشابه --gpus-per-node



       SBATCH_GPUS_PER_TASK  مشابه --gpus-per-task



       SBATCH_GRES           مشابه --gres



       SBATCH_GRES_FLAGS     مشابه --gres-flags



       SBATCH_HINT یا SLURM_HINT
                             مشابه --hint



       SBATCH_IGNORE_PBS     مشابه --ignore-pbs



       SBATCH_INPUT          مشابه -i, --input



       SBATCH_JOB_NAME       مشابه -J, --job-name



       SBATCH_MEM_BIND       مشابه --mem-bind



       SBATCH_MEM_PER_CPU    مشابه --mem-per-cpu



       SBATCH_MEM_PER_GPU    مشابه --mem-per-gpu



       SBATCH_MEM_PER_NODE   مشابه --mem



       SBATCH_NETWORK        مشابه --network



       SBATCH_NO_KILL        مشابه -k, --no-kill.IP


       SBATCH_NO_REQUEUE     همانند --no-requeue



       SBATCH_OPEN_MODE      همانند --open-mode



       SBATCH_OUTPUT         همانند -o, --output



       SBATCH_OVERCOMMIT     همانند -O, --overcommit



       SBATCH_PARTITION      همانند -p, --partition



       SBATCH_POWER          همانند --power



       SBATCH_PROFILE        همانند --profile



       SBATCH_QOS            همانند --qos



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



       SBATCH_REQUEUE        همانند --requeue



       SBATCH_RESERVATION    همانند --reservation



       SBATCH_SEGMENT_SIZE   همانند --segment



       SBATCH_SIGNAL         همانند --signal



       SBATCH_SPREAD_JOB     همانند --spread-job



       SBATCH_THREAD_SPEC    همانند --thread-spec



       SBATCH_THREADS_PER_CORE
                             همانند --threads-per-core



       SBATCH_TIMELIMIT      همانند -t, --time



       SBATCH_TRES_BIND      همانند --tres-bind



       SBATCH_TRES_PER_TASK  همانند --tres-per-task



       SBATCH_USE_MIN_NODES  همانند --use-min-nodes



       SBATCH_WAIT           همانند -W، --wait



       SBATCH_WAIT_ALL_NODES همانند --wait-all-nodes. برای غیرفعال یا فعال
                             کردن گزینه باید روی 0 یا 1 تنظیم شود.



       SBATCH_WAIT4SWITCH    بیشینهٔ زمان انتظار برای سوییچ‌های درخواستی. به
                             --switches مراجعه کنید.



       SBATCH_WCKEY          همانند --wckey



       SLURM_CONF            مکان فایل پیکربندی Slurm.



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



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



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



       SLURM_UMASK           در صورت تعریف شدن، Slurm هنگام ایجاد فایل‌های
                             خروجی/خطای کار، از umask تعریف‌شده برای تنظیم
                             مجوزها استفاده خواهد کرد.

       کنترل‌کننده Slurm متغیرهای زیر را در محیط اسکریپت دسته‌ای (batch script)
       تنظیم خواهد کرد.


       SBATCH_MEM_BIND
              برابر با مقدار گزینه --mem-bind تنظیم می‌شود.



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



       SBATCH_MEM_BIND_PREFER
              اگر گزینه --mem-bind شامل گزینه prefer باشد، برابر با “prefer”
              تنظیم می‌شود.



       SBATCH_MEM_BIND_TYPE
              برابر با نوع مقیدسازی حافظه تعیین‌شده با گزینه --mem-bind تنظیم
              می‌شود.  مقادیر ممکن عبارتند از “none”،‏ “rank”،‏ “map_mem:”،‏
              “mask_mem:” و “local”.



       SBATCH_MEM_BIND_VERBOSE
              اگر گزینه --mem-bind شامل گزینه verbose باشد، برابر با “verbose”
              تنظیم می‌شود.  در غیر این صورت برابر با “quiet” تنظیم می‌گردد.



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



       SLURM_ARRAY_JOB_ID
              شناسه کار اصلی (master job ID) آرایه کار (job array).



       SLURM_ARRAY_TASK_COUNT
              تعداد کل وظایف در یک آرایه کار.



       SLURM_ARRAY_TASK_ID
              شماره شناسه (نمایه) وظیفه در آرایه کار.



       SLURM_ARRAY_TASK_MAX
              بیشترین شماره شناسه (نمایه) آرایه کار.



       SLURM_ARRAY_TASK_MIN
              کمترین شماره شناسه (نمایه) آرایه کار.



       SLURM_ARRAY_TASK_STEP
              اندازه گام نمایه در آرایه کار.



       SLURM_CLUSTER_NAME
              نام کلاستری که کار روی آن در حال اجرا است.



       SLURM_CPUS_ON_NODE
              تعداد CPUهای اختصاص‌یافته به گام دسته‌ای.  نکته: پلاگین
              select/linear گره‌های کامل را به کارها تخصیص می‌دهد، بنابراین این
              مقدار بیانگر تعداد کل CPUهای موجود روی گره است.  برای پلاگین
              cons/tres، این مقدار بیانگر تعداد CPUهای تخصیص‌یافته به این گام
              روی این گره است.



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



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



       SLURM_CONTAINER
              بسته OCI (OCI Bundle) برای کار.  تنها در صورتی تنظیم می‌شود که
              --container مشخص شده باشد.



       SLURM_CONTAINER_ID
              شناسه OCI برای کار.  تنها در صورتی تنظیم می‌شود که --container-id
              مشخص شده باشد.



       SLURM_CONTAINER_TYPE
              نوع کانتینر برای کار.  تنها در صورتی تنظیم می‌شود که
              --container-type مشخص شده باشد.



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



       SLURM_DISTRIBUTION
              مشابه -m, --distribution.



       SLURM_EXPORT_ENV
              مشابه --export.



       SLURM_GPU_BIND
              مقیدسازی درخواستی وظایف به GPU.  تنها در صورتی تنظیم می‌شود که
              گزینه --gpu-bind مشخص شده باشد.



       SLURM_GPU_FREQ
              فرکانس درخواستی GPU.  تنها در صورتی تنظیم می‌شود که گزینه
              --gpu-freq مشخص شده باشد.



       SLURM_GPUS
              تعداد GPUهای درخواستی.  تنها در صورتی تنظیم می‌شود که گزینه -G,
              --gpus مشخص شده باشد.



       SLURM_GPUS_ON_NODE
              تعداد GPUهای تخصیص‌یافته به گام دسته‌ای.



       SLURM_GPUS_PER_NODE
              تعداد GPUهای درخواستی به ازای هر گره تخصیص‌یافته.  تنها در صورتی
              تنظیم می‌شود که گزینه --gpus-per-node مشخص شده باشد.



       SLURM_GPUS_PER_SOCKET
              تعداد GPUهای درخواستی به ازای هر سوکت تخصیص‌یافته.  تنها در صورتی
              تنظیم می‌شود که گزینه --gpus-per-socket مشخص شده باشد.



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



       SLURM_HET_SIZE
              برابر با تعداد مؤلفه‌ها در یک کار ناهمگن تنظیم می‌شود.



       SLURM_JOB_ACCOUNT
              نام حساب کاربری (account) مرتبط با تخصیص کار.



       SLURM_JOB_CPUS_PER_NODE
              تعداد CPUهای در دسترس کار روی گره‌های موجود در تخصیص، با فرمت
              CPU_count[(xnumber_of_nodes)][,CPU_count [(xnumber_of_nodes)]
              ...].  برای مثال: SLURM_JOB_CPUS_PER_NODE='72(x2),36' نشان می‌دهد
              که در گره اول و دوم (همان‌طور که توسط SLURM_JOB_NODELIST فهرست
              شده است) تخصیص دارای ۷۲ پردازنده است، در حالی که گره سوم دارای
              ۳۶ پردازنده است.  نکته: پلاگین select/linear کل گره‌ها را به
              کارها تخصیص می‌دهد، بنابراین این مقدار بیانگر تعداد کل CPUها روی
              گره‌های تخصیص‌یافته است. پلاگین select/cons_tres پردازنده‌های
              جداگانه را به کارها تخصیص می‌دهد، بنابراین این عدد بیانگر تعداد
              CPUهای تخصیص‌یافته به کار است.



       SLURM_JOB_DEPENDENCY
              برابر با مقدار گزینه --dependency تنظیم می‌شود..IP


       SLURM_JOB_END_TIME
              برچسب زمانی یونیکس (UNIX timestamp) برای زمان تخمینی پایان کار.



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



       SLURM_JOB_ID
              شناسهٔ تخصیص کار.



       SLURM_JOB_LICENSES
              نام و تعداد هر مجوزی که درخواست شده است.



       SLURM_JOB_NAME
              نام کار.



       SLURM_JOB_NODELIST
              فهرست گره‌های اختصاص‌یافته به کار.



       SLURM_JOB_NUM_NODES
              تعداد کل گره‌ها در تخصیص منابع کار.



       SLURM_JOB_PARTITION
              نام پارتیشنی که کار در آن در حال اجرا است.



       SLURM_JOB_QOS
              کیفیت خدمات (QOS) تخصیص کار.



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



       SLURM_JOB_SEGMENT_SIZE
              اندازهٔ بخش‌هایی (segments) که برای ایجاد تخصیص کار استفاده شده
              است.  تنها در صورتی تنظیم می‌شود که --segment مشخص شده باشد.



       SLURM_JOB_START_TIME
              برچسب زمانی یونیکس (UNIX timestamp) برای زمان شروع کار.



       SLURM_JOBID
              شناسهٔ تخصیص کار. SLURM_JOB_ID را ببینید. برای سازگاری با نسخه‌های
              پیشین گنجانده شده است.



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



       SLURM_MEM_PER_CPU
              مشابه --mem-per-cpu



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



       SLURM_MEM_PER_NODE
              مشابه --mem



       SLURM_NETWORK
              در صورت تعیین، با مقدار گزینهٔ --network تنظیم می‌شود.



       SLURM_NNODES
              تعداد کل گره‌ها در تخصیص منابع کار. SLURM_JOB_NUM_NODES را
              ببینید. برای سازگاری با نسخه‌های پیشین گنجانده شده است.



       SLURM_NODEID
              شناسهٔ گره‌های تخصیص‌یافته.



       SLURM_NODELIST
              فهرست گره‌های اختصاص‌یافته به کار. SLURM_JOB_NODELIST را ببینید.
              برای سازگاری با نسخه‌های پیشین گنجانده شده است.



       SLURM_NPROCS
              مشابه SLURM_NTASKS. برای سازگاری با نسخه‌های پیشین گنجانده شده
              است.



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

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



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




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



       SLURM_NTASKS_PER_NODE
              تعداد وظایف درخواستی به ازای هر گره.  تنها در صورتی تنظیم می‌شود
              که گزینهٔ --ntasks-per-node مشخص شده باشد.



       SLURM_NTASKS_PER_SOCKET
              تعداد وظایف درخواستی به ازای هر سوکت.  تنها در صورتی تنظیم می‌شود
              که گزینهٔ --ntasks-per-socket مشخص شده باشد.



       SLURM_OOMKILLSTEP
              مشابه --oom-kill-step



       SLURM_OVERCOMMIT
              در صورتی که --overcommit مشخص شده باشد، روی 1 تنظیم می‌شود.



       SLURM_PRIO_PROCESS
              اولویت زمان‌بندی (مقدار nice) در زمان ارسال کار.  این مقدار به
              فرایندهای ایجادشده منتقل می‌شود.



       SLURM_PROCID
              رتبهٔ MPI (یا شناسهٔ نسبی فرایند) برای فرایند کنونی.



       SLURM_PROFILE
              مشابه --profile



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



       SLURM_SHARDS_ON_NODE
              تعداد GPU Shardهای در دسترس برای این گام در این گره.



       SLURM_SUBMIT_DIR
              دایرکتوری‌ای که sbatch از آن فراخوانی شده است.



       SLURM_SUBMIT_HOST
              نام میزبان (hostname) رایانه‌ای که sbatch از آن فراخوانی شده
              است..IP


       SLURM_TASK_PID
              شناسه فرایند (PID) تسکی که راه‌اندازی می‌شود.



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



       SLURM_THREADS_PER_CORE
              این متغیر تنها زمانی تنظیم می‌شود که --threads-per-core یا
              SBATCH_THREADS_PER_CORE مشخص شده باشند. مقدار آن برابر با مقدار
              تعیین‌شده توسط --threads-per-core یا SBATCH_THREADS_PER_CORE
              خواهد بود. این متغیر توسط فراخوانی‌های بعدی srun درون تخصیص کار
              استفاده می‌شود.



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



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



       SLURM_TRES_PER_TASK
              روی مقدار --tres-per-task تنظیم می‌شود. اگر --cpus-per-task یا
              --gpus-per-task مشخص شده باشد، در SLURM_TRES_PER_TASK نیز تنظیم
              می‌شود، گویی در --tres-per-task مشخص شده بود.



       SLURMD_NODENAME
              نام گره‌ای که اسکریپت کار را اجرا می‌کند.



مثال‌ها (EXAMPLES)
       تعیین یک اسکریپت دسته‌ای با استفاده از نام فایل در خط فرمان. این اسکریپت
       دسته‌ای یک محدودیت زمانی ۱ دقیقه‌ای برای کار تعیین می‌کند.

              $ 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


       ارسال یک اسکریپت دسته‌ای به sbatch از طریق ورودی استاندارد:

              $ sbatch -N4 <<EOF
              > #!/bin/sh
              > srun hostname |sort
              > EOF
              sbatch: Submitted batch job 65541

              $ cat slurm-65541.out
              host1
              host2
              host3
              host4


       برای ایجاد یک کار ناهمگن با ۳ جزء، به طوری که هر یک مجموعه‌ای یکتا از
       گره‌ها را تخصیص دهند:

              $ sbatch -w node[2-3] : -w node4 : -w node[5-7] work.bash
              Submitted batch job 34987


کپی‌رایت و تکثیر (COPYING)
       Copyright (C) 2006-2007 The Regents of the University of California.
       تولید شده در Lawrence Livermore National Laboratory (ر.ک. DISCLAIMER).
       Copyright (C) 2008-2010 Lawrence Livermore National Security.
       Copyright (C) 2010-2022 SchedMD LLC.

       این فایل بخشی از Slurm، یک برنامه مدیریت منابع است.  برای جزئیات بیشتر،
       <https://slurm.schedmd.com> را ببینید.

       نرم‌افزار Slurm یک نرم‌افزار آزاد است؛ شما می‌توانید آن را تحت شرایط «GNU
       General Public License» همان‌طور که توسط بنیاد نرم‌افزارهای آزاد منتشر
       شده است، چه نسخه ۲ مجوز یا (به انتخاب خودتان) هر نسخه بعدی، بازتوزیع
       کرده یا تغییر دهید.

       نرم‌افزار Slurm به این امید که مفید واقع شود توزیع شده است، اما بدون
       هرگونه ضمانت؛ حتی بدون ضمانت ضمنی قابلیت فروش یا مناسب بودن برای یک هدف
       خاص. برای جزئیات بیشتر GNU General Public License را ببینید..SH "همچنین
       ببینید (SEE ALSO)"

       sinfo(1), sattach(1), salloc(1), squeue(1), scancel(1), scontrol(1),
       slurm.conf(5), sched_setaffinity (2), numa (3)

Slurm 26.05                     Slurm Commands                       sbatch(1)