Changes between Version 14 and Version 15 of RemoteJob

Timestamp:

Feb 3, 2011, 10:58:23 AM (15 years ago)

Author:

tonig

Comment:

Added faq

RemoteJob

@@ -186 +186 @@
 retrieve directory.
 
+
+== Frequently asked questions ==
+
+It seems that in BOINC, if you have 2 WU with different input but
+having the same name (like "environment.dat"), there will be a problem
+because it will already be in the folder "download" on your
+project. So you would have to rename the file or set manually the file
+property (URL...) in WU.  Is it the same with RBoinc? Will the file be
+overwritten ?
+
+
+    That should be handled correctly: file names in download are
+    unique (in fact, equal to the file's md5), even though the
+    submitter used the same name for different contents. (It's fairly
+    common e.g. for 1000 WUs to have in common at least one of the
+    inputs).
+
+
+
+I understood that with RBoinc, user didn't have to worry about
+uploading separately files used and that it was automatic. So is it
+important to ensure all input files (for different WUs) will have a
+different name?
+
+    The scientist can and reuse whatever names and contents he
+    likes. The only thing that matters is the file content at the
+    moment of submission. The RBoinc server will generate internal
+    unique names (which are hidden from the user).
+
+
+How does the manual retrieve operation affect workunits once a job has
+been performed ?
+
+    Retrieve will free up space taken on the server by the results of
+    the completed WUs. Currently running, scheduled, and future WUs
+    will be otherwise unaffected (e.g., "step1" may depend on "step0"
+    through the chaining mechanism).
+
+    Note, however, that a "boinc_retrieve -stop ..."  command will
+    stop the chaining machinery, ie. the generation of new WUs.
+
+
+And what about the results if you don't perform a "retrieve"?  
+
+    The results are kept on the server until the issuing scientist
+    retrieves them. (In fact, they may fill up the server if
+    forgotten.)
+
+
+What is the relationship between RBoinc and the assimilator?
+
+    Let me clarify:
+
+      1. a client ("volunteer") computes a WU 
+      2. results are stored in 
+      "workflow_results/GROUPNAME" (something like
+      name-USER_GROUPNAME-2-10-RND1234-...)  
+      3. the WU is assimilated:
+      assimilator executes the '''process''' script in the
+      workflow_results/GROUPNAME 
+      4. '''process''' creates a WU
+      corresponding the next step of the chain (if necessary)
+      5. repeat from 1
+
+    The "retrieve" operation is completely independent of the above
+    process: a "retrieve" can be requested at any time, and it will
+    download any results in workflow_results/GROUPNAME
+
+
+
+
+Will there be a problem if a user send simultaneously 1000 jobs by a
+script (as I saw you used temp folders which were deleted at the end
+of 1 submission) ?
+
+    It's perfectly fine (quite common indeed).
+
+
+Do you have an idea if your application is directly compatible with
+windows ?
+
+    The '''client''' scripts are likely portable with minor changes
+    (just install a good perl interpreter and the required modules).
+
+
+
+Is it possible to use your commands with different BOINC projects ?
+
+    I'd say that a rboinc '''server''' is tied to the corresponding
+    boinc server (but it can talk to any of its applications).  The
+    rboinc clients can talk to multiple servers using different URLs
+    (-url option).
+
+I was thinking of having several Boinc projects to assign easily each
+of them to a specific group of users.  Should I be installing multiple
+servers with their own URLs?
+
+    Yes - that will be the most flexible solution (e.g. you wil be
+    able to perform maintenance on each of them separately, make
+    firewall rules, etc). Alternatively, you can create several
+    applications on the same server, if you prefer.
+
+
+The scientist may request the output at any time.  Is it also possible
+to retrieve automatically the output in a predefined folder when a job is
+performed?
+
+    Scientists may request the outputs of successfully-completed WUs
+    at any time (even if they are part of a still-ongoing chain of
+    WUs). Automatic retrieval on the issuing scientist's machine via
+    cron jobs is convenient.
+
+
+
+(Courtesy of BK)