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.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2393 from RosettaCommons/everyday847/stepwise_integration_test_pre_fix
Pre-emptive alteration to 'stepwise' silent file tags (just in integration tests)
The 14 integration test changes to stepwise integration tests are EXPECTED; they reflect a nomenclature change so it will be easier to detect REAL changes later.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2387 from RosettaCommons/jadolfbr/code_template_namespaces
Fix Code Template Namespacing
This addresses #2386 - Add full pathing or typedefs to function variables to make the templates independent of final namespace as they should be.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2371 from RosettaCommons/aleaverfay/cart_min_deriv_unit_tests
This checkin fixes two bugs with Cartesian minimization of symmetric poses.
One was related to the recent change of symmetric atom tree minimizer to better support lattice symmetries. This change modified the edge weights on minimization graph, however CartesianMin still needed the old weights. This checkin changes the logic so the weights are modified as needed in SymAtomTree minimize, while keeping the minimization graph as it was before this change.
This checkin also fixes a longstanding bug in symmetric CartesianMinimization when only part of the structure only was allowed to move. In these cases, the domain map was built assuming an asymmetric pose, leading to not all energy edges getting calculated during cartesian minimization. This has been fixed (and @aleaverfay has added an integration test ensuring this works). Thanks Andrew for finding these issues.
Integration changes expected in all tests that minimize with symmetry.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2349 from RosettaCommons/JWLabonte/lipids/database
This merge will add a few more lipid building blocks to the database for (an attempt at) explicit modeling of lipids.
An integration test has also been added that demonstrates loading in an explicit lipid monolayer of 99 2-oleoyl-1-palmitoylphosphatidylcholine units, scoring, and minimizing.
Please note that this integration test demonstrates a framework; it in no way implies any sort of scientific validity to the output structures. There is currently no reliable protocol for explicitly modeling lipid membranes in Rosetta.
All unit tests pass. Several integration tests show new tracer output.
notify author
notify list [rosetta-logs@googlegroups.com]
Merge pull request #2378 from RosettaCommons/everyday847/5prime_cap
Model mRNA in rna_denovo
Rocco Moretti 7 years The farfar_mrna integration test added with this commit looks to be in permanent (magenta) failure with the release_debug version, though not the regular release (an always illuminative "variable seqpos is out of range" error).
Rocco Moretti 7 years Looks like it may be related to an uninitialized variable issue: http://benchmark.graylab.jhu.edu/sub_test/71848545
Andy Watkins 7 years Yes! Every day or so I have checked your recent PR to link to the valgrind_detailed you were running. I will fix this before I leave.
notify author
notify list [rosetta-logs@googlegroups.com]