विषय पर बढ़ें

भाग 6: Hello Config

AI-सहायता प्राप्त अनुवाद - अधिक जानें और सुधार सुझाएं

Nextflow YouTube channel पर पूरी playlist देखें।

📗 वीडियो transcript यहाँ उपलब्ध है।

यह section explore करेगा कि अपनी Nextflow pipeline का configuration कैसे set up और manage करें ताकि तुम इसके behavior को customize कर सको, इसे different environments में adapt कर सको, और resource usage optimize कर सको बिना workflow code की single line को alter किए।

ऐसा करने के multiple ways हैं, जो combination में use किए जा सकते हैं और configuration documentation में described order of precedence के अनुसार interpret किए जाते हैं।

इस course के part में, हम तुम्हें सबसे simple और common configuration file mechanism, nextflow.config file दिखाएंगे, जो तुमने Part 5: Hello Containers में पहले ही encounter किया था।

हम Nextflow configuration के essential components जैसे process directives, executors, profiles, और parameter files को cover करेंगे। इन configuration options को effectively utilize करना सीखकर, तुम अपनी pipelines की flexibility, scalability, और performance enhance कर सकते हो।

इस section से कैसे शुरू करें

Course का यह section मानता है कि तुमने Hello Nextflow course के Parts 1-5 complete कर लिए हैं और एक complete working pipeline है।

यदि तुम इस point से course शुरू कर रहे हो, तो तुम्हें solutions से modules directory और nextflow.config file copy करनी होगी:

cp -r solutions/5-hello-containers/modules .
cp solutions/5-hello-containers/nextflow.config .

nextflow.config file में line docker.enabled = true है जो Docker containers का use enable करती है।

यदि तुम Hello pipeline से familiar नहीं हो या तुम्हें reminder चाहिए, तो यह info page देखो।

0. Warmup: hello-config.nf चलाएं

हम starting point के रूप में workflow script hello-config.nf use करेंगे। यह इस training course के Part 5 में produce की गई script के equivalent है, except हमने output destinations change कर दिए हैं:

hello-config.nf
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
output {
    first_output {
        path 'hello_config/intermediates'
        mode 'copy'
    }
    uppercased {
        path 'hello_config/intermediates'
        mode 'copy'
    }
    collected {
        path 'hello_config/intermediates'
        mode 'copy'
    }
    batch_report {
        path 'hello_config'
        mode 'copy'
    }
    cowpy_art {
        path 'hello_config'
        mode 'copy'
    }
}

यह sure करने के लिए कि सब कुछ काम कर रहा है, कोई भी changes करने से पहले script को एक बार run करो:

nextflow run hello-config.nf
कमांड आउटपुट 
 N E X T F L O W   ~  version 25.10.2

Launching `hello-config.nf` [nice_escher] DSL2 - revision: d5dfdc9872

executor > local (7)
[6a/bc46a6] sayHello (2) [100%] 3 of 3 ✔
[33/67bc48] convertToUpper (3) [100%] 3 of 3 ✔
[b5/de03ba] collectGreetings [100%] 1 of 1 ✔
[98/c6b57b] cowpy              | 1 of 1 ✔

पहले की तरह, तुम output files को output block में specified directory (results/hello_config/) में पाओगे।

Directory contents 
results/hello_config/
├── cowpy-COLLECTED-batch-output.txt
├── intermediates
│   ├── Bonjour-output.txt
│   ├── COLLECTED-batch-output.txt
│   ├── Hello-output.txt
│   ├── Holà-output.txt
│   ├── UPPER-Bonjour-output.txt
│   ├── UPPER-Hello-output.txt
│   └── UPPER-Holà-output.txt
└── batch-report.txt

Final ASCII art output results/hello_config/ directory में है, cowpy-COLLECTED-batch-output.txt name के under।

फ़ाइल contents
results/hello_config/cowpy-COLLECTED-batch-output.txt
_________
/ HOLà    \
| HELLO   |
\ BONJOUR /
---------
  \                                  ,+*^^*+___+++_
  \                           ,*^^^^              )
    \                       _+*                     ^**+_
    \                    +^       _ _++*+_+++_,         )
              _+^^*+_    (     ,+*^ ^          \+_        )
            {       )  (    ,(    ,_+--+--,      ^)      ^\
            { (\@)    } f   ,(  ,+-^ __*_*_  ^^\_   ^\       )
          {:;-/    (_+*-+^^^^^+*+*<_ _++_)_    )    )      /
          ( /  (    (        ,___    ^*+_+* )   <    <      \
          U _/     )    *--<  ) ^\-----++__)   )    )       )
            (      )  _(^)^^))  )  )\^^^^^))^*+/    /       /
          (      /  (_))_^)) )  )  ))^^^^^))^^^)__/     +^^
        (     ,/    (^))^))  )  ) ))^^^^^^^))^^)       _)
          *+__+*       (_))^)  ) ) ))^^^^^^))^^^^^)____*^
          \             \_)^)_)) ))^^^^^^^^^^))^^^^)
          (_             ^\__^^^^^^^^^^^^))^^^^^^^)
            ^\___            ^\__^^^^^^))^^^^^^^^)\\
                  ^^^^^\uuu/^^\uuu/^^^^\^\^\^\^\^\^\^\
                    ___) >____) >___   ^\_\_\_\_\_\_\)
                    ^^^//\\_^^//\\_^       ^(\_\_\_\)
                      ^^^ ^^ ^^^ ^

यदि यह तुम्हारे लिए काम किया, तो तुम अपनी pipelines configure करना सीखने के लिए ready हो।

1. Workflow input parameters manage करें

हम configuration के एक aspect से शुरू करेंगे जो हम अब तक काम कर रहे थे उसका simply extension है: input parameters का management।

Currently, हमारा workflow command-line के through कई parameter values accept करने के लिए set up है, जिनकी default values workflow script में params block में set हैं। हालाँकि, तुम उन defaults को override करना चाहते हो बिना parameters को command line पर specify करने या original script file modify करने के।

ऐसा करने के multiple ways हैं; हम तुम्हें तीन basic ways दिखाएंगे जो बहुत commonly use होते हैं।

1.1. Default values को nextflow.config में move करें

यह सबसे simple approach है, हालाँकि यह possibly सबसे least flexible है क्योंकि main nextflow.config file कुछ ऐसा नहीं है जिसे तुम हर run के लिए edit करना चाहोगे। लेकिन इसका advantage है कि यह parameters declare करने (जो definitely workflow में belong करता है) versus default values supply करने की concerns को separate करता है, जो configuration file में अधिक at home हैं।

चलो इसे दो steps में करते हैं।

1.1.1. Configuration file में params block create करें

nextflow.config file में following code changes करो:

nextflow.config
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
docker.enabled = true

/*
* Pipeline पैरामीटर
*/
params {
    input = 'data/greetings.csv'
    batch = 'batch'
    character = 'turkey'
}
nextflow.config
1
docker.enabled = true

Note करो कि हमने simply workflow से configuration file में params block copy नहीं किया। Syntax थोड़ा different है। Workflow file में, वे typed declarations हैं। Configuration में, वे value assignments हैं।

Technically, यह workflow file में अभी भी specified default values को override करने के लिए sufficient है। तुम character को modify कर सकते हो, example के लिए, और workflow run कर सकते हो यह satisfy करने के लिए कि configuration file में set की गई value workflow file में set की गई value को override करती है।

लेकिन configuration को पूरी तरह configuration file में move करने की spirit में, चलो उन values को workflow file से पूरी तरह remove करते हैं।

1.1.2. Workflow file में params block से values remove करें

