「view this page in B3 βῆτα server」

Revisions №60943

branch: master 「№60943」
Commited by: Andrew Leaver-Fay
GitHub commit link: 「bd4d9acbca68f827」 「№4238」
Difference from previous tested commit:  code diff
Commit date: 2019-09-23 09:23:11
linux.clang linux.gcc linux.srlz mac.clang
debug
release
unit
linux.clang.cxx11thread.serialization.python37.PyRosetta4.unit linux.gcc.python36.PyRosetta4.unit mac.PyRosetta.unit build.clean.debug cppcheck mysql postgres linux.clang.python36.build.debug linux.zeromq.debug mpi mpi.serialization linux.icc.build.debug OpenCL mac.clang.python36.build.debug build.header build.levels ninja graphics static linux.ui mac.ui build.xcode beautification code_quality.clang_analysis serialization integration.addsan integration.mpi integration.release_debug integration.tensorflow integration.thread integration.tutorials integration maintenance.documentation performance profile linux.clang.python35.release.PyRosetta4.MinSizeRel linux.clang.python36.release.PyRosetta4.MinSizeRel linux.clang.python37.release.PyRosetta4.MinSizeRel ubuntu.clang.python27.release.PyRosetta4.MinSizeRel ubuntu.clang.python37.release.PyRosetta4.MinSizeRel linux.clang.python35.release.PyRosetta4.Release linux.clang.python37.release.PyRosetta4.Release ubuntu.clang.python27.release.PyRosetta4.Release release.source scientific.antibody_snugdock scientific.cofactor_binding_sites.debug scientific.cofactor_binding_sites scientific.fast_relax_5iter.debug scientific.ligand_docking scientific.mhc_epitope_energy.debug scientific.mp_dock.debug scientific.mp_dock scientific.mp_domain_assembly.debug scientific.mp_domain_assembly scientific.mp_f19_ddG_of_mutation.debug scientific.mp_f19_ddG_of_mutation scientific.mp_f19_decoy_discrimination scientific.mp_f19_energy_landscape scientific.mp_lipid_acc.debug scientific.mp_lipid_acc scientific.mp_relax.debug scientific.mp_relax scientific.mp_symdock.debug scientific.mp_symdock scientific.rna_denovo_favorites.debug scientific.sewing.debug scientific.stepwise_rna_favorites.debug linux.clang.score linux.gcc.score mac.clang.score linux.scripts.pyrosetta scripts.rosetta.parse scripts.rosetta.validate scripts.rosetta.verify unit.addsan linux.clang.unit.release linux.gcc.unit.release util.apps

Merge pull request #4238 from RosettaCommons/aleaverfay/sjq_ilj_construction_bug Fixing bug w/ MSRS following JD3 refactor (Issue #4234). The MRSJobQueen had operated with the knowledge/assumption that the job_node index stored in the StandardInnerLarvalJob referred to the preliminary job node from which the later job node descended. The When the JD3 refactor went through back in January, the JobExtractor began using the job-node index stored in the InnerLarvalJob to record the node of origin for a job. The logic for when you declare one job node complete and move on to the next job node depended on the proper labeling of InnerLarvalJobs with their node of origin. However, multistage rosetta scripts was not labeling ILJ's with the job node but instead with the preliminary job node. This meant that multistage rosetta script jobs stopped working; it seems likely that everyone who has tried to use MSRS since January would have been unable to get it to run properly. (Thanks @odaunc for bringing this bug to Jack's and my attention!) It turns out that the integration tests for multistage_rosetta_scripts were not failing before because they were run using the VanillaJobDistributor, and the VanillaJobDistributor is so simple that it does not use the JobExtractor at all. In order to test JD3 applications in single threaded code, I'm making the VJD as similar as possible to the other JDs (Thanks for this suggestion, @JackMaguire ). It was a good thing I did this! It turns out that MRSJQ has/had a different idea of what the JobDAG would look like from the SJQ. The MRSJQ thinks that an n-stage protocol should have n nodes in the JobDAG. The SJQ thinks that if there are m input Poses, that the first m nodes in the JobDAG will represent one input Pose apiece. The VJD-version of the MRS integration test was exiting with an assertion failure. There's actually a one-line solution to this inconsistency/discrepancy, in job-dag philosophy, which is that when the MRSJQ calls the SJQ::create_and_init_inner_larval_job_from_prelim for the very first stage, the MRSJQ should pass "1" for the job-node index. (This "fix" is relative to earlier in this PR, because I am the one to have put the wrong value for this parameter.) This means that the InnerLarvalJobs that the SJQ constructs for the preliminary-job-node will have a different job-node index than the InnerLavalJobs that the MRSJQ constructs and that will actually be used to construct LarvalJobs. This discrepancy likely has no consequences, but should be noted. This PR causes several cosmetic integration test changes as all JD3 applications now will use the JobExtractor and the JobExtractor is more verbose in its interactions with the JobQueen.

...
Test: mac.clang.python27.build.xcode

 View log

Loading...

 View log in dialog  View log in log in separate window
Test: linux.clang.scientific.mp_dock

 View log

Loading...

 View log in dialog  View log in log in separate window
Test: linux.clang.scientific.mp_symdock

 View log

Loading...

 View log in dialog  View log in log in separate window