Open mnmelo opened 6 years ago
I think I can be convinced to go with option 2 but it would be good to have a broader understanding of all the combinations of options that we allow.
Also, we must have discussed this previously, but does a good reason remain not to switch over to passing AtomGroups around and abandon passing selection strings?
Right now some pretty extravagant things are allowed, such as fitting the c-alphas of a protein in universe1 to those of the protein in universe2 but the perform the rotation on some entirely separate group, such as the solvent of universe3. Option 2 would retain these possibilities.
On the switching to only AtomGroups
:
I have been little involved with this part of the code. My guess as to why Universes
are still accepted is historical reasons? In any case, there's little specific code to handle Universes
vs. AtomGroups
. It just works because a Universe
can mostly duck-type as an AtomGroup
for this purpose. IMO it'd be unpythonic to block that. Switching to AtomGroups
would then be mostly a matter of updating the docs.
That said, if we assume the user is passing AtomGroups
we can also assume that by default they'll want to rotate said AtomGroups
, and make subselection
default to 'all'
for any case.
This function deals elegantly with this corner case by creating a copy of the reference to fit against. I never had the time to include it into MDAnalysis. But the code has a good amount of tests written as well. It could allow for @mnmelo use case without breaking the API
The
align.alignto
can take eitherUniverses
or directlyAtomGroups
as itsmobile
andreference
structures. Atoms to actually fit are selected by optional selection strings, set with theselect
keyword and defaulting to'all'
. After alignment, by default, the entireUniverse
ofmobile
will be rotated/shifted.The default behavior is fine for the usual case where you have, say, a
Universe
with a protein asmobile
and another with a protein asreference
. In my case above I had a singleUniverse
with two lipids and wanted to superimpose both. I passed one lipid'sAtomGroup
asmobile
and the other asreference
and ended up with a rotatedUniverse
but no superposition since both groups come from the sameUniverse
that was rotated.Upon understanding the puzzling result, I figured I could use the
subselection
keyword to specify 'all' instead of the defaultNone
. This will force a calculation ofmobile.select_atoms("all")
that will be rotated, instead of the defaultmobile.universe
:This is clearly couterintuitive, and stems from the
Universe + selection_string
vs.AtomGroup
duality we have in the analysis API.I think in this case we could be clever and either: 1- be conservative and simply emit a warning when both
mobile
andreference
come from the sameUniverse
and nosubselection
is passed; 2- be slightly API-breaking and default tosubselection='all'
when bothmobile
andreference
come from the sameUniverse
.Even though it's API-breaking I vote for option 2, since I can see no use case for the default behavior when both groups come from the same
Universe
.