>>> The outputfile appears to have additional line feeds (see picture) which,
>>> however are not seen in the windows notepad.
What application ARE the extra lines seen in?
Sounds like a problem with different newline conventions-
<CR> vs <LF> vs <CR><LF> -
although I shouldn't have thought extra carriage returns and linefeeds
would confuse a program reading a PDB.
Maybe the latest update uses the windows <CR><LF> on output
but still unix <LF> for input
Anyway, to help the developers debug, it would be good to provide
a hex dump of a portion of the pdb file. If you don't have a windows
hex editor you can use debug (I assume it still exists in windows 7)
Open a dos shell and cd to the directory where the peculiar
file is, and
debug lsq1.pdb
d 100 200
that is dump from the beginning of the file (which is loaded
starting hex 100) to hex 200. If there is a big header you
may want to skip down to the ATOM records, d 1000 1100
or such.
this gives hex dump on left and ascii on the right like below.
Lines are separated by two dots in the ascii which correspond
to 0D 0A in the hex dump-
-d 100 200
0B05:0100 57 79 61 72 74 69 74 65-3A 20 42 75 72 6E 73 20 Wyartite: Burns
0B05:0110 61 6E 64 20 46 69 6E 63-68 2C 20 41 6D 20 4D 69 and Finch, Am Mi
0B05:0120 6E 20 38 34 20 28 31 39-39 39 29 20 31 34 35 36 n 84 (1999) 1456
0B05:0130 2D 31 34 36 30 0D 0A 57-79 61 72 74 69 74 65 3A -1460..Wyartite:
0B05:0140 20 43 72 79 73 74 61 6C-6C 6F 67 72 61 70 68 69 Crystallographi
0B05:0150 63 20 65 76 69 64 65 6E-63 65 20 66 6F 72 20 74 c evidence for t
0B05:0160 68 65 20 66 69 72 73 74-20 70 65 6E 74 61 76 61 he first pentava
0B05:0170 6C 65 6E 74 2D 75 72 61-6E 69 75 6D 0D 0A 20 6D lent-uranium.. m
0B05:0180 69 6E 65 72 61 6C 0D 0A-31 31 2E 32 37 30 36 20 ineral..11.2706
0B05:0190 37 2E 31 30 35 35 20 32-30 2E 38 30 37 20 39 30 7.1055 20.807 90
0B05:01A0 20 39 30 20 39 30 20 50-32 32 32 0D 0A 55 31 0D 90 90 P222..U1.
0B05:01B0 0A 2E 36 31 31 20 2E 33-31 30 20 2E 31 35 34 20 ..611 .310 .154
0B05:01C0 33 0D 0A 43 0D 0A 2E 35-31 31 20 2E 34 31 30 20 3..C...511 .410
0B05:01D0 2E 31 35 34 20 32 0D 0A-61 6E 69 6F 6E 73 0D 0A .154 2..anions..
0B05:01E0 4F 31 0D 0A 2E 35 31 31-20 2E 33 31 30 20 2E 31 O1...511 .310 .1
0B05:01F0 35 34 0D 0A 65 6E 64 F0-97 01 75 03 E8 CE E0 3C 54..end...u....<
0B05:0200 2E
Matthias Zebisch wrote:
Hi again,
Thanks for your quick replies but I think I made myself not clear. here
is what I'm doing:
1) superpose proteinA.pdb onto proteinB.pdb : works, but gives out
proteinA_lsq1.pdb with extra empty lines (not the anisou lines ;o) )
2) superpose proteinA_lsq1.pdb onto proteinC.pdb : doesnt work because
proteinA_lsq1.pdb cannot be read
Any ideas?
Even if there is some compatibility issue between CCP4 and windows, I
guess superpose should be able to read its own files, shouldnt it?
Thanks,
Matthias
On 9/26/2011 9:13 PM, Jacob Keller wrote:
I vaguely recall notepad doing something wacky with files in certain
cases...why don't you get the excellent text editor NoteTab Light
[sic] (I use it all the time--free and works great), then take a look
at your files and see whether MS notepad altered the files.
JPK
On Mon, Sep 26, 2011 at 2:42 PM, Matthias Zebisch
<[email protected]> wrote:
Dear CCP4 users,
I am using the ccp4i version 6.2.0 under windows 7. I've come across a
problem with superpose.
The outputfile appears to have additional line feeds (see picture) which,
however are not seen in the windows notepad.
The structure can also be opened in coot and pymol. However, it is not
possible to use it within CCP4, eg. for a subsequent superposition.
Is this problem known to anybody and is there a simple workaround available?
I need to compare hell of a lot of relative domain orientations...
I did not have this problem on a second computer with ccp4 6.1.2. When I
updated to 6.2.0, the situation was as described above.
Any help will be highly appreciated,
Thanks, Matthias
