Appion

Prior to this feature, the queue has been set by adding extra lines to the job file via the .appion.cfg file located on the processing host. When a job is launched from the web and goes through runJob.py, the .appion.cfg file is loaded and used.

Now we want to be able to select which queue the user would like to run on directly from the web GUI to give the user more flexibility and avoid having to edit job files once created.

To do this, we can now define all the available queues in the config.php file in the myamiweb directory. Each entry in the PROCESSING_HOSTS array can include a queues array which simply lists the names of the available queues. The Cluster class now includes a queues member variable which is used to populate the available queues in clusterParameters form. The Cluster class is also capable of asking the selected host for its list of available queues when the user is logged in, which may be more accurate or up to date than the config file, but may also be more confusing for users if there are queues that should not be used. We can remove that feature if needed. For generic jobs like particle picking, etc., the getSubmitForm() function in processing.inc has been updated to add a select box for queues if there is more than one queue available for the selected host.

For all job types, generic, remote, and refine, a new option --queue is added to the command sent to runJob.py. When runJob.py builds the job file, if --queue=name is defined, the queue will be listed in the file.
An important question for Anchi:
Should your apParellelTasks.py jobs also set the queue??

• update the installation documentation
• update the setup wizard to prompt for processing host queues

These changes will affect every job run in Appion, so if there are bugs, they should be discovered quickly. Keep this in mind if you see anything strange going on with job submission.

When I check in these changes, the new web front end will not be compatible with the old back end or old config.php files or old .appion.cfg files. The web code, processing code and config files must be updated at the same time. Therefore, I will wait to check in these changes for a time when Sargis is available to ensure all installations are updated correctly.

Sargis, will Monday August 4 be a good day for us to do the update??

Turns out the issue with the submit is due to processing files that would submit the form for processing on

if ($_POST)

if ($_POST['process'])

Everything should be functioning when the installations are updated tomorrow morning.

Ready for code review.

Changed the rest of php scripts I could find in tomography part for completeness. These are outdated with protomo II integration in 3.2 and unrelated to the feature here.