Sandbox FAQ » History » Version 2
Herve Caumont, 2013-06-19 18:05
| 1 | 2 | Herve Caumont | h1. Frequently Asked Questions |
|---|---|---|---|
| 2 | 1 | Herve Caumont | |
| 3 | 2 | Herve Caumont | {{toc}} |
| 4 | 1 | Herve Caumont | |
| 5 | 2 | Herve Caumont | h2. Installation of application and software |
| 6 | 1 | Herve Caumont | |
| 7 | h3. How do I install external libraries (e.g. HDF5)? |
||
| 8 | |||
| 9 | 2 | Herve Caumont | HDF5 libraries and associated binaries (e.g. h5dump) are available via yum: |
| 10 | 1 | Herve Caumont | |
| 11 | <pre> |
||
| 12 | [user@fb ~] sudo yum search hdf |
||
| 13 | </pre> |
||
| 14 | |||
| 15 | This will list all packages related with HDF. |
||
| 16 | We will install the hdf5 libraries and binaries with: |
||
| 17 | |||
| 18 | <pre> |
||
| 19 | 2 | Herve Caumont | [user@sb ~] sudo yum install hdf5.x86_64 |
| 20 | 1 | Herve Caumont | </pre> |
| 21 | |||
| 22 | h3. Several jobs of my workflow use the same software, where is it installed? |
||
| 23 | |||
| 24 | When several jobs use the same software (e.g. NEST toolbox or CDAT) the location to install these packages is: |
||
| 25 | |||
| 26 | <pre> |
||
| 27 | /application/share/<software name> |
||
| 28 | </pre> |
||
| 29 | |||
| 30 | instead of installing it several times under |
||
| 31 | |||
| 32 | <pre> |
||
| 33 | /application/job1/ |
||
| 34 | /application/job2/ |
||
| 35 | </pre> |
||
| 36 | |||
| 37 | 2 | Herve Caumont | h3. Am I a sudoer? |
| 38 | 1 | Herve Caumont | |
| 39 | 2 | Herve Caumont | Yes, you are but with limited power, you can do: |
| 40 | 1 | Herve Caumont | |
| 41 | * yum - yum allows you to install packages on your sandbox |
||
| 42 | |||
| 43 | h2. Parameters and inputs |
||
| 44 | |||
| 45 | h3. How do I manage the inputs to a job? |
||
| 46 | |||
| 47 | There are several ways to pass inputs to a job: |
||
| 48 | |||
| 49 | * Local inputs - local files will use the file:// protocol and are defined in the workflow as follows: |
||
| 50 | |||
| 51 | <pre><code class="xml"> |
||
| 52 | <workflow id="somename"> |
||
| 53 | <workflowVersion>1.0</workflowVersion> |
||
| 54 | <node id="somenodeid"> |
||
| 55 | <job id="ceda-collect"></job> |
||
| 56 | <sources> |
||
| 57 | <source refid="file:urls" >/application/input.urls</source> |
||
| 58 | </sources> |
||
| 59 | </node> |
||
| 60 | </workflow> |
||
| 61 | </code></pre> |
||
| 62 | |||
| 63 | and the file _input.urls_ contains the references to the local files: |
||
| 64 | |||
| 65 | <pre><code class="ruby"> |
||
| 66 | [ user@sb ~] cat /application/input.urls |
||
| 67 | file:///home/user/somefile1 |
||
| 68 | file:///home/user/somefile2 |
||
| 69 | file:///home/user/somefile3 |
||
| 70 | </code></pre> |
||
| 71 | |||
| 72 | Then the job executable can use ciop-copy to copy the files if needed. |
||
| 73 | |||
| 74 | <pre><code class="c"> |
||
| 75 | while read inputfile |
||
| 76 | do |
||
| 77 | echo $inputfile | ciop-copy -o ./ - |
||
| 78 | done |
||
| 79 | </code></pre> |
||
| 80 | |||
| 81 | 2 | Herve Caumont | > Tip: check the [[ciop-copy] CLI reference |
| 82 | |||
| 83 | 1 | Herve Caumont | * Values |
| 84 | |||
| 85 | Passing values to a job follows the same approach as above. |
||
| 86 | |||
| 87 | <pre><code class="xml"> |
||
| 88 | <workflow id="somename"> |
||
| 89 | <workflowVersion>1.0</workflowVersion> |
||
| 90 | <node id="somenodeid"> |
||
| 91 | <job id="ceda-collect"></job> |
||
| 92 | <sources> |
||
| 93 | <source refid="file:urls" >/application/inputparams</source> |
||
| 94 | </sources> |
||
| 95 | </node> |
||
| 96 | </workflow> |
||
| 97 | </code></pre> |
||
| 98 | |||
| 99 | and the file _inputparams_ contains the list of values: |
||
| 100 | |||
| 101 | <pre><code class="ruby"> |
||
| 102 | [ user@sb ~] cat /application/inputparams |
||
| 103 | -10,-10,10,10 |
||
| 104 | 10,10,20,20 |
||
| 105 | </code></pre> |
||
| 106 | |||
| 107 | In the example above, the executable manages the parameters (bounding boxes) with: |
||
| 108 | |||
| 109 | <pre><code class="ruby"> |
||
| 110 | while read bbox |
||
| 111 | do |
||
| 112 | echo "processing bounding box $bbox" |
||
| 113 | done |
||
| 114 | </code></pre> |
||
| 115 | |||
| 116 | 2 | Herve Caumont | * Products available in the sandbox internal catalogue |
| 117 | 1 | Herve Caumont | |
| 118 | 2 | Herve Caumont | During the sandbox definition and creation you may have selected a list of EO products, the references to these products are available in the sandbox internal catalogue. |
| 119 | 1 | Herve Caumont | The workflow is defined as follows: |
| 120 | |||
| 121 | <pre><code class="xml"> |
||
| 122 | <workflow id="testVomir"> |
||
| 123 | <workflowVersion>1.0</workflowVersion> |
||
| 124 | <node id="Vimage"> <!-- workflow node unique id --> |
||
| 125 | <job id="imager"></job> <!-- job defined above --> |
||
| 126 | <sources> |
||
| 127 | <source refid="cas:serie" >ATS_TOA_1P</source> |
||
| 128 | </sources> |
||
| 129 | <parameters> <!-- parameters of the job --> |
||
| 130 | <parameter id="volcano_db"></parameter> |
||
| 131 | </parameters> |
||
| 132 | </node> |
||
| 133 | </code></pre> |
||
| 134 | |||
| 135 | 2 | Herve Caumont | As an example, the job executable would contain the lines below to copy the EO products locally: |
| 136 | 1 | Herve Caumont | |
| 137 | <pre><code class="ruby"> |
||
| 138 | while read product |
||
| 139 | do |
||
| 140 | echo $product | ciop-copy -o ./ - |
||
| 141 | done |
||
| 142 | </code></pre> |
||
| 143 | |||
| 144 | 2 | Herve Caumont | > Tip: check the [[ciop-copy] CLI reference |
| 145 | 1 | Herve Caumont | |
| 146 | 2 | Herve Caumont | h2. Job |
| 147 | |||
| 148 | 1 | Herve Caumont | h3. What environmental variables can I use in my jobs? |
| 149 | |||
| 150 | 2 | Herve Caumont | CIOP provides the environmental variables: |
| 151 | 1 | Herve Caumont | * _CIOP_APPLICATION_PATH is the path to the application.xml files and all other underlying folders. Its value is /application |
| 152 | > Note: do not use its value in the executable scripts, always use $_CIOP_APPLICATION_PATH |
||
| 153 | * _JOB_DIR |
||
| 154 | * TMPDIR is temporary directory for the task. |
||
| 155 | * _JOB_ID contains the job id |
||
| 156 | * _JOB_LOCAL_DIR is the job specific shared scratch space |
||
| 157 | * _TASK_ID is the task id |
||
| 158 | * _TASK_LOCAL_DIR is the task specific scratch space |
||
| 159 | * _TASK_NUM contains the number of tasks |
||
| 160 | * _TASK_INDEX |
||
| 161 | |||
| 162 | The best way to get acquainted to the values of the environmental variables is to have them logged in a job with: |
||
| 163 | |||
| 164 | <pre> |
||
| 165 | ciop-log "DEBUG" "TMPDIR = $TMPDIR" |
||
| 166 | ciop-log "DEBUG" "_JOB_ID = ${_JOB_ID}" |
||
| 167 | ciop-log "DEBUG" "_JOB_LOCAL_DIR = ${_JOB_LOCAL_DIR}" |
||
| 168 | ciop-log "DEBUG" "_TASK_ID = ${_TASK_ID}" |
||
| 169 | ciop-log "DEBUG" "_TASK_LOCAL_DIR = ${_TASK_LOCAL_DIR}" |
||
| 170 | ciop-log "DEBUG" "_TASK_NUM = ${_TASK_NUM}" |
||
| 171 | ciop-log "DEBUG" "_TASK_INDEX = ${_TASK_INDEX}" |
||
| 172 | </pre> |
||
| 173 | |||
| 174 | h3. How do I test a single job of a workflow? |
||
| 175 | |||
| 176 | 2 | Herve Caumont | For that you have to know the nodeid of the job in the workflow. Use the command below to list the nodes of the application workflow: |
| 177 | 1 | Herve Caumont | |
| 178 | 2 | Herve Caumont | <pre> |
| 179 | [user@sb ~] ciop-simjob -n |
||
| 180 | </pre> |
||
| 181 | |||
| 182 | Or check the *application.xml* file and look for the node name |
||
| 183 | |||
| 184 | 1 | Herve Caumont | <pre><code class="xml"> |
| 185 | <workflow id="testVomir"> |
||
| 186 | <workflowVersion>1.0</workflowVersion> |
||
| 187 | <node id="Vimage"> |
||
| 188 | ... |
||
| 189 | </node> |
||
| 190 | </code></pre> |
||
| 191 | |||
| 192 | With that value simply do: |
||
| 193 | |||
| 194 | <pre> |
||
| 195 | [user@sb ~] ciop-simjob -f Vimage |
||
| 196 | </pre> |
||
| 197 | |||
| 198 | 2 | Herve Caumont | > Tip: check the [[ciop-simjob] CLI reference |
| 199 | 1 | Herve Caumont | |
| 200 | 2 | Herve Caumont | h2. Workflow |
| 201 | |||
| 202 | 1 | Herve Caumont | h3. How do I test a workflow? |
| 203 | |||
| 204 | Simply run the command: |
||
| 205 | |||
| 206 | <pre><code class="ruby"> |
||
| 207 | [ user@sb ~] ciop-simwf |
||
| 208 | </code></pre> |
||
| 209 | |||
| 210 | 2 | Herve Caumont | > Tip: check the [[ciop-simwf]] CLI reference |
| 211 | |||
| 212 | 1 | Herve Caumont | h3. How do I access the details of my workflow run? |
| 213 | |||
| 214 | When you run the _ciop-simwf_ you'll see on your terminal window the image below. The link to the details is highlighted. |
||
| 215 | Copy and paste the URL on your browser and navigate through the pages to find details about the workflow execution. |
||
| 216 | |||
| 217 | !workflow_url.png! |
||
| 218 | |||
| 219 | 2 | Herve Caumont | h3. How do I access the results of my workflow run? |
| 220 | 1 | Herve Caumont | |
| 221 | After a successful run of your workflow, your results including logs can be found in the folder: |
||
| 222 | |||
| 223 | <pre> |
||
| 224 | /share/tmp/sandbox/<workflow name> |
||
| 225 | </pre> |
||
| 226 | 2 | Herve Caumont | |
| 227 | You can list the run identifiers with: |
||
| 228 | |||
| 229 | <pre><code class="ruby"> |
||
| 230 | [ user@sb ~] ciop-simwf -l |
||
| 231 | </code></pre> |