hello-config.nf workflow file में following code changes करो:

hello-config.nf
 9
10
11
12
13
14
15
16
/*
* Pipeline पैरामीटर
*/
params {
    input: Path
    batch: String
    character: String
}
hello-config.nf
 9
10
11
12
13
14
15
16
/*
* Pipeline पैरामीटर
*/
params {
    input: Path = 'data/greetings.csv'
    batch: String = 'batch'
    character: String = 'turkey'
}

अब workflow file itself इन parameters के लिए कोई default values set नहीं करती।

1.1.3. Pipeline run करें

चलो test करते हैं कि यह correctly काम करता है।

nextflow run hello-config.nf
कमांड आउटपुट 
N E X T F L O W   ~  version 25.10.2

Launching `hello-config.nf` [disturbed_einstein] DSL2 - revision: ede9037d02

executor >  local (8)
[f0/35723c] sayHello (2)       | 3 of 3 ✔
[40/3efd1a] convertToUpper (3) | 3 of 3 ✔
[17/e97d32] collectGreetings   | 1 of 1 ✔
[98/c6b57b] cowpy              | 1 of 1 ✔

यह अभी भी पहले जैसा same output produce करता है।

Final ASCII art output results/hello_config/ directory में है, cowpy-COLLECTED-batch-output.txt name के under, पहले जैसा ही।

फ़ाइल contents
results/hello_config/cowpy-COLLECTED-batch-output.txt
_________
/ HOLà    \
| HELLO   |
\ BONJOUR /
---------
  \                                  ,+*^^*+___+++_
  \                           ,*^^^^              )
    \                       _+*                     ^**+_
    \                    +^       _ _++*+_+++_,         )
              _+^^*+_    (     ,+*^ ^          \+_        )
            {       )  (    ,(    ,_+--+--,      ^)      ^\
            { (\@)    } f   ,(  ,+-^ __*_*_  ^^\_   ^\       )
          {:;-/    (_+*-+^^^^^+*+*<_ _++_)_    )    )      /
          ( /  (    (        ,___    ^*+_+* )   <    <      \
          U _/     )    *--<  ) ^\-----++__)   )    )       )
            (      )  _(^)^^))  )  )\^^^^^))^*+/    /       /
          (      /  (_))_^)) )  )  ))^^^^^))^^^)__/     +^^
        (     ,/    (^))^))  )  ) ))^^^^^^^))^^)       _)
          *+__+*       (_))^)  ) ) ))^^^^^^))^^^^^)____*^
          \             \_)^)_)) ))^^^^^^^^^^))^^^^)
          (_             ^\__^^^^^^^^^^^^))^^^^^^^)
            ^\___            ^\__^^^^^^))^^^^^^^^)\\
                  ^^^^^\uuu/^^\uuu/^^^^\^\^\^\^\^\^\^\
                    ___) >____) >___   ^\_\_\_\_\_\_\)
                    ^^^//\\_^^//\\_^       ^(\_\_\_\)
                      ^^^ ^^ ^^^ ^

Functionally, इस move ने कुछ भी change नहीं किया, लेकिन conceptually यह थोड़ा cleaner है कि default values configuration file में set हों।

1.2. Run-specific configuration file use करें

यह great है, लेकिन sometimes तुम main configuration file के साथ mess किए बिना different default values के साथ कुछ temporary experiments run करना चाहते हो। तुम ऐसा एक subdirectory में new nextflow.config file create करके कर सकते हो जिसे तुम अपने experiments के लिए working directory के रूप में use करोगे।

1.2.1. Blank configuration के साथ working directory create करें

एक new directory create करके उसमें move करो:

mkdir -p tux-run
cd tux-run

फिर, उस directory में blank configuration file create करो:

touch nextflow.config

यह एक empty file produce करता है।

1.2.2. Experimental configuration set up करें

अब new file open करो और जो parameters customize करना चाहते हो वो add करो:

tux-run/nextflow.config
1
2
3
4
5
params {
    input = '../data/greetings.csv'
    batch = 'experiment'
    character = 'tux'
}

Note करो कि input file का path directory structure reflect करना चाहिए।

1.2.3. Pipeline run करें

अब हम अपने new working directory के अंदर से pipeline run कर सकते हैं। Path को accordingly adapt करना sure करो!

nextflow run ../hello-config.nf
कमांड आउटपुट 
N E X T F L O W   ~  version 25.10.2

Launching `../hello-config.nf` [trusting_escher] DSL2 - revision: 356df0818d

executor >  local (8)
[59/b66913] sayHello (2)       [100%] 3 of 3 ✔
[ad/f06364] convertToUpper (3) [100%] 3 of 3 ✔
[10/714895] collectGreetings   [100%] 1 of 1 ✔
[88/3ece98] cowpy              [100%] 1 of 1 ✔

यह tux-run/ के under directories का एक new set create करेगा जिसमें tux-run/work/ और tux-run/results/ शामिल हैं।

इस run में, Nextflow हमारी current directory में nextflow.config को pipeline की root directory में nextflow.config के साथ combine करता है, और thereby default character (turkey) को tux character के साथ override करता है।

Final output file में greetings कहता हुआ tux character होना चाहिए।

फ़ाइल contents
tux-run/results/hello_config/cowpy-COLLECTED-experiment-output.txt
_________
/ HELLO   \
| BONJOUR |
\ HOLà    /
---------
  \
    \
        .--.
      |o_o |
      |:_/ |
      //   \ \
    (|     | )
    /'\_   _/`\
    \___)=(___/

बस इतना ही; अब तुम्हारे पास अपने 'normal' configuration को modify किए बिना experimenting के लिए space है।

चेतावनी

Next section पर move करने से पहले previous directory में वापस change करना sure करो!

cd ..

अब चलो parameter values set करने के एक और useful way को देखते हैं।

1.3. Parameter file use करें

Subdirectory approach experimenting के लिए great काम करता है, लेकिन इसमें थोड़ी setup involve होती है और require होता है कि तुम paths accordingly adapt करो। एक simpler approach है जब तुम अपनी pipeline को specific set of values के साथ run करना चाहते हो, या किसी और को minimal effort के साथ ऐसा करने enable करना चाहते हो।

Nextflow हमें YAML या JSON format में parameter file के through parameters specify करने allow करता है, जो alternative sets of default values manage और distribute करना बहुत convenient बनाता है, example के लिए, साथ ही run-specific parameter values।

1.3.1. Example parameter file examine करें

इसे demonstrate करने के लिए, हम current directory में एक example parameter file provide करते हैं, जिसका नाम test-params.yaml है:

test-params.yaml
1
2
3
input: "data/greetings.csv"
batch: "yaml"
character: "stegosaurus"

इस parameter file में प्रत्येक input के लिए एक key-value pair है जिसे हम specify करना चाहते हैं। Note करो कि यदि तुम syntax को configuration file से compare करो तो equal signs (=) के बजाय colons (:) का use है। Config file Groovy में लिखी है, जबकि parameter file YAML में लिखी है।

Info

हम example के रूप में parameter file का JSON version भी provide करते हैं लेकिन हम यहाँ इसके साथ run नहीं करने वाले। उसे अपने आप try करने में free feel करो।

1.3.2. Pipeline run करें

इस parameter file के साथ workflow run करने के लिए, simply base command में -params-file <filename> add करो।

nextflow run hello-config.nf -params-file test-params.yaml
कमांड आउटपुट 
N E X T F L O W   ~  version 25.10.2

Launching `hello-config.nf` [disturbed_sammet] DSL2 - revision: ede9037d02

