Hi Paul,
Can changing the CELL of the moving molecule after
doing an SSM cause problems if one is interested in lattice contacts
of the moving molecule ? Will symmetry related copies of the moving
molecule now use the cell of the reference molecule ?
If so, this is a real issue for some of the things I am trying to do
(detecting if differences in conformation are influenced by different
lattice interactions). Is there any way of preventing this from
happening ?
Thanks
Andrew
On 20 Dec 2010, at 17:25, Paul Emsley wrote:
> On 20/12/10 14:55, David Komander wrote:
>> Dear all
>> I have noticed a (related?) CRYST1 problem/bug/feature.
>> superposing 2 molecules in 2 different cells, and saving the moved
>> molecule, changed the CRYST1 record of the saved file to the one
>> from the reference molecule.
>>
>> original pdb
>> CRYST1 60.400 72.150 133.010 90.00 90.00 90.00 P 21 21 21
>> SCALE1 0.016556 0.000000 0.000000 0.00000
>> SCALE2 0.000000 0.013860 0.000000 0.00000
>> SCALE3 0.000000 0.000000 0.007518 0.00000
>>
>> after coot SSM and save_as
>> CRYST1 69.675 39.000 36.255 90.00 111.69 90.00 C 1 2 1
>> SCALE1 0.014352 0.000000 0.005709 0.00000
>> SCALE2 0.000000 0.025641 0.000000 0.00000
>> SCALE3 0.000000 0.000000 0.029684 0.00000
>>
>> this generates very funny results in PyMol. Changing the CRYST
>> record after saving to the original cell seems to fix this, but
>> surely the CRYST record should stay the same upon loading and
>> saving a pdb-file?
>>
>> I wonder if this is to do with me? I am running coot on a MBP, snow
>> leopard, and just upgraded to the latest version of everything
>> using the latest builds from Bill Scott. Let me know if I have left
>> out some crucial information.
>>
>
>
> Hello David,
>
> Yes, saving and loading a file should not change the CELL card.
>
> Which version are you using?
>
> $ coot --version-full
>
> This code was updated in rev 3272.
>
> After SSMing, the moving molecule should match the CELL, SCALE and
> ORIGx cards of the reference molecule.
>
>
> Paul.
|