|Anonymous | Login||2022-01-22 21:19 CST|
|My View | View Issues|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000187||Rosetta||[All Projects] Input Handling||public||2013-03-01 10:37||2013-03-01 13:16|
|Fixed in Version|
|Summary||0000187: -in:file:obey_ENDMDL default|
|Description||Minicon 2013 defaults report 0000002|
Rosetta reads ALL MODELS of multimodel PDBs, and loads them into the same pose. This is a problem for multimodel NMR PDBs, because there will be 20 different conformations of the same protein all piled up on the same coordinates, resulting in huge memory, ludicrous score, useless Poses.
-in:file:obey_ENDMDL true changes this behavior to read only the first model of multimodel PDBs.
|Additional Information||There are two major classes of multimodel PDBs discussed at MiniCON 2013. NMR PDBs require obey_ENDMDL to be to true. Other multimodel PDBs, particularly "biological unit" PDBs, require it to be false. Which case do we want to support as the default?|
There is also something called "CloudPDB" (?) which this will disrupt? I am vague on the details.
As of filing this bug, the plan is to NOT change the default.
|Application(s) Affected||NMR / biological unit / multimodel PDBs|
|Command Line Used||* -in:file:obey_ENDMDL|
|Fixed in SVN Version|
"In addition to the biopdbs which use multimodels which are biologically relevant, I am worried that some non-Rosetta programs may use them as part of their output; people may be using the default behavior of multimodel PDBs unknowingly. If this change is going to be made, would it be possible to -- before the default is changed -- to have cases which would be affected spit out a massive warning banner … something like "READING OF THIS PDB WILL CHANGE IN THE NEAR FUTURE".
If no one has a problem after a few weeks, maybe the default could then be changed?"
I think your suggestion is fine...actually, for this flag, I think
it's probably fine to leave as-is. You've demonstrated that *both*
defaults are wrong, so there's no real reason to change which wrong
state we favor.
I don't think there's enough information in the PDB itself to reliably
detect whether the user wants more than the first model or not...you'd
need an algorithm like "measure the center of mass of each model; if
they're all the same, then assume NMR and use only first model;
otherwise use all models", but that's so heavy as to be useless.
rmoretti (Attentive Developer)
In the multimodel PDB breakout/action session on Tuesday afternoon (attendees: Rocco Moretti, Frank Dimaio, Evan Baugh, a fourth whose name I'm unfortunately blanking on at the moment) it was decided that having either read-only-first-model or read-all-atoms as default would be less than desirable.
The conclusion we came to is that if Rosetta encounters a multi-model PDB (with more than one model) it should raise an error by default and refuse to load the PDB, much like if it raises an error if it encounters an unrecognized residue. We should then also provide an option to control loading (referenced in the above-mentioned error message), to specify either to load all the atoms into one pose, or to load a specific model from the PDB (which may be the first model, but doesn't necessarily have to be). This allows both the biounit users and the NMR model users to control things appropriately.
We also discussed the future possibility of loading in all of the models as separate poses (effectively turning 1 PDB into multiple separate ones), or doing something like an "ensemble pose" representation. Both were deemed as potentially worthwhile, but not needed now. Though a string option controlling the setting was thought to allow for future expansion (something like "-in:file:multimodel 2", "-in:file:multimodel together", "-in:file:multimodel all", "-in:file:multimodel 2,3,5", etc.)
|2013-03-01 10:37||smlewis||New Issue|
|2013-03-01 10:38||smlewis||Relationship added||related to 0000188|
|2013-03-01 10:53||smlewis||Tag Attached: Minicon_2013_defaults|
|2013-03-01 11:51||smlewis||Note Added: 0000150|
|2013-03-01 11:51||smlewis||Note Added: 0000151|
|2013-03-01 13:16||rmoretti||Note Added: 0000155|
|Copyright © 2000 - 2012 MantisBT Group|