I think if you are reading a file format which is defined to be fixed fields, you should read it as fixed fields. For better or for worst, the PDB format is defined so that each field has a particular column that it begins on and a column that it ends on.
I've looked in the PDB format definition on the RCSB website and, while it doesn't specifically give a Fortran format statement for TLS parameter, in it's discussion of REMARK 3 it often shows a line of column numbers. I presume those lines indicate that column numbers are important even for data in REMARK 3. Dale Ethan Merritt wrote: > Hi all, > > I have run into an issue that affects a number of CCP4 programs > (and my own code as well). > > The problem > ============ > > Programs that produce TLSOUT descriptions of TLS parameters create > a file using the equivalent of Fortran format (9F8.4) > Here are two examples: > > TLS > RANGE 'A 209.' 'A 220.' ALL > ORIGIN 7.895 -62.178 -23.423 > T 0.9518 0.3476 0.5619 -0.0034 0.2309 0.0373 > L 18.9522 22.2045 0.6690-19.0722 -1.8277 2.8987 > S -0.2024 -0.2744 0.5817 0.2971 -0.1614 -1.0850 -0.1876 0.0462 > > TLS > RANGE 'B 15.' 'B 21.' ALL > ORIGIN 13.302 -6.004 38.582 > T 0.0184 0.0726 0.0102 0.0294 -0.0001 0.0303 > L 10.9899108.7779 8.3249 28.9340 -8.6452-15.7119 > S -0.5438 0.6025 -0.5212 0.5483 3.1784 1.6311 -0.1214 -0.1901 > > You see the problem ... If any element of the T, L, or S tensors is > greater than 100 or less than -10 then two numbers run together in the output. > > This affects several hundred files in the current PDB, including some > from my lab, e.g. 3BJE and 3I7F, which I used as examples above. > > If a program reads this in using a corresponding Fortran fixed format, OK. > But the current versions of TLSANL and REFMAC5 don't do this; > they instead use a home-grown free format input routine. > > TLSANL > ============ > > When TLSANL hits one of these files, it exits with the message > ****** INVALID CHARACTER "." AT POSITION 16. > > *** FORMAT ERROR ON RECORD: > L 10.9899108.7779 8.3249 28.9340 -8.6452-15.7119 > > *** L OR S SPECIFICATION MISSING FOR TLS GROUP 12 12 > > This is annoying, but at least it's obvious that something went wrong. > > Refmac > ============= > > When Refmac hits one of these, the result is more insidious. > Instead of exiting with an error message, it prints a small warning, > stores a mangled set of values, and continues. > Here is a snippet from the log file from refinement of 3I7F > > Data line--- TLS > Data line--- RANGE 'A 209.' 'A 220.' ALL > Data line--- ORIGIN 7.895 -62.178 -23.423 > Data line--- T 0.9518 0.3476 0.5619 -0.0034 0.2309 0.0373 > Data line--- L 18.9522 22.2045 0.6690-19.0722 -1.8277 2.8987 > *** Warning > Illegal number in field 4 > Data line--- S -0.2024 -0.2744 0.5817 0.2971 -0.1614 -1.0850 -0.1876 > 0.0462 > > [snip] > > Initial TLS parameters > > TLS group 3: > > T tensor ( 3) = 0.952 0.348 0.562 -0.003 0.231 0.037 > L tensor ( 3) = 18.952 22.204 0.000 -1.828 2.899 0.000 > S tensor ( 3) = -0.202 -0.274 0.582 0.297 -0.161 -1.085 -0.188 > 0.046 > > So the input tensor L > L 18.9522 22.2045 0.6690-19.0722 -1.8277 2.8987 > has become > L 18.952 22.204 0.000 -1.828 2.899 0.000 > > This perturbs the refinement, sometimes fatally. > > In fact, I think this is the reason I have had problems with TLS refinement > in recent refmac versions. Every time you recycle the TLSOUT as the TLSIN for > the next refinement round, you risk kicking one or more of the TLS group > descriptions out into the next county. > > TLSMD > ======== > > The TLSIN files produced by the TLSMD server can trigger the same problem. > This may explain why some people have reported problems with using the pair > of files > (XYZIN TLSIN) returned by the server for use in refmac refinement. > > > > Possible solutions > ====================== > > The obvious fix is to change all programs that create a TLSOUT file to > guarantee that the tensor elements are separated by whitespace. > > At a minimum, this includes > tlsmd tlsextract (from my lab, I've already changed our in-house copies) > refmac5 > anisoanl > > The new format could either be the equivalent of Fortran > ( 9(X,F8.4)) or ( 9(X,F8.3)) > > The first of these preserves the precision, but would break any program that > uses a fixed format input statement describing the current format. > > The second is backward compatible with existing fixed format input programs, > but loses one decimal of precision. > > Both TLSANL and REFMAC are happy if you add the extra whitespace, but I don't > know what other programs out there might break because they use fixed format > input. > > > Please discuss. I want to modify the TLSMD server output accordingly. > > cheers, > > Ethan >