executor >  local (8)
[f0/35723c] sayHello (2)       | 3 of 3 ✔
[40/3efd1a] convertToUpper (3) | 3 of 3 ✔
[17/e97d32] collectGreetings   | 1 of 1 ✔
[98/c6b57b] cowpy              | 1 of 1 ✔

Final output file में greetings कहता हुआ stegosaurus character होना चाहिए।

फ़ाइल contents
results/hello_config/cowpy-COLLECTED-yaml-output.txt
_________
/ HELLO   \
| HOLà    |
\ BONJOUR /
---------
\                             .       .
\                           / `.   .' "
  \                  .---.  <    > <    >  .---.
  \                 |    \  \ - ~ ~ - /  /    |
        _____          ..-~             ~-..-~
        |     |   \~~~\.'                    `./~~~/
      ---------   \__/                        \__/
      .'  O    \     /               /       \  "
    (_____,    `._.'               |         }  \/~~~/
      `----.          /       }     |        /    \__/
            `-.      |       /      |       /      `. ,~~|
                ~-.__|      /_ - ~ ^|      /- _      `..-'
                    |     /        |     /     ~-.     `-. _  _  _
                    |_____|        |_____|         ~ - . _ _ _ _ _>

Parameter file use करना overkill लग सकता है जब तुम्हारे पास specify करने के लिए only कुछ parameters हों, लेकिन कुछ pipelines दर्जनों parameters expect करती हैं। उन cases में, parameter file use करना हमें massive command lines type किए बिना और workflow script modify किए बिना runtime पर parameter values provide करने allow करेगा।

यह collaborators को parameter sets distribute करना भी easier बनाता है, या publication के लिए supporting information के रूप में, example के लिए। यह तुम्हारे work को दूसरों द्वारा अधिक reproducible बनाता है।

सीख

तुम जानते हो कि workflow inputs manage करने के लिए key configuration options का advantage कैसे लें।

आगे क्या?

सीखो कि where और how तुम्हारे workflow outputs publish होते हैं यह कैसे manage करें।

2. Workflow outputs manage करें

अब तक हम workflow-level output declarations के लिए सभी paths hardcode कर रहे थे, और जैसा हमने note किया जब हमने multiple outputs add करना शुरू किया, इसमें थोड़ी repetition involve हो सकती है।

कुछ common ways देखते हैं जिनसे तुम इसे अधिक flexible बनाने के लिए configure कर सकते हो।

2.1. -output-dir के साथ output directory को customize करें

जब हम control कर रहे होते हैं कि हमारे 'published' output कैसे organized हैं तो हमारे पास दो distinct priorities होती हैं:

  • Top-level output directory
  • इस directory के अंदर files कैसे organized हैं

हम अब तक default top-level directory use कर रहे थे: results। चलो उसे customize करना शुरू करते हैं, -output-dir CLI option use करके।

2.1.1. -output-dir के साथ pipeline run करें

-output-dir option (shorthand: -o) सभी workflow outputs के लिए default output directory (results/) को override करता है। यह root path को control करने का recommended way है जहाँ outputs publish होते हैं।

nextflow run hello-config.nf -output-dir custom-outdir-cli/
कमांड आउटपुट 
N E X T F L O W   ~  version 25.10.2

Launching `hello-config.nf` [prickly_kay] DSL2 - revision: 32ecc4fba2

executor >  local (8)
[9f/332636] sayHello (1)       [100%] 3 of 3 ✔
[03/a55991] convertToUpper (3) [100%] 3 of 3 ✔
[e5/ab7893] collectGreetings   [100%] 1 of 1 ✔
[a8/97338e] cowpy              [100%] 1 of 1 ✔

यह outputs को results/ के बजाय custom-outdir-cli/ में publish करता है:

Directory contents 
custom-outdir-cli/
└── hello_config
    ├── batch-report.txt
    ├── cowpy-COLLECTED-batch-output.txt
    └── intermediates
        ├── Bonjour-output.txt
        ├── COLLECTED-batch-output.txt
        ├── Hello-output.txt
        ├── Holà-output.txt
        ├── UPPER-Bonjour-output.txt
        ├── UPPER-Hello-output.txt
        └── UPPER-Holà-output.txt

Notice करो कि हमारे पास अभी भी output block में path declarations से hello_config subdirectory है। चलो इसे clean up करते हैं।

2.1.2. Output block से hardcoded paths remove करें

hello_config/ prefix earlier chapters में hardcoded था, लेकिन चूंकि हम अब output paths flexibly configure करना सीख रहे हैं, हम इस hardcoding को remove कर सकते हैं। उन outputs के लिए जिन्हें subdirectory की जरूरत नहीं है हम path directive को empty string पर set कर सकते हैं, या इसे पूरी तरह remove कर सकते हैं।

Workflow file में following code changes करो:

hello-config.nf
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
output {
    first_output {
        path 'intermediates'
        mode 'copy'
    }
    uppercased {
        path 'intermediates'
        mode 'copy'
    }
    collected {
        path 'intermediates'
        mode 'copy'
    }
    batch_report {
        path ''
        mode 'copy'
    }
    cowpy_art {
        path ''
        mode 'copy'
    }
}
hello-config.nf
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
output {
    first_output {
        path 'hello_config/intermediates'
        mode 'copy'
    }
    uppercased {
        path 'hello_config/intermediates'
        mode 'copy'
    }
    collected {
        path 'hello_config/intermediates'
        mode 'copy'
    }
    batch_report {
        path 'hello_config'
        mode 'copy'
    }
    cowpy_art {
        path 'hello_config'
        mode 'copy'
    }
}

Pipeline फिर से run करो:

nextflow run hello-config.nf -output-dir custom-outdir-cli-2/

अब outputs बिना hello_config subdirectory के directly custom-outdir-cli-2/ के under publish होते हैं:

Directory contents 
custom-outdir-cli-2/
├── batch-report.txt
├── cowpy-COLLECTED-batch-output.txt
└── intermediates
    ├── Bonjour-output.txt
    ├── COLLECTED-batch-output.txt
    ├── Hello-output.txt
    ├── Holà-output.txt
    ├── UPPER-Bonjour-output.txt
    ├── UPPER-Hello-output.txt
    └── UPPER-Holà-output.txt

सुझाव

-output-dir option where outputs जाते हैं यह control करने के लिए use होता है, जबकि output block में path directive subdirectory structure control करता है।

2.2. Dynamic output paths

CLI के through output directory change करने के अलावा, हम config file में outputDir use करके custom default value भी set कर सकते हैं। यह हमें directory path dynamically set करने allow करता है - सिर्फ static strings use करके नहीं।

2.2.1. Configuration file में outputDir set करें

nextflow.config file में following code add करो:

nextflow.config
 9
10
11
12
13
14
15
16
17
18
19
20
21
/*
* Pipeline पैरामीटर
*/
params {
    input = 'data/greetings.csv'
    batch = 'batch'
    character = 'turkey'
}

/*
* Output सेटिंग्स
*/
outputDir = "custom-outdir-config/${params.batch}"
nextflow.config
 9
10
11
12
13
14
15
16
/*
* Pipeline पैरामीटर
*/
params {
    input = 'data/greetings.csv'
    batch = 'batch'
    character = 'turkey'
}

यह output directory को custom-outdir-config/ plus batch parameter की value as subdirectory पर set करता है। अब तुम --batch parameter set करके output location change कर सकते हो:

nextflow run hello-config.nf --batch my_run

यह outputs को custom-outdir-config/my_run/ में publish करता है।

नोट

