| 188 | |
| 189 | == Frequently asked questions == |
| 190 | |
| 191 | It seems that in BOINC, if you have 2 WU with different input but |
| 192 | having the same name (like "environment.dat"), there will be a problem |
| 193 | because it will already be in the folder "download" on your |
| 194 | project. So you would have to rename the file or set manually the file |
| 195 | property (URL...) in WU. Is it the same with RBoinc? Will the file be |
| 196 | overwritten ? |
| 197 | |
| 198 | |
| 199 | That should be handled correctly: file names in download are |
| 200 | unique (in fact, equal to the file's md5), even though the |
| 201 | submitter used the same name for different contents. (It's fairly |
| 202 | common e.g. for 1000 WUs to have in common at least one of the |
| 203 | inputs). |
| 204 | |
| 205 | |
| 206 | |
| 207 | I understood that with RBoinc, user didn't have to worry about |
| 208 | uploading separately files used and that it was automatic. So is it |
| 209 | important to ensure all input files (for different WUs) will have a |
| 210 | different name? |
| 211 | |
| 212 | The scientist can and reuse whatever names and contents he |
| 213 | likes. The only thing that matters is the file content at the |
| 214 | moment of submission. The RBoinc server will generate internal |
| 215 | unique names (which are hidden from the user). |
| 216 | |
| 217 | |
| 218 | How does the manual retrieve operation affect workunits once a job has |
| 219 | been performed ? |
| 220 | |
| 221 | Retrieve will free up space taken on the server by the results of |
| 222 | the completed WUs. Currently running, scheduled, and future WUs |
| 223 | will be otherwise unaffected (e.g., "step1" may depend on "step0" |
| 224 | through the chaining mechanism). |
| 225 | |
| 226 | Note, however, that a "boinc_retrieve -stop ..." command will |
| 227 | stop the chaining machinery, ie. the generation of new WUs. |
| 228 | |
| 229 | |
| 230 | And what about the results if you don't perform a "retrieve"? |
| 231 | |
| 232 | The results are kept on the server until the issuing scientist |
| 233 | retrieves them. (In fact, they may fill up the server if |
| 234 | forgotten.) |
| 235 | |
| 236 | |
| 237 | What is the relationship between RBoinc and the assimilator? |
| 238 | |
| 239 | Let me clarify: |
| 240 | |
| 241 | 1. a client ("volunteer") computes a WU |
| 242 | 2. results are stored in |
| 243 | "workflow_results/GROUPNAME" (something like |
| 244 | name-USER_GROUPNAME-2-10-RND1234-...) |
| 245 | 3. the WU is assimilated: |
| 246 | assimilator executes the '''process''' script in the |
| 247 | workflow_results/GROUPNAME |
| 248 | 4. '''process''' creates a WU |
| 249 | corresponding the next step of the chain (if necessary) |
| 250 | 5. repeat from 1 |
| 251 | |
| 252 | The "retrieve" operation is completely independent of the above |
| 253 | process: a "retrieve" can be requested at any time, and it will |
| 254 | download any results in workflow_results/GROUPNAME |
| 255 | |
| 256 | |
| 257 | |
| 258 | |
| 259 | Will there be a problem if a user send simultaneously 1000 jobs by a |
| 260 | script (as I saw you used temp folders which were deleted at the end |
| 261 | of 1 submission) ? |
| 262 | |
| 263 | It's perfectly fine (quite common indeed). |
| 264 | |
| 265 | |
| 266 | Do you have an idea if your application is directly compatible with |
| 267 | windows ? |
| 268 | |
| 269 | The '''client''' scripts are likely portable with minor changes |
| 270 | (just install a good perl interpreter and the required modules). |
| 271 | |
| 272 | |
| 273 | |
| 274 | Is it possible to use your commands with different BOINC projects ? |
| 275 | |
| 276 | I'd say that a rboinc '''server''' is tied to the corresponding |
| 277 | boinc server (but it can talk to any of its applications). The |
| 278 | rboinc clients can talk to multiple servers using different URLs |
| 279 | (-url option). |
| 280 | |
| 281 | I was thinking of having several Boinc projects to assign easily each |
| 282 | of them to a specific group of users. Should I be installing multiple |
| 283 | servers with their own URLs? |
| 284 | |
| 285 | Yes - that will be the most flexible solution (e.g. you wil be |
| 286 | able to perform maintenance on each of them separately, make |
| 287 | firewall rules, etc). Alternatively, you can create several |
| 288 | applications on the same server, if you prefer. |
| 289 | |
| 290 | |
| 291 | The scientist may request the output at any time. Is it also possible |
| 292 | to retrieve automatically the output in a predefined folder when a job is |
| 293 | performed? |
| 294 | |
| 295 | Scientists may request the outputs of successfully-completed WUs |
| 296 | at any time (even if they are part of a still-ongoing chain of |
| 297 | WUs). Automatic retrieval on the issuing scientist's machine via |
| 298 | cron jobs is convenient. |
| 299 | |
| 300 | |
| 301 | |
| 302 | (Courtesy of BK) |