Merge pull request #2384 from RosettaCommons/aleaverfay/jd3_multiple_results_per_job
JD3: Jobs produce multiple of JobSummary/JobResult pairs
Imagine that a job produces 1000 poses because it's efficient for it to produce many at once. What then? Should it put all 1000 poses into a single JobResult? When the JobQueen selects Pose 884 to advance to the next round of the protocol, will all 1000 Poses be sent as a single serialized JobResult to the remote node, so it can extract all 1000, and then take the single Pose it cares about?
That seems like a bad idea! JD3's initial design didn't plan for this.
The new system I'm working on here instead has a Job produce a list of outputs allowing the JobDistributor to serialize and store them all separately. Then when result 884 needs to get sent to the remote node as input to the next job, only a single Pose has to be transferred. Also, the other 999 poses can be deallocated.
Job's ```run()``` method now returns a ```CompletedJobResult``` as before, but this previous typedef is now a struct containing a vector1 of JobSummary/JobResult pairs in addition to a JobStatus. If a job produces more than one Pose, each Pose could (should) be put into separate PoseJobResult and entered into a separate entry in the CompletedJobOutput array.
The JobQueen's interface now changes:
* ```note_job_completed(...)``` now informs the JQ of the number of job results produced
* ```completed_job_summary( ... )``` now includes the index of the JobSummary (1..nresults for that job)
* ```completed_job_result( ... )``` similarly includes the index of the JobResult
* ```jobs_that_should_be_output``` now returns a list of Size/Size pairs
* ```job_results_that_should_be_discarded``` also returns a list of Size/Size pairs
The PoseOutputters now handle extra outputs the same way that JD2 handles multiple Pose outputs for a single job -- i.e. the names given to the extra poses written as .pdbs or silent structures append an extra _0001, _0002 after the job_id; e.g. job 4311 run on PDB 1l2y.pdb which produces < 9999 output Poses would write to 1l2y_4311_0001.pdb, 1l2y_4311_0002.pdb, etc.
There's really no reason for the integration test changes I'm seeing on the server, and I'm suspicious that it's just a hiccup related to Frank's merge of PR #2371 which fixed several bugs in symmetric minimization.