-output-dir CLI option outputDir configuration setting पर precedence लेता है। यदि यह set है, तो config option पूरी तरह ignore हो जाएगा।

2.2.2. Batch और process names के साथ subdirectories

हम subdirectory output path declarations को भी dynamically set कर सकते हैं, per-output basis पर।

Example के लिए, हम अपने outputs को process के अनुसार organize कर सकते हैं output path declaration में <process>.name reference करके:

hello-config.nf
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
output {
    first_output {
        path { sayHello.name }
        mode 'copy'
    }
    uppercased {
        path { convertToUpper.name }
        mode 'copy'
    }
    collected {
        path { collectGreetings.name }
        mode 'copy'
    }
    batch_report {
        path { collectGreetings.name }
        mode 'copy'
    }
    cowpy_art {
        path { cowpy.name }
        mode 'copy'
    }
}
hello-config.nf
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
output {
    first_output {
        path 'intermediates'
        mode 'copy'
    }
    uppercased {
        path 'intermediates'
        mode 'copy'
    }
    collected {
        path 'intermediates'
        mode 'copy'
    }
    batch_report {
        path ''
        mode 'copy'
    }
    cowpy_art {
        path ''
        mode 'copy'
    }
}

हम और आगे जा सकते हैं और अधिक complex subdirectory paths compose कर सकते हैं।

ऊपर के edit में हमने intermediates versus final outputs जो top level पर हैं, के बीच distinction erase कर दिया। चलो उसे वापस लाते हैं, और साथ ही files को params.batch subdirectory में भी रखते हैं।

सुझाव

Output block path में params.batch include करना, outputDir config के बजाय, का मतलब है कि यह CLI पर -output-dir से overwrite नहीं होगा।

पहले, config file update करो outputDir से ${params.batch} remove करने के लिए (चूंकि हम इसे path declarations में move कर रहे हैं):

nextflow.config
12
13
14
15
/*
* Output सेटिंग्स
*/
outputDir = "custom-outdir-config/"
nextflow.config
12
13
14
15
/*
* Output सेटिंग्स
*/
outputDir = "custom-outdir-config/${params.batch}"

फिर, workflow file में following changes करो:

hello-config.nf
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
output {
    first_output {
        path { "${params.batch}/intermediates/${sayHello.name}" }
        mode 'copy'
    }
    uppercased {
        path { "${params.batch}/intermediates/${convertToUpper.name}" }
        mode 'copy'
    }
    collected {
        path { "${params.batch}/intermediates/${collectGreetings.name}" }
        mode 'copy'
    }
    batch_report {
        path { "${params.batch}/${collectGreetings.name}" }
        mode 'copy'
    }
    cowpy_art {
        path { "${params.batch}/${cowpy.name}" }
        mode 'copy'
    }
}
hello-config.nf
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
output {
    first_output {
        path { sayHello.name }
        mode 'copy'
    }
    uppercased {
        path { convertToUpper.name }
        mode 'copy'
    }
    collected {
        path { collectGreetings.name }
        mode 'copy'
    }
    batch_report {
        path { collectGreetings.name }
        mode 'copy'
    }
    cowpy_art {
        path { cowpy.name }
        mode 'copy'
    }
}

2.2.3. Pipeline run करें

चलो देखते हैं कि यह practice में कैसे काम करता है, command line से दोनों -output-dir (या short के लिए -o) को custom-outdir-config-2 पर और batch name को rep2 पर set करते हुए:

nextflow run hello-config.nf -output-dir custom-outdir-config-2 --batch rep2
कमांड आउटपुट 
N E X T F L O W   ~  version 25.10.2

Launching `hello-config.nf` [mad_curry] DSL2 - revision: 668a98ccb9

executor >  local (8)
[9e/6095e0] sayHello (1)       [100%] 3 of 3 ✔
[05/454d52] convertToUpper (3) [100%] 3 of 3 ✔
[ed/e3ddfb] collectGreetings   [100%] 1 of 1 ✔
[39/5e063a] cowpy              [100%] 1 of 1 ✔

यह outputs को custom-outdir-config-2/rep2/ में publish करता है, specified base path और batch name subdirectory और process द्वारा grouped results के साथ:

Directory contents 
custom-outdir-config-2
└── rep2
    ├── collectGreetings
    │   └── rep2-report.txt
    ├── cowpy
    │   └── cowpy-COLLECTED-rep2-output.txt
    └── intermediates
        ├── collectGreetings
        │   └── COLLECTED-rep2-output.txt
        ├── convertToUpper
        │   ├── UPPER-Bonjour-output.txt
        │   ├── UPPER-Hello-output.txt
        │   └── UPPER-Holà-output.txt
        └── sayHello
            ├── Bonjour-output.txt
            ├── Hello-output.txt
            └── Holà-output.txt

2.3. Workflow level पर publish mode set करें

Finally, repetitive code की amount reduce करने की spirit में, हम per-output mode declarations को configuration में single line से replace कर सकते हैं।

2.3.1. Configuration file में workflow.output.mode add करें

nextflow.config file में following code add करो:

nextflow.config
12
13
14
15
16
/*
* Output सेटिंग्स
*/
outputDir = "custom-outdir-config/"
workflow.output.mode = 'copy'
nextflow.config
12
13
14
15
/*
* Output सेटिंग्स
*/
outputDir = "custom-outdir-config/"

Configuration file में workflow.output.mode set करना workflow file में set किए गए को override करने के लिए sufficient है, लेकिन चलो unnecessary code को anyway remove करते हैं।

2.3.2. Workflow file से output mode remove करें

Workflow file में following changes करो:

hello-config.nf
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
output {
    first_output {
        path { "${params.batch}/intermediates/${sayHello.name}" }
    }
    uppercased {
        path { "${params.batch}/intermediates/${convertToUpper.name}" }
    }
    collected {
        path { "${params.batch}/intermediates/${collectGreetings.name}" }
    }
    batch_report {
        path { "${params.batch}/${collectGreetings.name}" }
    }
    cowpy_art {
        path { "${params.batch}/${cowpy.name}" }
    }
}
hello-config.nf
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
output {
    first_output {
        path { "${params.batch}/intermediates/${sayHello.name}" }
        mode 'copy'
    }
    uppercased {
        path { "${params.batch}/intermediates/${convertToUpper.name}" }
        mode 'copy'
    }
    collected {
        path { "${params.batch}/intermediates/${collectGreetings.name}" }
        mode 'copy'
    }
    batch_report {
        path { "${params.batch}/${collectGreetings.name}" }
        mode 'copy'
    }
    cowpy_art {
        path { "${params.batch}/${cowpy.name}" }
        mode 'copy'
    }
}

यह अधिक concise है, है ना?

2.3.3. Pipeline run करें

चलो test करते हैं कि यह correctly काम करता है:

nextflow run hello-config.nf -output-dir config-output-mode
कमांड आउटपुट 
N E X T F L O W   ~  version 25.10.2

Launching `hello-config.nf` [small_stone] DSL2 - revision: 024d6361b5

executor >  local (8)
[e8/a0e93e] sayHello (1)       [100%] 3 of 3 ✔
[14/176c9d] convertToUpper (3) [100%] 3 of 3 ✔
[23/d667ca] collectGreetings   [100%] 1 of 1 ✔
[e6/1dc80e] cowpy              [100%] 1 of 1 ✔

यह outputs को config-output-mode/ में publish करता है, और वे सभी अभी भी proper copies हैं, symlinks नहीं।

