Bob Hanson wrote:
...
this case is called molecule in RasMol2.7. and I don't want to load
them as two separate PDB-MODELs in Jmol animation frames. They
could be addressed for maneuvering independently but should be in the
same MODEL allowing measurements between molecules.
Jan, I wonder
Right. Can you give an example of where you would want those */1 out?
In other words:
select within(4.2, atomno=3)
No, only in the case of the large PDB files where the Jmol model
concept is violated.
OK, then, that's the key. I believe we will have to implement some sort
of model
Bob Hanson wrote:
Is this a feature or a bug? Should within restrict itself to a
given model, or is it interesting or important that one be able to
select within a distance across multiple model sets?
it is an important *feature* that one is able to use within across
multiple model sets.
Jan wrote:
Bob Hanson wrote:
Is this a feature or a bug? Should within restrict itself to a
given model, or is it interesting or important that one be able to
select within a distance across multiple model sets?
it is an important *feature* that one is able to use within across
multiple
OK, this one surprised me. I guess I can see where it is coming from,
and I'm not certain there's an obvious solution since I can't tell if
it's even a bug, but here goes
1) consider a set of several independent structures -- say,
On May 9, 2006, at 2:06 p, Bob Hanson wrote:
So I guess my question is this:
Is this a feature or a bug? Should within restrict itself to
a given model, or is it interesting or important that one be able
to select within a distance across multiple model sets?
Bob
well, no other
I agree with Tim.
Extrange or unintended as it may seem to select atoms from other models,
no other command is restricted to current model, so this one should not
either.
If the file is multi-model, one has to take extreme care for nearly anything.
Nico, look carefully -- some atoms are selected far from the center
because they are close to atomno=3 in some OTHER model.
But I'm OK with this behavior. We can leave it as is. If I think of
it, next time I'm working on documentation I'll try to make a note
there about this. It's too bad,
Diificult to distinguish, since most atoms nr. 3 are close to each other.
I have tested with another file and yes, it is selecting atoms in any model
that are close to specified atom in any model (i.e, not only within the same
model).
Test attached PDB file using atomno=22 as the reference
ยท
Angel Herraez wrote:
Diificult to distinguish, since most atoms nr. 3 are close to each other.
I have tested with another file and yes, it is selecting atoms in any model
that are close to specified atom in any model (i.e, not only within the same
model).
Test attached PDB file using
right, that's my point. It seems unnatural to me as well. That's why I
was surprised and initially thought it was a bug. Personally I can't
imagine it, either, unless
...I suppose some day we will be loading two molecules and maneuvering
them independently (like a drug and an active
On Tue, May 9, 2006 4:17 pm, Bob Hanson said:
right, that's my point. It seems unnatural to me as well. That's why I
was surprised and initially thought it was a bug. Personally I can't
imagine it, either, unless
Wouldn't it be more natural to have a model specifier? Do x to model
n, or to
Bob Hanson wrote:
right, that's my point. It seems unnatural to me as well. That's why I
was surprised and initially thought it was a bug. Personally I can't
imagine it, either, unless
...I suppose some day we will be loading two molecules and maneuvering
them independently (like a
As a select is processed, there is one long string of bits, one bit
for each atom in the *collection* -- meaning all the models. This
string is purposefully not separated per model, and all operations
and/or/not are carried out on all models at once. This is very
efficient, of course.
So,
Bob Hanson wrote:
As a select is processed, there is one long string of bits, one bit
for each atom in the *collection* -- meaning all the models. This
string is purposefully not separated per model, and all operations
and/or/not are carried out on all models at once. This is very
yeah, that's just what I just found. Slick.
My guess is that very few people have had to think about this, because
it's just not something a lot of people are doing right now. I'm
thinking about it because I suddenly have access to CIF files with
all the known quartz structures for instance.
On May 9, 2006, at 4:08 p, Nicolas Vervelle wrote:
Angel Herraez wrote:
Diificult to distinguish, since most atoms nr. 3 are close to each
other.
I have tested with another file and yes, it is selecting atoms in
any model that are close to specified atom in any model (i.e, not
only
I am completely swamped with other responsibilities ... I apologize.
Bob wrote:
So, for example, when you say atomno=3, if there
are 25 models, 25 atoms will be selected.
Correct.
And then, after that, when you say,
within(3.0, atomno=3), then that original set is expanded based
proximity.
On May 9, 2006, at 5:21 p, Nicolas Vervelle wrote:
Timothy Driscoll wrote:
On May 9, 2006, at 4:08 p, Nicolas Vervelle wrote:
as one example, it makes scripting multi-model animations much
easier. for instance, I can use this script:
select all
spacefill 30%
wireframe 0.25
select
OK, I checked that in, both in 10.3 and in 10.x. Works like a charm!
Thanks.
select within(3.0, atomset)
like select within group, chain, molecule (in 10.x), and model, is
specifically within a given model.
Works far more naturally, since generally one can only display one model
at a time
20 matches
Mail list logo
