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

Revisions №60402

branch: master 「№60402」
Commited by: Andrew Leaver-Fay
GitHub commit link: 「b60bb5d8de163c42」 「№3084」
Difference from previous tested commit:  code diff
Commit date: 2018-09-17 09:59:30

Merge pull request #3084 from RosettaCommons/aleaverfay/jd3_combine_cl_and_jobdef_for_input_structs In Issue #3034 (#3034), @jadolfbr proposed that the Input subtag of the Job tag not be required and that instead, if it is absent, then the command line would be fallen back upon. This would allow you to write a job definition file with several jobs where you could leave unspecified which structures these jobs would be run on, and instead, could pair them with -s on the command line, e.g. as -s *.pdb. I think I have that now working and have a few new unit tests to convince me that it is. So this brings up a potential concern. Currently, the SJQ asks to deallocate Poses after the input node that uses them is done with its jobs. If the same 1ubq.pdb file were given to two different jobs, then it would be loaded, discarded, and loaded again. The SJQ made no attempt to test whether two Poses were effectively the same. (Indeed, just knowing that two Poses are initialized from the same PDB file is insufficient to know they are the same; e.g. it's possible to construct both a centroid and fullatom Pose from 1ubq.pdb and these Poses would be quite different). With the new system, the user probably intends for an input structure to be "the same" between different jobs. So then it that case, it would be somewhat wasteful to load the structure, deallocate it, and then load it again repeatedly. To address this, I'm adding a flag -jd3:load_input_poses_only_once. Note that per-job-options controlling how Poses are loaded could mean that the protocol behaves quite differently when this flag is on the command line.

Vikram K. Mulligan 6 years
Merging pull request #3084 resulted in a Mac/clang unit test failure. Andrew, could you check on this? [list]
Andy Watkins 6 years
Note that this unit test was likely affected by @lqtza's last merge, which definitely touched the scs code.
Andrew Leaver-Fay 6 years
Will do
Jeliazko Jeliazkov 6 years
Definitely due to my changes... I am looking at it. Odd that this didn't pop up during standard testing.
Andrew Leaver-Fay 6 years
OK, I think I understand the problem. Jeli's new code makes a decision based on the SCS_BlastResult.identity data member, but the unit test does not initialize this anywhere. https://github.com/RosettaCommons/main/blob/4a18ae197069a706bce92479b7d551dc9f0805a2/source/test/protocols/antibody/grafting/scs_functor_filtering.cxxtest.hh Jeli, could you expand the existing unit test suite to cover your new code in some level? From what I can tell, the existing test is not expected to filter anything, so the new code is not exercised beyond the "if" check (which fails).
Jeliazko Jeliazkov 6 years
Yep. Testing against identity is not something I had in mind when I wrote the test. Thanks for pointing this out to me.
...