Directory contents 
config-output-mode
└── batch
    ├── collectGreetings
    │   └── batch-report.txt
    ├── cowpy
    │   └── cowpy-COLLECTED-batch-output.txt
    └── intermediates
        ├── collectGreetings
        │   └── COLLECTED-batch-output.txt
        ├── convertToUpper
        │   ├── UPPER-Bonjour-output.txt
        │   ├── UPPER-Hello-output.txt
        │   └── UPPER-Holà-output.txt
        └── sayHello
            ├── Bonjour-output.txt
            ├── Hello-output.txt
            └── Holà-output.txt

Main reason जिससे तुम अभी भी per-output way mode set करना चाह सकते हो वह है यदि तुम same workflow के अंदर mix और match करना चाहते हो, i.e. कुछ outputs copied हों और कुछ symlinked हों।

ऐसे बहुत सारे अन्य options हैं जिन्हें तुम इस way में customize कर सकते हो, लेकिन hopefully यह तुम्हें options की range और अपनी preferences suit करने के लिए उन्हें effectively कैसे utilize करें इसकी sense देता है।

सीख

तुम जानते हो कि directories का naming और structure जहाँ तुम्हारे outputs publish होते हैं, साथ ही workflow output publishing mode कैसे control करें।

आगे क्या?

सीखो कि अपने workflow configuration को अपने compute environment में कैसे adapt करें, software packaging technology से शुरू करके।

3. Software packaging technology select करें

अब तक हम configuration elements देख रहे थे जो control करते हैं कि inputs कैसे जाते हैं और where outputs से आते हैं। अब specifically अपने workflow configuration को अपने compute environment में adapt करने पर focus करने का time है।

उस path पर पहला step है यह specify करना कि software packages जो प्रत्येक step में run होंगे वे कहाँ से आएंगे। क्या वे पहले से local compute environment में installed हैं? क्या हमें images retrieve करनी और उन्हें container system के through run करना है? या हमें Conda packages retrieve करने और local Conda environment build करना है?

इस training course के बहुत पहले part में (Parts 1-4) हमने अपने workflow में बस locally installed software use किया। फिर Part 5 में, हमने Docker containers और nextflow.config file introduce की, जिसे हमने Docker containers का use enable करने के लिए use किया।

अब देखते हैं कि हम nextflow.config file के through एक alternative software packaging option कैसे configure कर सकते हैं।

3.1. Config file में Docker disable और Conda enable करें

मान लो हम एक HPC cluster पर काम कर रहे हैं और admin security reasons के लिए Docker का use allow नहीं करता। Fortunately हमारे लिए, Nextflow कई अन्य container technologies support करता है जिसमें Singularity (जो HPC पर अधिक widely use होती है) शामिल है, और software package managers जैसे Conda।

हम अपनी configuration file को Docker के बजाय Conda use करने के लिए change कर सकते हैं। ऐसा करने के लिए, चलो docker.enabled की value को false पर switch करते हैं, और Conda के use को enable करने वाला directive add करते हैं:

nextflow.config
1
2
docker.enabled = false
conda.enabled = true
nextflow.config
1
docker.enabled = true

यह Nextflow को उन processes के लिए Conda environments create और utilize करने allow करेगा जिनके पास Conda packages specified हैं। जिसका मतलब है कि हमें अब अपने cowpy process में उनमें से एक add करना होगा!

3.2. Process definition में Conda package specify करें

हम पहले से ही cowpy tool contain करने वाले Conda package के लिए URI retrieve कर चुके हैं: conda-forge::cowpy==1.1.5

अब हम conda directive का use करके URI को cowpy process definition में add करते हैं:

