byron delabarre wrote:
I'm having troubles with the wonderful 'unmodelled blobs' feature in
coot when I use a CNS map.
I am using the 0.4 prerelease full prebuilt for unix (running FC5).
The 0.3.3 release didn't seem to be working properly when reading in CNS
maps (crashed everytime).
Yes, it was a "length of header lines" problem (a clipper issue really).
The problem is that Coot starts picking density from the symmetry
related map copies as 'blobs'. This renders the blob searching pretty
useless.
Hmmm... make sure that your reference molecule is in the place that you
want your blobs to appear. [I sometimes pick the wrong molecule and the
blobs are positioned "in space"]. Perhaps 1 blob in 100 or so may get
wrongly position, but as a rule they should be in and around the
reference molecule.
I did notice that Coot had some troubles reading the CNS cryst header (C
2 as opposed to C 1 2 1). I changed this by editing the PDB file but
still saw the problem with the blob search.
I suppose the ambiguity of where the 2 fold is needed to be resolved.
I generated the CNS map using the 'molecule' option - I guess coot does
some conversion to give the 'everywhere I go there is a map' functionality.
Indeed. EYC-TIED.
Note that this problem also extends to the water finding routine in Coot.
Hmmm.... I suspect that the map is not in good order - it wouldn't be
the first time that there were infelicities in reading a CNS map into
Coot. I'd rather suggest that you read in the CNS data either directly
using cns->coot or using Joel Bard's cns2coot script.
Some other questions:
1) Should the unmodelled blobs function work if you simply read in a
map (as opposed to auto-open mtz)?
Yes.
2) Is this just a 0.4 prerelease problem?
No.
3) Is the CNS map format to be blamed for not storing spacegroup info?
"Blame" is too strong a word I think. They have different preconceptions.
HTH,
Paul.
