Changes between Version 15 and Version 16 of External_Supercomputing_Notes

Timestamp:

Jan 23, 2014, 2:00:42 PM (13 years ago)

Author:

watersc1

Comment:

--

External_Supercomputing_Notes

@@ -192 +192 @@
 srun: error: @HOST@: task 1: Exited with exit code 3
 }}}
+
+== 2014-01-23 ==
+
+After completing some of the most obvious scripts that are necessary to make this work, I've come up with the following processing outline that I think satisfies all of the needed steps.
+
+=== Queuing/database management ===
+
+All processing needs to begin with chipRun entries defined in the standard way.  chiptool -pendingimfile provides the majority of the information needed, so it's best to reuse this framework.  However, after the chipRun entries are defined, they need to be registered into a "supercomputeRun" database entry.  My current assumption is that a chip_id or chipRun.label field will be used in the definebyquery statement.  The supercomputeRun entry will manage the communication with the remote supercompute resources.  This table needs to have the following fields:
+
+ * sc_id: main table index
+ * stage: current stage being processed for this entry
+ * stage_id: reference to the stageRun table
+ * state: in addition to the run/full/cleaned values, this will need values pending, auth, and error (described below).
+ * last_poll: date string indicating last time this entry was remotely polled.
+ * job_id: remote processing job_id.
+ * fault: standard fault code
+ * path_base: local storage location for supercompute file generation.
+ * job_policy: policy state for dealing with partially incomplete runs.
+
+=== Processing order ===
+
+Once the supercomputeRun is inserted (with state = 'new'), the initial prep task will run, doing the following:
+ * Construct list of required files necessary to complete the task on the remote cluster, and their local analogs (if they exist).
+ * Construct the command script that defines the resources needed and will launch the srun command.
+ * Construct the config script needed for srun to parallelize the processing.
+ * Update supercomputeRun to state = 'pending'
+
+With the preparation done, the launch task runs, with the following effects:
+ * Check that the connection to the remote supercomputer is available.  If not, set the database entry to state = 'auth', update the last_poll entry, and quit.
+ * Send list of required files to the remote cluster, and run the validation script on the remote end.  This script will produce a file listing any missing entries.  This file is returned to the local site, and a transfer list is constructed of the files that need to be pushed to the remote site.
+ * Any file pushes that are required are performed, and the command and config scripts are pushed as well.
+ * The command script is inserted into the supercomputing queue and the job_id value is obtained.
+ * The supercomputeRun is set to state = 'run', and the job_id value updated.
+ * A job poll is performed (setting last_poll), and the script either terminates (allowing a future poll to check), or sleeps until the poll determines the job has completed.  A future poll will skip the previous steps and return to this point.
+ * The remote job status completes, and the resulting files are pulled back from the remote site, including any permanent files (log, stats, SMF, etc), as well as a job_summary compiled at the end of the command script.
+ * If the remote job has completed successfully, or if the job_policy is set to "ignore", the local database is updated to reflect that the stageRun has completed successfully, and the state is updated to 'full'.  If the job_policy is not set to ignore (job errors are fatal), the local database is updated with information about the jobs that have completed successfully, but the jobs that have failed are marked as so.  The supercomputeRun is set to have a fault != 0, and the state = 'error'.  This behavior then will require manual intervention to update the database and resolve the failed jobs.
+
+At this point, a master control process will have to step in and launch new supercomputeRun entries for the next step.  Upon adding this, the chip->supercomputeRun operation is likely an operation of this master control program operating on a label basis.
+
+===