modules/cowpy.nf
4
5
6
7
8
9
process cowpy {

    container 'community.wave.seqera.io/library/cowpy:1.1.5--3db457ae1977a273'
    conda 'conda-forge::cowpy==1.1.5'

    input:
modules/cowpy.nf
4
5
6
7
8
process cowpy {

    container 'community.wave.seqera.io/library/cowpy:1.1.5--3db457ae1977a273'

    input:

Clear करने के लिए, हम docker directive replace नहीं कर रहे, हम एक alternative option add कर रहे हैं।

सुझाव

Given conda package के लिए URI पाने के कुछ different ways हैं। हम Seqera Containers search query use करने recommend करते हैं, जो तुम्हें एक URI देगी जिसे तुम copy और paste कर सकते हो, भले ही तुम इससे container create करने की planning नहीं कर रहे हो।

3.3. Workflow run करें verify करने के लिए कि यह Conda use कर सकता है

चलो इसे try करते हैं।

nextflow run hello-config.nf --batch conda
कमांड आउटपुट
Output
N E X T F L O W   ~  version 25.10.2

Launching `hello-config.nf` [friendly_lamport] DSL2 - revision: 024d6361b5

executor >  local (8)
[e8/91c116] sayHello (2)       [100%] 3 of 3 ✔
[fe/6a70ce] convertToUpper (3) [100%] 3 of 3 ✔
[99/7cc493] collectGreetings   [100%] 1 of 1 ✔
[3c/09fb59] cowpy              [100%] 1 of 1 ✔

यह बिना issue के काम करना चाहिए और पहले जैसे same outputs custom-outdir-config/conda के under produce करना चाहिए।

Behind the scenes, Nextflow ने Conda packages retrieve किए और environment create किया, जो normally थोड़ा काम लेता है; तो यह nice है कि हमें खुद कुछ भी नहीं करना पड़ा!

नोट

यह quickly run होता है क्योंकि cowpy package quite small है, लेकिन यदि तुम large packages के साथ काम कर रहे हो, तो यह पहली बार usual से थोड़ा longer लग सकता है, और तुम console output को एक या दो minute के लिए 'stuck' देख सकते हो completing से पहले। यह normal है और extra work के कारण है जो Nextflow पहली बार नया package use करते समय करता है।

हमारे standpoint से, ऐसा लगता है कि यह बिलकुल Docker के साथ running जैसा ही काम करता है, भले ही backend पर mechanics थोड़े different हैं।

इसका मतलब है कि हम Conda environments के साथ run करने के लिए सब set हैं यदि जरूरत हो।

Docker और Conda mix और match करना

चूंकि ये directives per process assign किए जाते हैं, 'mix और match' करना possible है, i.e. अपने workflow में कुछ processes को Docker के साथ और अन्य को Conda के साथ run करने के लिए configure करना, example के लिए, यदि तुम जो compute infrastructure use कर रहे हो वह दोनों support करता है। उस case में, तुम अपनी configuration file में Docker और Conda दोनों enable करोगे। यदि किसी given process के लिए दोनों available हैं, Nextflow containers को prioritize करेगा।

और जैसा पहले noted है, Nextflow कई अन्य software packaging और container technologies support करता है, तो तुम सिर्फ उन दो तक limited नहीं हो।

सीख

तुम जानते हो कि प्रत्येक process को कौन सा software package use करना चाहिए यह कैसे configure करें, और technologies के बीच switch कैसे करें।

आगे क्या?

सीखो कि Nextflow द्वारा actually work करने के लिए use किए जाने वाले execution platform को कैसे change करें।

4. Execution platform select करें

अब तक, हम अपनी pipeline को local executor के साथ run कर रहे थे। यह प्रत्येक task को उस machine पर execute करता है जिस पर Nextflow run हो रहा है। जब Nextflow begin होता है, तो यह available CPUs और memory को देखता है। यदि run होने के लिए ready tasks के resources available resources को exceed करते हैं, Nextflow last tasks को execution से hold back करेगा जब तक कि earlier tasks में से एक या अधिक finish नहीं हो जाते, necessary resources को free करते हुए।

Local executor convenient और efficient है, लेकिन यह उस single machine तक limited है। बहुत large workloads के लिए, तुम discover कर सकते हो कि तुम्हारी local machine bottleneck है, या तो क्योंकि तुम्हारे पास एक single task है जिसे available से अधिक resources require होते हैं, या क्योंकि तुम्हारे पास इतने tasks हैं कि single machine के उन्हें run करने की waiting बहुत long लगेगी।

Nextflow कई different executors support करता है, जिसमें HPC schedulers (Slurm, LSF, SGE, PBS, Moab, OAR, Bridge, HTCondor और अन्य) साथ ही cloud execution backends (AWS Batch, Google Cloud Batch, Azure Batch, Kubernetes और अधिक) शामिल हैं।

4.1. Different backend target करना

Executor की choice एक process directive द्वारा set होती है जिसे executor कहते हैं। By default यह local पर set है, तो following configuration implied है:

Built-in configuration
process {
    executor = 'local'
}

Different backend target करने के लिए executor set करने के लिए, तुम simply वह executor specify करोगे जो तुम चाहते हो similar syntax use करके (सभी options के लिए executor documentation देखें)।

nextflow.config
process {
    executor = 'slurm'
}

चेतावनी

हम actually training environment में इसे test नहीं कर सकते क्योंकि यह HPC से connect करने के लिए set up नहीं है।

4.2. Execution parameters के लिए backend-specific syntax deal करना

Most high-performance computing platforms allow (और sometimes require) करते हैं कि तुम certain parameters specify करो जैसे resource allocation requests और limitations (e.g. number of CPUs और memory) और use करने के लिए job queue का name।

Unfortunately, इनमें से प्रत्येक system different technologies, syntaxes और configurations use करता है यह define करने के लिए कि job कैसे define और relevant scheduler को submit किया जाना चाहिए।

उदाहरण

Example के लिए, same job जिसे 8 CPUs और 4GB RAM require होता है "my-science-work" queue पर execute होने के लिए backend के depending following different ways में express किया जाना चाहिए।

SLURM के लिए Config / sbatch use करके submit करें
#SBATCH -o /path/to/my/task/directory/my-task-1.log
#SBATCH --no-requeue
#SBATCH -c 8
#SBATCH --mem 4096M
#SBATCH -p my-science-work
PBS के लिए Config / qsub use करके submit करें
#PBS -o /path/to/my/task/directory/my-task-1.log
#PBS -j oe
#PBS -q my-science-work
#PBS -l nodes=1:ppn=5
#PBS -l mem=4gb
SGE के लिए Config / qsub use करके submit करें
#$ -o /path/to/my/task/directory/my-task-1.log
#$ -j y
#$ -terse
#$ -notify
#$ -q my-science-work
#$ -l slots=5
#$ -l h_rss=4096M,mem_free=4096M

Fortunately, Nextflow यह सब simplify करता है। यह एक standardized syntax provide करता है ताकि तुम relevant properties जैसे cpus, memory और queue (अन्य properties के लिए process directives देखें) सिर्फ एक बार specify कर सको। फिर, runtime पर, Nextflow उन settings को executor setting के based पर appropriate backend-specific scripts generate करने के लिए use करेगा।

हम next section में उस standardized syntax को cover करेंगे।

सीख

अब तुम जानते हो कि different kinds of computing infrastructure use करने के लिए executor कैसे change करें।

आगे क्या?

सीखो कि Nextflow में resource allocations और limitations कैसे evaluate और express करें।

5. Compute resource allocations control करें

Most high-performance computing platforms allow (और sometimes require) करते हैं कि तुम certain resource allocation parameters specify करो जैसे number of CPUs और memory।

By default, Nextflow प्रत्येक process के लिए single CPU और 2GB memory use करेगा। Corresponding process directives को cpus और memory कहा जाता है, तो following configuration implied है:

Built-in configuration
1
2
3
4
process {
    cpus = 1
    memory = 2.GB
}

तुम इन values को modify कर सकते हो, either सभी processes के लिए या specific named processes के लिए, अपनी configuration file में additional process directives use करके। Nextflow उन्हें chosen executor के लिए appropriate instructions में translate करेगा।

लेकिन तुम कैसे जानते हो कि कौन सी values use करनी हैं?

5.1. Resource utilization report generate करने के लिए workflow run करें

यदि तुम up front नहीं जानते कि तुम्हारे processes को कितनी CPU और memory की likely need होगी, तुम कुछ resource profiling कर सकते हो, मतलब तुम कुछ default allocations के साथ workflow run करते हो, record करते हो कि प्रत्येक process ने कितना use किया, और वहाँ से, base allocations को कैसे adjust करें यह estimate करते हो।

Conveniently, Nextflow में इसके लिए built-in tools included हैं, और request पर तुम्हारे लिए report happily generate करेगा।

ऐसा करने के लिए, अपनी command line में -with-report <filename>.html add करो।

nextflow run hello-config.nf -with-report report-config-1.html

Report एक html file है, जिसे तुम download करके अपने browser में open कर सकते हो। तुम file explorer में बाईं ओर इस पर right click भी कर सकते हो और training environment में इसे view करने के लिए Show preview पर click कर सकते हो।

Report को देखने के लिए कुछ minutes लो और identify करो कि resources adjust करने के लिए कुछ opportunities हैं या नहीं। Tabs पर click करना sure करो जो utilization results को allocated की गई percentage के रूप में show करते हैं।

सभी available features पर documentation के लिए Reports देखें।

5.2. सभी processes के लिए resource allocations set करें

Profiling show करती है कि हमारी training workflow में processes बहुत lightweight हैं, तो default memory allocation को 1GB per process तक reduce करते हैं।

अपनी nextflow.config file में following add करो, pipeline parameters section से पहले:

nextflow.config
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
docker.enabled = false
conda.enabled = true

/*
* Process सेटिंग्स
*/
process {
    memory = 1.GB
}

/*
* Pipeline पैरामीटर
*/
params {
    input = 'data/greetings.csv'
    batch = 'batch'
    character = 'turkey'
}
nextflow.config
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
docker.enabled = false
conda.enabled = true

/*
* Pipeline पैरामीटर
*/
params {
    input = 'data/greetings.csv'
    batch = 'batch'
    character = 'turkey'
}

यह हम जो compute consume करते हैं उसकी amount reduce करने में help करेगा।

5.3. Specific process के लिए resource allocations set करें

साथ ही, हम pretend करेंगे कि cowpy process को दूसरों से अधिक resources require होती हैं, बस demonstrate करने के लिए कि individual process के लिए allocations कैसे adjust करें।

nextflow.config
 4
 5
 6
 7
 8
 9
10
11
12
13
/*
* Process सेटिंग्स
*/
process {
    memory = 1.GB
    withName: 'cowpy' {
        memory = 2.GB
        cpus = 2
    }
}
nextflow.config
4
5
6
7
8
9
/*
* Process सेटिंग्स
*/
process {
    memory = 1.GB
}

इस configuration के साथ, सभी processes 1GB memory और single CPU (implied default) request करेंगे, except cowpy process, जो 2GB और 2 CPUs request करेगा।

सुझाव

यदि तुम्हारे पास few CPUs वाली machine है और तुम per process high number allocate करते हो, तुम process calls को एक दूसरे के पीछे queued होते हुए देख सकते हो। यह इसलिए है क्योंकि Nextflow ensure करता है कि हम available से अधिक CPUs request नहीं करते।

5.4. Updated configuration के साथ workflow run करें

चलो इसे try करते हैं, profiling report के लिए different filename supply करते हुए ताकि हम configuration changes से पहले और बाद performance compare कर सकें।

nextflow run hello-config.nf -with-report report-config-2.html

तुम probably कोई real difference notice नहीं करोगे चूंकि यह इतना small workload है, लेकिन यह approach है जो तुम real-world workflow की performance और resource requirements analyze करने के लिए use करोगे।

यह बहुत useful है जब तुम्हारे processes की different resource requirements हों। यह तुम्हें actual data के based पर प्रत्येक process के लिए set up किए गए resource allocations को right-size करने empower करता है, guesswork नहीं।

सुझाव

यह सिर्फ एक tiny taster है कि तुम resources के अपने use को optimize करने के लिए क्या कर सकते हो। Nextflow itself में कुछ really neat dynamic retry logic built in है resource limitations के कारण fail होने वाले jobs को retry करने के लिए। Additionally, Seqera Platform AI-driven tooling offer करता है तुम्हारे resource allocations को automatically optimize करने के लिए भी।

5.5. Resource limits add करें

Depending on तुम कौन सा computing executor और compute infrastructure use कर रहे हो, कुछ constraints हो सकते हैं कि तुम क्या allocate कर सकते हो (या must)। Example के लिए, तुम्हारा cluster require कर सकता है कि तुम certain limits के अंदर रहो।

तुम resourceLimits directive use कर सकते हो relevant limitations set करने के लिए। Syntax ऐसा दिखता है जब यह process block में अकेला हो:

Syntax example
process {
    resourceLimits = [
        memory: 750.GB,
        cpus: 200,
        time: 30.d
    ]
}

Nextflow इन values को उस executor के depending appropriate instructions में translate करेगा जो तुमने specify किया।

हम इसे run नहीं करने वाले, चूंकि training environment में हमारे पास relevant infrastructure तक access नहीं है। हालाँकि, यदि तुम इन limits से exceed होने वाले resource allocations के साथ workflow run करने की try करो, फिर .command.run script file में sbatch command देखो, तुम देखोगे कि requests जो actually executor को भेजे जाते हैं resourceLimits द्वारा specified values पर capped हैं।

Institutional reference configurations

nf-core project ने दुनिया भर के various institutions द्वारा shared collection of configuration files compile की है, wide range of HPC और cloud executors को cover करते हुए।

वे shared configs valuable हैं both उन लोगों के लिए जो वहाँ काम करते हैं और therefore अपनी institution की configuration को out of the box just utilize कर सकते हैं, और एक model के रूप में उन लोगों के लिए जो अपने खुद के infrastructure के लिए configuration develop करना देख रहे हैं।

सीख

तुम जानते हो कि resource utilization assess करने के लिए profiling report कैसे generate करें और सभी processes के लिए और/या individual processes के लिए resource allocations कैसे modify करें, साथ ही HPC पर running के लिए resource limitations set करें।

आगे क्या?

सीखो कि preset configuration profiles कैसे set up करें और runtime पर उनके बीच switch करें।

6. Preset configurations के बीच switch करने के लिए profiles use करें

हमने तुम्हें कई ways दिखाए हैं जिनसे तुम अपनी pipeline configuration customize कर सकते हो depending on तुम किस project पर काम कर रहे हो या तुम कौन सा compute environment use कर रहे हो।

तुम alternative settings के बीच switch करना चाहते हो depending on तुम कौन सी computing infrastructure use कर रहे हो। Example के लिए, तुम अपने laptop पर locally develop और small-scale tests run करना चाहते हो, फिर HPC या cloud पर full-scale workloads run करना चाहते हो।

Nextflow तुम्हें कितनी भी profiles set up करने देता है जो different configurations describe करती हैं, जिन्हें तुम फिर runtime पर command-line argument use करके select कर सकते हो, बजाय configuration file itself modify करने के।

6.1. Local development और HPC पर execution के बीच switch करने के लिए profiles create करें

दो alternative profiles set up करते हैं; एक regular computer पर small scale loads run करने के लिए, जहाँ हम Docker containers use करेंगे, और एक Slurm scheduler के साथ university HPC पर running के लिए, जहाँ हम Conda packages use करेंगे।

6.1.1. Profiles set up करें

अपनी nextflow.config file में following add करो, pipeline parameters section के बाद लेकिन output settings से पहले:

nextflow.config
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
/*
* Pipeline पैरामीटर
*/
params {
    input = 'data/greetings.csv'
    batch = 'batch'
    character = 'turkey'
}

/*
* Profiles
*/
profiles {
    my_laptop {
        process.executor = 'local'
        docker.enabled = true
    }
    univ_hpc {
        process.executor = 'slurm'
        conda.enabled = true
        process.resourceLimits = [
            memory: 750.GB,
            cpus: 200,
            time: 30.d
        ]
    }
}

/*
* Output सेटिंग्स
*/
outputDir = "custom-outdir-config/"
workflow.output.mode = 'copy'
nextflow.config
15
16
17
18
19
20
21
22
23
24
25
26
27
28
/*
* Pipeline पैरामीटर
*/
params {
    input = 'data/greetings.csv'
    batch = 'batch'
    character = 'turkey'
}

/*
* Output सेटिंग्स
*/
outputDir = "custom-outdir-config/"
workflow.output.mode = 'copy'

तुम देखते हो कि university HPC के लिए, हम resource limitations भी specify कर रहे हैं।

6.1.2. Profile के साथ workflow run करें

अपनी Nextflow command line में profile specify करने के लिए, हम -profile argument use करते हैं।

my_laptop configuration के साथ workflow run करने की try करते हैं।

nextflow run hello-config.nf -profile my_laptop
कमांड आउटपुट 
N E X T F L O W   ~  version 25.10.2

Launching `hello-config.nf` [hungry_sanger] DSL2 - revision: 024d6361b5

executor >  local (8)
[b0/fb2ec9] sayHello (3)       [100%] 3 of 3 ✔
[4a/e039f0] convertToUpper (3) [100%] 3 of 3 ✔
[6f/408fa9] collectGreetings   [100%] 1 of 1 ✔
[f1/fd6520] cowpy              [100%] 1 of 1 ✔

जैसा तुम देख सकते हो, यह हमें runtime पर configurations के बीच बहुत conveniently toggle करने allow करता है।

चेतावनी

univ_hpc profile training environment में properly run नहीं होगी चूंकि हमारे पास Slurm scheduler तक access नहीं है।

यदि future में हमें configuration के अन्य elements मिलते हैं जो हमेशा इनके साथ co-occurring हैं, हम simply उन्हें corresponding profile(s) में add कर सकते हैं। हम additional profiles भी create कर सकते हैं यदि configuration के अन्य elements हैं जिन्हें हम together group करना चाहते हैं।

6.2. Test parameters की profile create करें

Profiles सिर्फ infrastructure configuration के लिए नहीं हैं। हम उन्हें workflow parameters के लिए default values set करने के लिए भी use कर सकते हैं, ताकि दूसरों के लिए workflow को try out करना easier हो बिना appropriate input values खुद gather किए। तुम इसे parameter file use करने का एक alternative consider कर सकते हो।

6.2.1. Profile set up करें

इस context में default values express करने के लिए syntax ऐसा दिखता है, एक profile के लिए जिसे हम test name देते हैं:

Syntax example
    test {
        params.<parameter1>
        params.<parameter2>
        ...
    }

यदि हम अपने workflow के लिए test profile add करें, तो profiles block बन जाता है:

nextflow.config
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
/*
* Profiles
*/
profiles {
    my_laptop {
        process.executor = 'local'
        docker.enabled = true
    }
    univ_hpc {
        process.executor = 'slurm'
        conda.enabled = true
        process.resourceLimits = [
            memory: 750.GB,
            cpus: 200,
            time: 30.d
        ]
    }
    test {
        params.input = 'data/greetings.csv'
        params.batch = 'test'
        params.character = 'dragonandcow'
    }
}

बिलकुल technical configuration profiles की तरह, तुम multiple different profiles set up कर सकते हो जो किसी भी arbitrary name के under parameters specify करते हैं जो तुम्हें पसंद हो।

6.2.2. Test profile के साथ workflow locally run करें

Conveniently, profiles mutually exclusive नहीं हैं, तो हम following syntax -profile <profile1>,<profile2> use करके अपनी command line में multiple profiles specify कर सकते हैं (किसी भी number of profiles के लिए)।

यदि तुम ऐसी profiles combine करते हो जो same elements of configuration के लिए values set करती हैं और same configuration file में described हैं, Nextflow conflict को resolve करेगा whichever value use करके जो उसने last में read किया (i.e. जो भी file में later आता है)। यदि conflicting settings different configuration sources में set हैं, default order of precedence apply होता है।

अपने previous command में test profile add करने की try करते हैं:

nextflow run hello-config.nf -profile my_laptop,test
कमांड आउटपुट 
N E X T F L O W   ~  version 25.10.2

Launching `hello-config.nf` [modest_becquerel] DSL2 - revision: 024d6361b5

executor >  local (8)
[4c/fe2580] sayHello (1)       [100%] 3 of 3 ✔
[fd/7d9017] convertToUpper (3) [100%] 3 of 3 ✔
[13/1523bd] collectGreetings   [100%] 1 of 1 ✔
[06/a1ee14] cowpy              [100%] 1 of 1 ✔

यह Docker use करेगा जहाँ possible हो और custom-outdir-config/test के under outputs produce करेगा, और इस बार character comedic duo dragonandcow है।

फ़ाइल contents
custom-outdir-config/test/cowpy/cowpy-COLLECTED-test-output.txt
 _________
/ HOLà    \
| HELLO   |
\ BONJOUR /
---------
            \                    ^    /^
              \                  / \  // \
              \   |\___/|      /   \//  .\
                \  /O  O  \__  /    //  | \ \           *----*
                  /     /  \/_/    //   |  \  \          \   |
                  \@___\@`    \/_   //    |   \   \         \/\ \
                0/0/|       \/_ //     |    \    \         \ \
            0/0/0/0/|        \///      |     \     \       | |
          0/0/0/0/0/_|_ /   (  //       |      \     _\     |  /
      0/0/0/0/0/0/`/,_ _ _/  ) ; -.    |    _ _\.-~       /   /
                  ,-}        _      *-.|.-~-.           .~    ~
  \     \__/        `/\      /                 ~-. _ .-~      /
  \____(oo)           *.   }            {                   /
  (    (--)          .----~-.\        \-`                 .~
  //__\\  \__ Ack!   ///.----..<        \             _ -~
  //    \\               ///-._ _ _ _ _ _ _{^ - - - - ~

इसका मतलब है कि जब तक हम workflow code के साथ कोई test data files distribute करते हैं, कोई भी quickly workflow को try out कर सकता है बिना अपने inputs command line या parameter file के through supply किए।

सुझाव

हम larger files के लिए जो externally stored हैं URLs point कर सकते हैं। Nextflow उन्हें automatically download करेगा जब तक open connection है।

अधिक details के लिए, Side Quest Working with Files देखें

6.3. Resolved configuration देखने के लिए nextflow config use करें

जैसा ऊपर noted है, sometimes same parameter profiles में different values पर set हो सकता है जिन्हें तुम combine करना चाहते हो। और more generally, कई places हैं जहाँ configuration के elements stored हो सकते हैं, और sometimes same properties different places में different values पर set हो सकती हैं।

Nextflow किसी भी conflicts को resolve करने के लिए set order of precedence apply करता है, लेकिन वह खुद determine करना tricky हो सकता है। और भले ही कुछ भी conflicting न हो, यह tedious हो सकता है सभी possible places को look up करना जहाँ चीज़ें configured हो सकती हैं।

Fortunately, Nextflow में एक convenient utility tool included है जिसे config कहते हैं जो तुम्हारे लिए वह whole process automate कर सकता है।

config tool तुम्हारी current working directory में सभी contents explore करेगा, किसी भी configuration files को hoover up करेगा, और fully resolved configuration produce करेगा जो Nextflow workflow run करने के लिए use करेगा। यह तुम्हें बिना कुछ launch किए यह find out करने allow करता है कि कौन सी settings use की जाएंगी।

6.3.1. Default configuration resolve करें

यह command run करो configuration resolve करने के लिए जो default द्वारा apply होगी।

nextflow config
कमांड आउटपुट 
params {
  input = 'data/greetings.csv'
  batch = 'batch'
  character = 'turkey'
}

docker {
  enabled = false
}

conda {
  enabled = true
}

process {
  memory = '1 GB'
  withName:cowpy {
      memory = '2 GB'
      cpus = 2
  }
}

outputDir = 'custom-outdir-config/'

workflow {
  output {
      mode = 'copy'
  }
}

यह तुम्हें base configuration show करता है जो तुम्हें मिलती है यदि तुम command line में कुछ extra specify नहीं करते।

6.3.2. Specific settings activated के साथ configuration resolve करें

यदि तुम command-line parameters provide करते हो, e.g. एक या अधिक profiles enable करना या parameter file load करना, command additionally उन्हें account में लेगा।

nextflow config -profile my_laptop,test
कमांड आउटपुट 
params {
  input = 'data/greetings.csv'
  batch = 'test'
  character = 'dragonandcow'
}

docker {
  enabled = true
}

conda {
  enabled = true
}

process {
  memory = '1 GB'
  withName:cowpy {
      memory = '2 GB'
      cpus = 2
  }
  executor = 'local'
}

outputDir = 'custom-outdir-config/'

workflow {
  output {
      mode = 'copy'
  }
}

यह complex projects के लिए especially useful हो जाता है जिनमें configuration की multiple layers involve होती हैं।

सीख

तुम जानते हो कि minimal hassle के साथ runtime पर preset configuration select करने के लिए profiles कैसे use करें। More generally, तुम जानते हो कि अपने workflow executions को different compute platforms suit करने के लिए कैसे configure करें और अपनी analyses की reproducibility enhance करें।

आगे क्या?

Celebrate करो और खुद को एक big pat on the back दो! तुमने अपना बहुत पहला Nextflow developer course complete कर लिया है।

Final course summary पर जाओ review करने के लिए कि तुमने क्या सीखा और पता लगाओ कि आगे क्या आता है।

Quiz

#

उस configuration file का क्या नाम है जो Nextflow automatically load करता है?

#

जब same parameter config file और command line दोनों में set हो तो क्या precedence लेता है?

#

क्या same configuration में Docker और Conda दोनों enabled हो सकते हैं?

#

यदि Docker और Conda दोनों enabled हैं और process के पास दोनों directives हैं, तो कौन prioritized होता है?

#

Nextflow processes के लिए default memory allocation क्या है?

#

Config file में specific process के लिए resource requirements कैसे set करते हो?

#

कौन सा command line option resource utilization report generate करता है?

#

resourceLimits directive क्या करता है?

#

Nextflow में default executor क्या है?

#

Nextflow run करते समय parameter file कैसे specify करते हो?

#

Profiles किसके लिए use की जा सकती हैं? (सभी लागू select करें)

#

Single command में multiple profiles कैसे specify करते हो?