Re: [ccp4bb] ?lsqkab?

[Eleanor Dodson]

Charlie - can you point  me to an example to test?
Eleanor

On 16 April 2018 at 23:57, Daniel M. Himmel, Ph. D.  wrote:

> Have you tried using the CNS script rmsd.inp?  You can explicitly list
> the atoms to superimpose and set "coord_fit=true;".
>
> -Daniel
>
>
> On Mon, Apr 16, 2018 at 3:30 PM, Carter, Charlie 
> wrote:
>
>> I think I’ve asked this question before and I was pointed in a number of
>> unsuitable (for various reasons, including lack of access to the programs
>> like ccot) directions. Why can one not use lsqkab to superimpose the
>> nucleic acid portions of protein RNA complexes?
>>
>> I’m asking now because I’ve found that if both moving and target pdb
>> files contain only nucleic acids, things work exactly as they are supposed
>> to do. However, when I try to then use the same algorithmic sequence,
>> properly annotated for Chain names, and using exactly the same list of
>> moving and fixed atoms, I find “you have failed to find any atoms to fit”.
>>
>> None of the various other superposition algorithms I’ve found will
>> actually do what I want to do, it seems. I thought I’d found a way to use
>> lsqkab, but it seems not.
>>
>> I’m puzzled…
>>
>> Thanks for any assistance,
>>
>> Charlie
>>
>>
>

Re: [ccp4bb] ?lsqkab?

[Daniel M. Himmel, Ph. D.]

Have you tried using the CNS script rmsd.inp?  You can explicitly list
the atoms to superimpose and set "coord_fit=true;".

-Daniel


On Mon, Apr 16, 2018 at 3:30 PM, Carter, Charlie  wrote:

> I think I’ve asked this question before and I was pointed in a number of
> unsuitable (for various reasons, including lack of access to the programs
> like ccot) directions. Why can one not use lsqkab to superimpose the
> nucleic acid portions of protein RNA complexes?
>
> I’m asking now because I’ve found that if both moving and target pdb files
> contain only nucleic acids, things work exactly as they are supposed to do.
> However, when I try to then use the same algorithmic sequence, properly
> annotated for Chain names, and using exactly the same list of moving and
> fixed atoms, I find “you have failed to find any atoms to fit”.
>
> None of the various other superposition algorithms I’ve found will
> actually do what I want to do, it seems. I thought I’d found a way to use
> lsqkab, but it seems not.
>
> I’m puzzled…
>
> Thanks for any assistance,
>
> Charlie
>
>

[ccp4bb] ?lsqkab?

[Carter, Charlie]

I think I’ve asked this question before and I was pointed in a number of 
unsuitable (for various reasons, including lack of access to the programs like 
ccot) directions. Why can one not use lsqkab to superimpose the nucleic acid 
portions of protein RNA complexes?

I’m asking now because I’ve found that if both moving and target pdb files 
contain only nucleic acids, things work exactly as they are supposed to do. 
However, when I try to then use the same algorithmic sequence, properly 
annotated for Chain names, and using exactly the same list of moving and fixed 
atoms, I find “you have failed to find any atoms to fit”.

None of the various other superposition algorithms I’ve found will actually do 
what I want to do, it seems. I thought I’d found a way to use lsqkab, but it 
seems not. 

I’m puzzled…

Thanks for any assistance,

Charlie

Re: [ccp4bb] lsqkab

[Robert Byrne]

I noticed the same problem with more recent versions of CCP4 (up to and 
including 6.5.001) but failed to report it…. 

It seems that the problem occurs regardless of the atoms chosen for selection - 
main, side or all -  and with both v2 and v3 PDB files.

The 'LSQ Superpose’ in Coot can superpose nucleic acids, but it is seemingly 
not possible to define non-contiguous selections.

Rob

 On 04 Feb 2015, at 17:30, Carter, Charlie car...@med.unc.edu wrote:
 
 I'm (still) using ccp4.6.1.1.
 
 Scripts that used to superimpose one tRNA on another now all return the error 
 
 YOU HAVE FAILED TO FIND ANY ATOMS TO FIT 
 
 I've looked high and low for a reason for this and failed. The pdb files 
 themselves look normal and behave well in PYMOL. They have CRYST1 cards. I 
 cannot even superimpose a file on itself!
 
 Anyone have any suggestions?
 
 Thanks so much,
 
 Charlie
 
 here is what I'm trying to implement:
 
 lsqkab XYZIN1 $1 XYZIN2 $2 XYZOUT $2_$1 $2_$1.log  END-lsqkab
 FIT RESIDUE MAIN 2 TO 6 
 MATCH 2 to 6
 FIT RESIDUE MAIN 68 TO 72 
 MATCH 68 to 72
 OUTPUT XYZ
 END
 END-lsqkab

Re: [ccp4bb] lsqkab

[Paul Emsley]

On 04/02/15 17:21, Robert Byrne wrote:


The 'LSQ Superpose’ in Coot can superpose nucleic acids, but it is seemingly 
not possible to define non-contiguous selections.


Admittedly there's no clicky-clicky interface, but you can do it and 
it's described in the manual.


https://www2.mrc-lmb.cam.ac.uk/Personal/pemsley/coot/web/docs/coot.html#index-Least-Squares-Fitting-113

Paul.

[ccp4bb] lsqkab

[Carter, Charlie]

I'm (still) using ccp4.6.1.1.

Scripts that used to superimpose one tRNA on another now all return the error 

YOU HAVE FAILED TO FIND ANY ATOMS TO FIT 

I've looked high and low for a reason for this and failed. The pdb files 
themselves look normal and behave well in PYMOL. They have CRYST1 cards. I 
cannot even superimpose a file on itself!

Anyone have any suggestions?

Thanks so much,

Charlie

here is what I'm trying to implement:

lsqkab XYZIN1 $1 XYZIN2 $2 XYZOUT $2_$1 $2_$1.log  END-lsqkab
FIT RESIDUE MAIN 2 TO 6 
MATCH 2 to 6
FIT RESIDUE MAIN 68 TO 72 
MATCH 68 to 72
OUTPUT XYZ
END
END-lsqkab

Re: [ccp4bb] lsqkab

[Tim Gruene]

Dear Charlie,

could it be related to that furanose atoms now have primes (') instead
of asterisks (*) in their names?

Best,
Tim

On 02/04/2015 05:30 PM, Carter, Charlie wrote:
 I'm (still) using ccp4.6.1.1.
 
 Scripts that used to superimpose one tRNA on another now all return the error 
 
 YOU HAVE FAILED TO FIND ANY ATOMS TO FIT 
 
 I've looked high and low for a reason for this and failed. The pdb files 
 themselves look normal and behave well in PYMOL. They have CRYST1 cards. I 
 cannot even superimpose a file on itself!
 
 Anyone have any suggestions?
 
 Thanks so much,
 
 Charlie
 
 here is what I'm trying to implement:
 
 lsqkab XYZIN1 $1 XYZIN2 $2 XYZOUT $2_$1 $2_$1.log  END-lsqkab
 FIT RESIDUE MAIN 2 TO 6 
 MATCH 2 to 6
 FIT RESIDUE MAIN 68 TO 72 
 MATCH 68 to 72
 OUTPUT XYZ
 END
 END-lsqkab
 

-- 
Dr Tim Gruene
Institut fuer anorganische Chemie
Tammannstr. 4
D-37077 Goettingen

GPG Key ID = A46BEE1A



signature.asc
Description: OpenPGP digital signature

Re: [ccp4bb] lsqkab problem to be reported to developer

[Eleanor Dodson]

Can you send more details? the log file? the pdb


On 30 May 2014 22:54, Carter, Charlie car...@med.unc.edu wrote:

 This is a bizarre problem. I'm trying to superimpose multiple
 conformations of the same protein using segments I expect not to change.
 LSQKAB bails with this error each time:

  *** RWBROOK error: point code unitfunction
  ***1 -1022MMDB_F_Atom
  *** file   : 4ARC_rot.pdb
  *** reason : internal error #2 -- report to developer
  *** Execution stopped.

 It also appears very likely that the superposition is wrong. I expect an
 RMSD for the superimposed atoms (main chain only) of less than 2 Å, yet the
 program reports that the RMSD is 7 Å.

 Thanks to anyone for a diagnosis and prescription.

 Charlie

Re: [ccp4bb] lsqkab problem to be reported to developer

[Eugene Krissinel]

Charlie,

Most probably this indicates a problem with your PDB file, either a format or 
things like misplaced or absent residue name etc. If you can send me your files 
and exact command that you run, I can have a look into this.

In future, if you see a message like report to developer please send it to 
CCP4 group rather than BB, this will help to deal with it faster.

Many thanks,

Eugene


On 30 May 2014, at 22:54, Carter, Charlie wrote:

 This is a bizarre problem. I'm trying to superimpose multiple conformations 
 of the same protein using segments I expect not to change. LSQKAB bails with 
 this error each time:
 
 *** RWBROOK error: point code unitfunction
 ***1 -1022MMDB_F_Atom
 *** file   : 4ARC_rot.pdb
 *** reason : internal error #2 -- report to developer
 *** Execution stopped.
 
 It also appears very likely that the superposition is wrong. I expect an RMSD 
 for the superimposed atoms (main chain only) of less than 2 Å, yet the 
 program reports that the RMSD is 7 Å.
 
 Thanks to anyone for a diagnosis and prescription.
 
 Charlie


-- 
Scanned by iCritical.

[ccp4bb] lsqkab problem to be reported to developer

[Carter, Charlie]

This is a bizarre problem. I'm trying to superimpose multiple conformations of 
the same protein using segments I expect not to change. LSQKAB bails with this 
error each time:

 *** RWBROOK error: point code unitfunction
 ***1 -1022MMDB_F_Atom
 *** file   : 4ARC_rot.pdb
 *** reason : internal error #2 -- report to developer
 *** Execution stopped.

It also appears very likely that the superposition is wrong. I expect an RMSD 
for the superimposed atoms (main chain only) of less than 2 Å, yet the program 
reports that the RMSD is 7 Å.

Thanks to anyone for a diagnosis and prescription.

Charlie

Re: [ccp4bb] LSQKAB

[Paul Emsley]

On 30/12/13 04:10, Doeke Hekstra wrote:

Hi All,

I would like to superimpose a query chain (moving frame) from a rather large 
PDB file (~50 chains) to a target frame specified by a chain in a reference PDB 
file.

  echo FIT RESIDUE CA 2 TO 63 CHAIN $CHAIN  lsqkab.conf
  echo MATCH RESIDUE CA 2 TO 63 CHAIN A  lsqkab.conf
  echo OUTPUT XYZ  lsqkab.conf
  echo end  lsqkab.conf
  lsqkab XYZINM ${f} XYZINF 1AHO.pdb XYZout ${fileout} lsqkab.conf

Rotates/translates all chains in the moving frame to the target frame and 
outputs all of them up to 40,000 atom records. Would it be possible to output 
only the chain of interest (preferred) OR to output all atom records?



This doesn't answer your question, but if you have Coot you can use the 
attached script as a work-around (you will have to do some editing).


Paul.



(let ((imol-1 (read-pdb reference.pdb))
  (imol-2 (read-pdb moving.pdb))
  (c-ids (list A B C ))) ;; or perhaps (chain-ids imol-2)
  
  (for-each (lambda (chain-id)
	  (let ((imol-moving-copy (copy-molecule imol-2)))
		(clear-lsq-matches)
		(add-lsq-match 2 63 A 2 63 chain-id 0)
		(apply-lsq-matches imol-1 imol-moving-copy)
		(let*  ((selection (string-append // chain-id))
			(frag-mol (new-molecule-by-atom-selection imol-moving-copy selection))
			(frag-mol-file-name (string-append fragment- chain-id .pdb)))
			   
		  (write-pdb-file frag-mol frag-mol-file-name
	c-ids))

Re: [ccp4bb] LSQKAB

[Doeke Hekstra]

Hi All,

I would like to superimpose a query chain (moving frame) from a rather large 
PDB file (~50 chains) to a target frame specified by a chain in a reference PDB 
file. 

 echo FIT RESIDUE CA 2 TO 63 CHAIN $CHAIN  lsqkab.conf
 echo MATCH RESIDUE CA 2 TO 63 CHAIN A  lsqkab.conf
 echo OUTPUT XYZ  lsqkab.conf
 echo end  lsqkab.conf
 lsqkab XYZINM ${f} XYZINF 1AHO.pdb XYZout ${fileout} lsqkab.conf

Rotates/translates all chains in the moving frame to the target frame and 
outputs all of them up to 40,000 atom records. Would it be possible to output 
only the chain of interest (preferred) OR to output all atom records?

Thanks, Doeke

Doeke R. Hekstra, Ph.D.
Postdoctoral Researcher, Ranganathan Lab
Green Center for Systems Biology
UT Southwestern Medical Center
6001 Forest Park Rd, Dallas, TX 75390

[ccp4bb] LSQKAB with trajectory files

[Carter, Charlie]

I've just tried to use LSQKAB to transform an entire trajectory file that is a 
pdb file with ENDMDL cards between models to a new orientation for the purpose 
of making use of work with the new orientation. 

LSQKAB returns with an error:

 *** RWBROOK error: point code unitfunction
 ***1  -411MMDB_F_Open
 *** file   : Cat_3state_traj.pdb
 *** reason : MMDB's error in structuring models
 ***  at input line #2665:
 ATOM  1  N   MET 1  19.334   0.098  11.397 
 
 *** continue running, may crash ...
 
BFONT COLOR=#FF!--SUMMARY_BEGIN--
 LSQKAB:   XYZOPEN: Error opening logical name XYZINM
 LSQKAB:   XYZOPEN: Error opening logical name XYZINM

This suggests that xyzfit cannot repeat a transformation on each model and then 
output a rotated pdb file for the trajectory. 

Can anyone suggest an alternative, either involving lsqkab or another 
superposition program?

Many thanks,

Charlie

[ccp4bb] השב: [ccp4bb] LSQKAB with trajectory files

[Boaz Shaanan]

Hi Charlie, one possible way of doing this is through UCSF-Chimera. It'll read each of the models into a different slot, then you can apply the transformation you choose to each of the models. I think I'm right. The Chimera support team may help you figure
 out how to do this in one go.

Best regards,
Boaz




 הודעה מקורית 
מאת Carter, Charlie car...@med.unc.edu 
תאריך: 03/11/2013 20:24 (GMT02:00) 
אל CCP4BB@JISCMAIL.AC.UK 
נושא [ccp4bb] LSQKAB with trajectory files 




I've just tried to use LSQKAB to transform an entire trajectory file that is a pdb file with ENDMDL cards between models to a new orientation for the purpose of making use of work with the new orientation.


LSQKAB returns with an error:

*** RWBROOK error: point code unit function
*** 1 -41 1 MMDB_F_Open
*** file : Cat_3state_traj.pdb
*** reason : MMDB's error in structuring models
*** at input line #2665:
ATOM 1 N MET 1 19.334 0.098 11.397 
*** continue running, may crash ...

BFONT COLOR=#FF!--SUMMARY_BEGIN--
LSQKAB: XYZOPEN: Error opening logical name XYZINM
LSQKAB: XYZOPEN: Error opening logical name XYZINM

This suggests that xyzfit cannot repeat a transformation on each model and then output a rotated pdb file for the trajectory.


Can anyone suggest an alternative, either involving lsqkab or another superposition program?

Many thanks,

Charlie

[ccp4bb] LSQKAB error: you have failed to find any atoms to fit

[sreetama das]

Dear All,
 I am trying to superpose 2 chains from the same pdb file. I have 
generated 2 separate pdb files, each with one chain, using PDBSET.
When I run LSQKAB with the 2 generated files (on UBUNTU 10.04, ccp4 6.2) it 
fails to run. The 2 input files CONTAIN the columns for occupancies and 
B-factors. ( some old mails in the BB mention checking if these columns are 
present)

details of the error are:

OPEN FILES AS REQUESTED
opening coordinate file of model to be moved
Logical name: XYZIN2  File name :/abc/def/../../*2.pdb
pdb file is being opened on unit 1 for input
Matrices derived from CRYST1 CARD in COORDINATE FILE
                RF                                                RO
matrices .

logical name: XYZOUT filename: /abc/def/../../*12.pdb
pdb file is being opened on unit 2 for output

opening coordinate file of fixed model
logical name:XYZIN1 filename:/abc/def/../../*1.pdb
pdb file is being opened on unit 3 for input

MAtrices derived from cryst1 card in coord. file
            RF             RO
matrices...

FORMATTED    UNKNOWN file opened on unit 7
logical name: RMSTAB, filename :/abc/def/../../*_rmstab.graph

FORMATTED    UNKNOWN file opened on unit 8
logical name: DELTAS, filename: /abc/def/../../*_deltas.log

** ZERO OCCUPANCIES IN WORKING SET**  0.0
** ZERO OCCUPANCIES IN REFERENCE SET**  0.0
LSQKAB: ***ERROR - YOU HAVE FAILED TO FIND ANY ATOMS TO FIT ***
##

Any idea how to fix the problem?


Thanks in advance,
regards,
sreetama

[ccp4bb] LSQKAB error: you have failed to find any atoms to fit

[sreetama das]

Dear All,
 I am trying to superpose 2 chains from the same pdb file. I have 
generated 2 separate pdb files, each with one chain, using PDBSET.
When I run LSQKAB with the 2 generated files (on UBUNTU 10.04, ccp4 6.2) it 
fails to run. The 2 input files CONTAIN the columns for occupancies and 
B-factors. ( some old mails in the BB mention checking if these columns are 
present)

details of the error
 are:

OPEN FILES AS REQUESTED
opening coordinate file of model to be moved
Logical name: XYZIN2  File name :/abc/def/../../*2.pdb
pdb file is being opened on unit 1 for input
Matrices derived from CRYST1 CARD in COORDINATE FILE
                RF                                                RO
matrices .

logical name: XYZOUT filename: /abc/def/../../*12.pdb
pdb file is being opened on unit 2 for output

opening coordinate file of fixed model
logical name:XYZIN1 filename:/abc/def/../../*1.pdb
pdb file is being opened on unit 3 for input

MAtrices derived from cryst1 card in coord. file
            RF             RO
matrices...

FORMATTED    UNKNOWN file opened on unit 7
logical name: RMSTAB, filename :/abc/def/../../*_rmstab.graph

FORMATTED    UNKNOWN file opened on unit 8
logical name: DELTAS, filename:
 /abc/def/../../*_deltas.log

** ZERO OCCUPANCIES IN WORKING SET**  0.0
** ZERO OCCUPANCIES IN REFERENCE SET**  0.0
LSQKAB: ***ERROR - YOU HAVE FAILED TO FIND ANY ATOMS TO FIT ***
##

Any idea how to fix the problem?


Thanks in advance,
regards,
sreetama

[ccp4bb] LSQKAB error: you have failed to find any atoms to fit

[sreetama das]

Dear All,
 I am trying to superpose 2 chains from the same pdb file. I have 
generated 2 separate pdb files, each with one chain, using PDBSET.
When I run LSQKAB with the 2 generated files (on UBUNTU 10.04, ccp4 6.2) it 
fails to run. The 2 input files CONTAIN the columns for occupancies and 
B-factors. ( some old mails in the BB mention checking if these columns are 
present)

details of the error
 are:

OPEN FILES AS REQUESTED
opening coordinate file of model to be moved
Logical name: XYZIN2  File name :/abc/def/../../*2.pdb
pdb file is being opened on unit 1 for input
Matrices derived from CRYST1 CARD in COORDINATE FILE
                RF                                                RO
matrices .

logical name: XYZOUT filename: /abc/def/../../*12.pdb
pdb file is being opened on unit 2 for output

opening coordinate file of fixed model
logical name:XYZIN1 filename:/abc/def/../../*1.pdb
pdb file is being opened on unit 3 for input

MAtrices derived from cryst1 card in coord. file
            RF             RO
matrices...

FORMATTED    UNKNOWN file opened on unit 7
logical name: RMSTAB, filename :/abc/def/../../*_rmstab.graph

FORMATTED    UNKNOWN file opened on unit 8
logical name: DELTAS, filename:
 /abc/def/../../*_deltas.log

** ZERO OCCUPANCIES IN WORKING SET**  0.0
** ZERO OCCUPANCIES IN REFERENCE SET**  0.0
LSQKAB: ***ERROR - YOU HAVE FAILED TO FIND ANY ATOMS TO FIT ***
##

Any idea how to fix the problem?


Thanks in advance,
regards,
sreetama

[ccp4bb] LSQKAB error

[Anita Lewit-Bentley]

Dear all,

I am trying to compare several related structures using LSQKAB. In  
order to refine the superpositions, I'd like to use the option  
radius, to see the relative postion of certain residues within a  
given distance from a common point.


The programme reads the commands OK:
   ALL ATOMS MORE THAN 30.000 ANGSTROMS FROM REFERENCE POINT 46.520  
37.890 40.280 EXCLUDED


as well as the fixed input coordinate file:

  Logical name: XYZIN2  File name: wtC_on_MnA_SSM.pdb
  PDB file is being opened on unit 1 for INPUT.

No sign of any other file being opened/read, but the following error  
message is output instead:


 LSQKAB:   ERROR: in XYZADVANCE file has not been opened
 LSQKAB:   ERROR: in XYZADVANCE file has not been opened   

and the job stops.

This happens for both ccp4 versions 6.0.2 and 6.1.1.

Is there a working version of the programme somewhere? If not, what  
other programme could do the same thing (in a simple way...)?


Thanks for any suggestions!

Anita



Anita Lewit-Bentley
Unité d'Immunologie Structurale
CNRS URA 2185
Département de Biologie Structurale  Chimie
Institut Pasteur
25 rue du Dr. Roux
75724 Paris cedex 15
FRANCE

Tel: 33- (0)1 45 68 88 95
FAX: 33-(0)1 40 61 30 74
email: ale...@pasteur.fr

Re: [ccp4bb] LSQKAB error

[Anita Lewit-Bentley]

Dear Norman,

That did the trick! And was easy to do...

Thanks a lot,

Anita


Dear Anita

You could try adding the following additional line of input:

rotate matrix 1 0 0 0 1 0 0 0 1

This multiplies the data in XYZINM by the identity matrix (so that  
the data should be unchanged) but has the side effect of forcing the  
program to read in the XYZINF input file.


Norman

From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf  
Of Anita Lewit-Bentley

Sent: 16 March 2009 14:59
To: CCP4BB@JISCMAIL.AC.UK
Subject: [ccp4bb] LSQKAB error

Dear all,

I am trying to compare several related structures using LSQKAB. In  
order to refine the superpositions, I'd like to use the option  
radius, to see the relative postion of certain residues within a  
given distance from a common point.


The programme reads the commands OK:
   ALL ATOMS MORE THAN 30.000 ANGSTROMS FROM REFERENCE POINT 46.520  
37.890 40.280 EXCLUDED


as well as the fixed input coordinate file:

  Logical name: XYZIN2  File name: wtC_on_MnA_SSM.pdb
  PDB file is being opened on unit 1 for INPUT.

No sign of any other file being opened/read, but the following error  
message is output instead:


 LSQKAB:   ERROR: in XYZADVANCE file has not been opened
 LSQKAB:   ERROR: in XYZADVANCE file has not been opened   

and the job stops.

This happens for both ccp4 versions 6.0.2 and 6.1.1.

Is there a working version of the programme somewhere? If not, what  
other programme could do the same thing (in a simple way...)?


Thanks for any suggestions!

Anita



Anita Lewit-Bentley
Unité d'Immunologie Structurale
CNRS URA 2185
Département de Biologie Structurale  Chimie
Institut Pasteur
25 rue du Dr. Roux
75724 Paris cedex 15
FRANCE

Tel: 33- (0)1 45 68 88 95
FAX: 33-(0)1 40 61 30 74
email: ale...@pasteur.fr

Re: [ccp4bb] LSQKAB, version 6.0 vs version 6.1

[Clemens Vonrhein]

Hi Dave,

On Mon, Dec 22, 2008 at 02:58:31PM -0500, Borhani, David wrote:
 I think the LSQKAB change at Line 291(old)/Line 300(new) DOES introduce
 new and possibly incorrect logic.

Very possible, but ...
 
 I haven't looked at all the code, but this one change does seem to
 substitute a check that chain, residue number, and atom name (only 3
 characters; incorrect) match [OLD] for a check that chain, residue
 number, atom name (4 chars, correct), insertion code (correct, assuming
 that the insertion codes and residues numbers in the two proteins are
 lined up correctly), AND ALT CODE match [NEW].

I read that slightly differently:

OLD: check on the first three characters of the atom name

NEW: check on the first three characters of the atom name
  AND
 check on alternate conformation
  AND
 check on insertion code

There is no (new) check on chain or residue number - which is correct,
since the LSQKAB syntax allows to specify different chain identifiers
and different residue numbers for the work and reference PDB file.

The new code makes sense to me (but please double check and correct me
if I'm wrong): without it you get a complete mess in the match-up
(since atom name, chain and residue number are simply not enough to
pick one and _only_ one atom).

 The alt code match is, I suspect, a bug, in exactly the situation that
 Jose provided: one protein may have them, but the other may not (or may
 have different ones). One should perform the alignment such that the
 protein (residue) without alt codes aligns onto the other protein
 (residue) with the A alt code; to discard the residue pair is simply
 because alt codes don't match is not correct.

I'm not sure about that: LSQKAB is intended to superimposed two sets
of atoms. For that the user needs to specify exactly (!) what atoms
belong into these two sets. Your suggestion of having LSQKAB pick
AltConf A instead of an atom without AltConf introduces new logic
into LSQKAB that wasn't there before. So I wouldn't classify that as a
bug, since it does the right thing: making sure that one and _only_
one atom will be picked (whereas before this wasn't guaranteed).

Please note that I don't say your suggestion doesn't make sense: I
like automatic superposition programs that make sensible structural
assumptions and decisions (some LSQMAN commands or SSM in Coot). Just
that LSQKAB isn't really intended that way: it does exactly what it
says on the tin.

As a comparison, I've run a test with three PDB files:

  a) just 5 residues

  b) same 5 residues, but one side-chain has two alternate
 conformations (A and B)

  c) same 5 residues, but one residue has insertion code instead of
 residue number increment

  d) same 5 residues, but now with the alternate conformation
 side-chain and the insertion code residue

Running this against 4 LSQKAB binaries:

  A) LSQKAB sources from 6.0.2, compiled against 6.0.2 libraries

  B) LSQKAB sources from 6.0.2, compiled against 6.1.0 libraries

  C) LSQKAB sources from 6.1.0, compiled against 6.0.2 libraries

  D) LSQKAB sources from 6.1.0, compiled against 6.1.0 libraries

shows some interesting items (assuming that LSQKAB should match-up
only identical atoms, i.e. leaving your suggestion of automatic
decisions aside).

 - the 6.0.2 LSQKAB source shows non-zero RMS values in a variety of
   cases

   This makes no sense, since for any pair of the above PDB files the
   common atoms are identical.

 - the 6.0.2 LSQKAB source gives different results when swapping the
   two PDB files one superposes (i.e. superposing PDB1 onto PDB2 gives
   a different result thatn superposing PDB2 onto PDB1)

   Again, this doesn't make sense.

   Both of these points are due to the missing checks introduced into
   the latest version (which make sure that only identical atoms are
   picked).

 - the 6.0.1 LSQKAB source always gives rms values of zero and the
   order of PDB files doesn't matter.

To me the 6.1.0 sources look correct ... ?

Anyway, getting back to the original question (most people reading the
CCP4bb will be bored by now anyway):

 If I do the same superposition (with a pdb file that contains 
 alternative conformations) with LSQKAB version 6.0 and 6.1:
 1) Version 6.0 reports 110 atoms to be refined and does not report any 
 error or warning. The loggraph contains data for the residues with 
 alternative conformations.
 2) Version 6.1 reports 97 atoms to be refined, and it reports 13 atoms 
 as no match for workcd atom [...]. The loggraph does NOT contain data 
 for the residues with alternative conformations.
 
 Based on that, I have assumed that version 6.0 does include atoms in 
 alternative conformations (in fact, it seems to take into account each 
 conformations independently).

I can understand that this looks like a regression in 6.1 (since it
uses more atoms and shows residues with alternate conformations in the
loggraph). But I'm fairly certain that it did the wrong thing
nevertheless, 

Re: [ccp4bb] LSQKAB, version 6.0 vs version 6.1 - reposting (Sorry!)

[Clemens Vonrhein]

Dear all,

oops - due to some disk/network issues on my side, the final edits of
my email got lost. Sorry for reposting this again (corrected):

On Mon, Dec 22, 2008 at 02:58:31PM -0500, Borhani, David wrote:
 I think the LSQKAB change at Line 291(old)/Line 300(new) DOES introduce
 new and possibly incorrect logic.

Very possible, but ...
 
 I haven't looked at all the code, but this one change does seem to
 substitute a check that chain, residue number, and atom name (only 3
 characters; incorrect) match [OLD] for a check that chain, residue
 number, atom name (4 chars, correct), insertion code (correct, assuming
 that the insertion codes and residues numbers in the two proteins are
 lined up correctly), AND ALT CODE match [NEW].

I read that slightly differently:

OLD: check on the first three characters of the atom name

NEW: check on the first three characters of the atom name
  AND
 check on alternate conformation
  AND
 check on insertion code

There is no (new) check on chain or residue number - which is correct,
since the LSQKAB syntax allows to specify different chain identifiers
and different residue numbers for the work and reference PDB file.

The new code makes sense to me (but please double check and correct me
if I'm wrong): without it you get a complete mess in the match-up
(since atom name, chain and residue number are simply not enough to
pick one and _only_ one atom).

 The alt code match is, I suspect, a bug, in exactly the situation that
 Jose provided: one protein may have them, but the other may not (or may
 have different ones). One should perform the alignment such that the
 protein (residue) without alt codes aligns onto the other protein
 (residue) with the A alt code; to discard the residue pair is simply
 because alt codes don't match is not correct.

I'm not sure about that: LSQKAB is intended to superimposed two sets
of atoms. For that the user needs to specify exactly (!) what atoms
belong into these two sets. Your suggestion of having LSQKAB pick
AltConf A instead of an atom without AltConf introduces new logic
into LSQKAB that wasn't there before. So I wouldn't classify that as a
bug, since it does the right thing: making sure that one and _only_
one atom will be picked (whereas before this wasn't guaranteed).

Please note that I don't say your suggestion doesn't make sense: I
like automatic superposition programs that make sensible structural
assumptions and decisions (some LSQMAN commands or SSM in Coot). Just
that LSQKAB isn't really intended that way (it does exactly what it
says on the tin). If one would want such a feature (which would be
nice) it needs to be coded and controlled (on/off) with some
additional input cards I guess.

 ---

As a comparison, I've run a test with four PDB files:

  a) just 5 residues

  b) same 5 residues, but one side-chain has two alternate
 conformations (A and B)

  c) same 5 residues, but one residue has insertion code instead of
 residue number increment

  d) same 5 residues, but now with the alternate conformation
 side-chain and the insertion code residue

Running this against 4 LSQKAB binaries:

  A) LSQKAB sources from 6.0.2, compiled against 6.0.2 libraries

  B) LSQKAB sources from 6.0.2, compiled against 6.1.0 libraries

  C) LSQKAB sources from 6.1.0, compiled against 6.0.2 libraries

  D) LSQKAB sources from 6.1.0, compiled against 6.1.0 libraries

shows some interesting items (assuming that LSQKAB should match-up
only identical atoms, i.e. leaving your suggestion of automatic
decisions aside).

 - the 6.0.2 LSQKAB source shows non-zero RMS values in a variety of
   cases

   This makes no sense, since for any pair of the above PDB files the
   common atoms are identical.

 - the 6.0.2 LSQKAB source gives different results when swapping the
   two PDB files one superposes (i.e. superposing PDB1 onto PDB2 gives
   a different result thatn superposing PDB2 onto PDB1)

   Again, this doesn't make sense.

   Both of these points are due to the missing checks introduced into
   the latest version (which make sure that only identical atoms are
   picked).

 - the 6.0.1 LSQKAB source always gives rms values of zero and the
   order of PDB files doesn't matter.

To me the 6.1.0 sources look correct ... ?

Anyway, getting back to the original question (most people reading the
CCP4bb will be bored by now anyway):

 If I do the same superposition (with a pdb file that contains 
 alternative conformations) with LSQKAB version 6.0 and 6.1:
 1) Version 6.0 reports 110 atoms to be refined and does not report any 
 error or warning. The loggraph contains data for the residues with 
 alternative conformations.
 2) Version 6.1 reports 97 atoms to be refined, and it reports 13 atoms 
 as no match for workcd atom [...]. The loggraph does NOT contain data 
 for the residues with alternative conformations.
 
 Based on that, I have assumed that version 6.0 

Re: [ccp4bb] LSQKAB, version 6.0 vs version 6.1 - reposting (Sorry!)

[Borhani, David]

Hi Clemens,

Thanks for all your tests; the scripts/keywords you used to run LSQKAB
with these test systems would help to clarify what may be going right
vs. going wrong.

A few points that I hope may be helpful:

1. Atom names are 4 characters. If a true match is desired, all 4
characters (even the first one that is often a  ) must be compared.

2. I think the new code is not correct, as your examples show, and as
others have found in using the program. The logic, in those cases where
alt coded atoms are present, seems to be either wrong, unexpected, or
ill-defined (i.e., it matters which coord set is work vs. reference), or
perhaps even all of the above.

3. I agree that chain, residue number, and atom name do not by
themselves specify a unique atom; insertion code must also be used. Alt
code *may* be used, and that's where (IMHO) it gets tricky (and
apparently the older versions of LSQKAB just used an implicit logic
(i.e., likely matched the first found alt coded atom, without any
checks):
A. Option one, no defined logic: just ignore the alt code; use
any (random) atom you get (first).
B. Option two, defined logic (what that logic should be is the
key point to discuss, I think).

Rigid potential logic:
1. User must explicitly specify what will constitute a match.
Absent such a specification, program stops with
an error if alt coded atoms are found (or if they don't
meet the specification).
(I don't recommend this!)

Flexible (intelligent?) potential logic:
1. Match the atom without the alt code (i.e.,  ), if it
exists; else match an atom with an altcode.
2. Now matching alt codes:
A. Is there an atom with alt code A? Use it, else look
for B, C, etc., in sort order.
(FYI: documentation (6.0.2-03) says: If there
are two or more conformations, the first (labelled A) 
is chosen for comparison.)
B. ALTERNATIVELY, use the alt coded atom with the
highest occupancy; use sort order to 
resolve ties (A  B  C... [usually, one tries,
at least, to put the most significant 
atom as the   alt code or the A atom]).
(I prefer using occupancy instead of B factor, because once one is
modeling alt conformations, occupancy receives some conscious attention;
the B will then just refine to where it needs to be given the
user-assigned occupancy [unless one is refining occupancies in SHELX].
So, in most cases, I suspect, occupancy trumps B factor. Others may
disagree.)

There also may need to be a new keyword/keyvalue to allow the user to
specify which of several potential alternative logics to use.

4. It appears to me that the new version (6.1.0) doesn't have any
changes to the FIT/MATCH keywords to handle insertion codes. If the user
specifies, for example:
FIT RESIDU SIDE 155 TO 156 CHAIN A 
MATCH RESIDU 155 TO 156 CHAIN A
then IF there exists a residue 155A in the working coords, there must
also be a residue 155A in the ref coords, else error.

There are good reasons to allow users to alter this behavior, e.g.
fitting immunoglobulin hypervariable regions, which often have (a
variable number of) insertions. Current LSQKAB logic would appear to
make this task difficult. To be more explicit, if I want to fit residues
25-40, knowing that there is a variable loop, with insertion codes after
residue 30, i.e. I want to fit 25-30 and 31-40, it would be nice to be
able to specify 25-40 and SKIP INSERTIONS or something similar.

5. Finally, ensuring that whatever logic is chosen works no matter which
coordinate set is specified as work or reference would be highly
desireable, as your examples clearly point out!

Dave

P.S. - I'm not sure I understand the problem that Wangsa mentions, but
it may be related to the 3- vs. 4-character atom name match.

 -Original Message-
 From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On 
 Behalf Of Clemens Vonrhein
 Sent: Tuesday, December 23, 2008 9:33 AM
 To: CCP4BB@JISCMAIL.AC.UK
 Subject: Re: [ccp4bb] LSQKAB, version 6.0 vs version 6.1 - 
 reposting (Sorry!)
 
 Dear all,
 
 oops - due to some disk/network issues on my side, the final edits of
 my email got lost. Sorry for reposting this again (corrected):
 
 On Mon, Dec 22, 2008 at 02:58:31PM -0500, Borhani, David wrote:
  I think the LSQKAB change at Line 291(old)/Line 300(new) 
 DOES introduce
  new and possibly incorrect logic.
 
 Very possible, but ...
  
  I haven't looked at all the code, but this one change does seem to
  substitute a check that chain, residue number, and atom name (only 3
  characters; incorrect) match [OLD] for a check that chain, residue
  number, atom name (4 chars, correct), insertion code 
 (correct, assuming
  that the insertion codes and residues numbers in the two 
 proteins are
  lined up correctly), AND ALT CODE match [NEW].
 
 I read that slightly differently:
 
 OLD: check

Re: [ccp4bb] LSQKAB, version 6.0 vs version 6.1 - reposting (Sorry!)

[Clemens Vonrhein]

Hi David,

On Tue, Dec 23, 2008 at 10:31:28AM -0500, Borhani, David wrote:
 Hi Clemens,
 
 Thanks for all your tests; the scripts/keywords you used to run LSQKAB
 with these test systems would help to clarify what may be going right
 vs. going wrong.

That was just a simple run with

  lsqkab workcd work.pdb refrcd ref.pdb EOF
  FIT RESI ALL 1 TO 5
  MATCH 1 TO 5
  EOF

 A few points that I hope may be helpful:
 
 1. Atom names are 4 characters. If a true match is desired, all 4
 characters (even the first one that is often a  ) must be compared.

I agree: the 3-character test is not something I'm involved with at
all. This is what LSQKAB is doing - and I _think_ it has to do partly
with MMDB (which does some shifting as far as I can remember).
 
 2. I think the new code is not correct, as your examples show, and as
 others have found in using the program. The logic, in those cases where
 alt coded atoms are present, seems to be either wrong, unexpected, or
 ill-defined (i.e., it matters which coord set is work vs. reference), or
 perhaps even all of the above.

Maybe my email wasn't quite clear: e.g. the problem with which coord
set is work vs. reference happens in the OLD code (CCP3 6.0.2) and is
fixed in the NEW code (6.1). All the unexpected behaviour is present
in the old 6.0.2 version of LSQKAB - the 6.1 version is fixed and
behaves as expected.

The original problem reported was that the output seems to suggest
that LSQKAB was using AltConf atoms in the superposition. And so it
was: but it did it wrongly (i.e. it mattered which PDB file was
defined as reference and which as work). The new code fixes that - but
if you want a feature like

  match up with AltConf A in case one PDB has no AltConf and the
  other has

then this needs to be newly introduced into LSQKAB: it never was in
there and the impression that it might have worked like that in the
old version was due to some wrong logic introducing this random
behaviour.

 3. I agree that chain, residue number, and atom name do not by
 themselves specify a unique atom; insertion code must also be used. Alt
 code *may* be used, and that's where (IMHO) it gets tricky (and
 apparently the older versions of LSQKAB just used an implicit logic
 (i.e., likely matched the first found alt coded atom, without any
 checks):
   A. Option one, no defined logic: just ignore the alt code; use
 any (random) atom you get (first).

Yes, that is 6.0.2 behaviour.

   B. Option two, defined logic (what that logic should be is the
 key point to discuss, I think).

Yes, that is 6.1 behaviour: exact matching. But yes: there should be
some better message (one can deduce this from the number of atoms in
the working set compared to the number of atoms used - printed just
above the RMS message).

 Rigid potential logic:
   1. User must explicitly specify what will constitute a match.
 Absent such a specification, program stops with
   an error if alt coded atoms are found (or if they don't
 meet the specification).
 (I don't recommend this!)
 
 Flexible (intelligent?) potential logic:
   1. Match the atom without the alt code (i.e.,  ), if it
 exists; else match an atom with an altcode.
   2. Now matching alt codes:
   A. Is there an atom with alt code A? Use it, else look
 for B, C, etc., in sort order.
   (FYI: documentation (6.0.2-03) says: If there
 are two or more conformations, the first (labelled A) 
   is chosen for comparison.)

Ah: that might have been true for pre-mmdb coordinate library use (but
even then it might have depended on the way the PDB file was
written). But with mmdb (as far as I understand) the atoms might be
stored in a different (random?) order.

   B. ALTERNATIVELY, use the alt coded atom with the
 highest occupancy; use sort order to 
   resolve ties (A  B  C... [usually, one tries,
 at least, to put the most significant 
   atom as the   alt code or the A atom]).
 (I prefer using occupancy instead of B factor, because once one is
 modeling alt conformations, occupancy receives some conscious attention;
 the B will then just refine to where it needs to be given the
 user-assigned occupancy [unless one is refining occupancies in SHELX].
 So, in most cases, I suspect, occupancy trumps B factor. Others may
 disagree.)

That would be the nicest way.

 There also may need to be a new keyword/keyvalue to allow the user to
 specify which of several potential alternative logics to use.
 
 4. It appears to me that the new version (6.1.0) doesn't have any
 changes to the FIT/MATCH keywords to handle insertion codes. If the user
 specifies, for example:
   FIT RESIDU SIDE 155 TO 156 CHAIN A 
   MATCH RESIDU 155 TO 156 CHAIN A
 then IF there exists a residue 155A in the working coords, there must
 also be a residue 155A in the ref coords, else error.

Possible: I'm not sure how the sequence 155 TO 156 is 

[ccp4bb] LSQKAB, version 6.0 vs version 6.1

[Jose M de Pereda]

Dear colleagues,

While using LSQKAB I have encountered what it seems a different behavior 
between version 6.1 and 6.0.


If I superpose two structures with LSQKAB version 6.1 (included in 
CCP4-6.1.0), residues with alternative conformations are not included 
for the calculations. This is an example of the message in the log file:


  - NO MATCH FOR WORKCD ATOM -   995CA  A IN REFRCD FILE
  - NO MATCH FOR WORKCD ATOM -   995CA  A IN REFRCD FILE
  - NO MATCH FOR WORKCD ATOM -  1009CA  A IN REFRCD FILE
  - NO MATCH FOR WORKCD ATOM -  1009CA  A IN REFRCD FILE

The program completes the task normally, but it does not use the 
residues with alternative conformations.


In contrast, LSQKAB version 6.0 (included in CCP4-6.0.2) uses the 
residues with alternative conformations.


The documentation of LSQKAB does not have any reference about the 
treatment of residues with alternative conformations.


This problem is not specific to a particular coordinates file. For 
example, I can reproduce it using PDB entry 1QG3 and superposing 
residues 1127-1318 of molecule A onto the same range of molecule B.


I would appreciate if someone could enlighten me whether this is a new 
FEATURE of ver 6.1 or a BUG; and how can this be avoided (i.e. include 
residues with alternative conformations for calculations).


Finally, I am running CCP4 6.1.0 in a Linux box with Suse 10.2 (Linux 
2.6.18.8-0.10-default i686).


Happy holidays and happy New Year
Cheers

 Jose

--

Jose M de Pereda, PhD
Instituto de Biologia Molecular y Celular del Cancer (IBMCC)
Spanish National Research Council - University of Salamanca
Campus Unamuno s/n
E-37007 Salamanca, Spain
Phone:  +34-923-294819
Fax:+34-923-294795
http://xtal.cicancer.org/

Re: [ccp4bb] LSQKAB, version 6.0 vs version 6.1

[Jose M de Pereda]

Hi Tim,

Not a stupid question at all.  This is how I came to think that version 
6.0 uses atoms with alternative conformations:


If I do the same superposition (with a pdb file that contains 
alternative conformations) with LSQKAB version 6.0 and 6.1:
1) Version 6.0 reports 110 atoms to be refined and does not report any 
error or warning. The loggraph contains data for the residues with 
alternative conformations.
2) Version 6.1 reports 97 atoms to be refined, and it reports 13 atoms 
as no match for workcd atom [...]. The loggraph does NOT contain data 
for the residues with alternative conformations.


Based on that, I have assumed that version 6.0 does include atoms in 
alternative conformations (in fact, it seems to take into account each 
conformations independently).


Bye
 Jose

On 12/22/2008 4:31 PM Tim Gruene wrote:
Not using lsqkab very often, this might be a stupid question: How do 
you know that version 6.0 _DOES_ include multiple conformations? Maybe 
it only does not report their omission?


Tim

--
Tim Gruene
Institut fuer anorganische Chemie
Tammannstr. 4
D-37077 Goettingen

GPG Key ID = A46BEE1A


On Mon, 22 Dec 2008, Jose M de Pereda wrote:


Dear colleagues,

While using LSQKAB I have encountered what it seems a different 
behavior between version 6.1 and 6.0.


If I superpose two structures with LSQKAB version 6.1 (included in 
CCP4-6.1.0), residues with alternative conformations are not included 
for the calculations. This is an example of the message in the log file:


 - NO MATCH FOR WORKCD ATOM -   995CA  A IN REFRCD FILE
 - NO MATCH FOR WORKCD ATOM -   995CA  A IN REFRCD FILE
 - NO MATCH FOR WORKCD ATOM -  1009CA  A IN REFRCD FILE
 - NO MATCH FOR WORKCD ATOM -  1009CA  A IN REFRCD FILE

The program completes the task normally, but it does not use the 
residues with alternative conformations.


In contrast, LSQKAB version 6.0 (included in CCP4-6.0.2) uses the 
residues with alternative conformations.


The documentation of LSQKAB does not have any reference about the 
treatment of residues with alternative conformations.


This problem is not specific to a particular coordinates file. For 
example, I can reproduce it using PDB entry 1QG3 and superposing 
residues 1127-1318 of molecule A onto the same range of molecule B.


I would appreciate if someone could enlighten me whether this is a 
new FEATURE of ver 6.1 or a BUG; and how can this be avoided (i.e. 
include residues with alternative conformations for calculations).


Finally, I am running CCP4 6.1.0 in a Linux box with Suse 10.2 (Linux 
2.6.18.8-0.10-default i686).


Happy holidays and happy New Year
Cheers

Jose

--

Jose M de Pereda, PhD
Instituto de Biologia Molecular y Celular del Cancer (IBMCC)
Spanish National Research Council - University of Salamanca
Campus Unamuno s/n
E-37007 Salamanca, Spain
Phone:  +34-923-294819
Fax:+34-923-294795
http://xtal.cicancer.org/






--

Jose M de Pereda, PhD
Instituto de Biologia Molecular y Celular del Cancer (IBMCC)
Spanish National Research Council - University of Salamanca
Campus Unamuno s/n
E-37007 Salamanca, Spain
Phone:  +34-923-294819
Fax:+34-923-294795
http://xtal.cicancer.org/

Re: [ccp4bb] LSQKAB, version 6.0 vs version 6.1

[Borhani, David]

I think the LSQKAB change at Line 291(old)/Line 300(new) DOES introduce
new and possibly incorrect logic.

I haven't looked at all the code, but this one change does seem to
substitute a check that chain, residue number, and atom name (only 3
characters; incorrect) match [OLD] for a check that chain, residue
number, atom name (4 chars, correct), insertion code (correct, assuming
that the insertion codes and residues numbers in the two proteins are
lined up correctly), AND ALT CODE match [NEW].

The alt code match is, I suspect, a bug, in exactly the situation that
Jose provided: one protein may have them, but the other may not (or may
have different ones). One should perform the alignment such that the
protein (residue) without alt codes aligns onto the other protein
(residue) with the A alt code; to discard the residue pair is simply
because alt codes don't match is not correct. [I don't want to start a
discussion on whether instead the program should use that alt code with
the highest occupancy, though that also should be fine; if occs are
equal, then pick A.)

Dave

David Borhani, Ph.D.
D. E. Shaw Research, LLC
120 West Forty-Fifth Street, 39th Floor
New York, NY 10036
david.borh...@deshawresearch.com
212-478-0698
http://www.deshawresearch.com

 -Original Message-
 From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On 
 Behalf Of Kevin Cowtan
 Sent: Monday, December 22, 2008 11:39 AM
 To: CCP4BB@JISCMAIL.AC.UK
 Subject: Re: [ccp4bb] LSQKAB, version 6.0 vs version 6.1
 
 In case it helps, you can see the diffs between the 6.0.2 version and 
 the 6.1 version here:
 
 http://www.ccp4.ac.uk/ccp4bin/viewcvs/ccp4/src/lsqkab.f.diff?r
 1=texttr1=1.51r2=texttr2=1.42.2.2diff_format=h
 
 The obvious changes seem to be some code from Clemens to make 
 sure that 
 insertion codes match. I can't see anything obviously wrong with that 
 code though.
 
 Jose M de Pereda wrote:
  Hi Tim,
  
  Not a stupid question at all.  This is how I came to think 
 that version 
  6.0 uses atoms with alternative conformations:
  
  If I do the same superposition (with a pdb file that contains 
  alternative conformations) with LSQKAB version 6.0 and 6.1:
  1) Version 6.0 reports 110 atoms to be refined and does 
 not report any 
  error or warning. The loggraph contains data for the residues with 
  alternative conformations.
  2) Version 6.1 reports 97 atoms to be refined, and it 
 reports 13 atoms 
  as no match for workcd atom [...]. The loggraph does NOT 
 contain data 
  for the residues with alternative conformations.
  
  Based on that, I have assumed that version 6.0 does include 
 atoms in 
  alternative conformations (in fact, it seems to take into 
 account each 
  conformations independently).
  
  Bye
   Jose
  
  On 12/22/2008 4:31 PM Tim Gruene wrote:
  Not using lsqkab very often, this might be a stupid 
 question: How do 
  you know that version 6.0 _DOES_ include multiple 
 conformations? Maybe 
  it only does not report their omission?
 
  Tim
 
  -- 
  Tim Gruene
  Institut fuer anorganische Chemie
  Tammannstr. 4
  D-37077 Goettingen
 
  GPG Key ID = A46BEE1A
 
 
  On Mon, 22 Dec 2008, Jose M de Pereda wrote:
 
  Dear colleagues,
 
  While using LSQKAB I have encountered what it seems a different 
  behavior between version 6.1 and 6.0.
 
  If I superpose two structures with LSQKAB version 6.1 
 (included in 
  CCP4-6.1.0), residues with alternative conformations are 
 not included 
  for the calculations. This is an example of the message 
 in the log file:
 
   - NO MATCH FOR WORKCD ATOM -   995CA  A IN REFRCD FILE
   - NO MATCH FOR WORKCD ATOM -   995CA  A IN REFRCD FILE
   - NO MATCH FOR WORKCD ATOM -  1009CA  A IN REFRCD FILE
   - NO MATCH FOR WORKCD ATOM -  1009CA  A IN REFRCD FILE
 
  The program completes the task normally, but it does not use the 
  residues with alternative conformations.
 
  In contrast, LSQKAB version 6.0 (included in CCP4-6.0.2) uses the 
  residues with alternative conformations.
 
  The documentation of LSQKAB does not have any reference about the 
  treatment of residues with alternative conformations.
 
  This problem is not specific to a particular coordinates 
 file. For 
  example, I can reproduce it using PDB entry 1QG3 and superposing 
  residues 1127-1318 of molecule A onto the same range of 
 molecule B.
 
  I would appreciate if someone could enlighten me whether 
 this is a 
  new FEATURE of ver 6.1 or a BUG; and how can this be 
 avoided (i.e. 
  include residues with alternative conformations for calculations).
 
  Finally, I am running CCP4 6.1.0 in a Linux box with Suse 
 10.2 (Linux 
  2.6.18.8-0.10-default i686).
 
  Happy holidays and happy New Year
  Cheers
 
  Jose
 
  -- 
  
  Jose M de Pereda, PhD
  Instituto de Biologia Molecular y Celular del Cancer (IBMCC)
  Spanish National Research Council - University of Salamanca
  Campus Unamuno s/n
  E-37007 Salamanca, Spain
  Phone:  +34-923

[ccp4bb] lsqkab

[Nathalie Colloc'h]

Hi everybody,

I wonder why in lsqkab, the glycine residues have a rms value for their 
side chains which are non null
(the same calculation done with CNS give about the same results for the 
rms calculation, but with

null value for the rms of glycine side chains).

thanks a lot

nathalie

--
Dr. Nathalie Colloc'h, PhD
CI-NAPS, UMR 6232 - UCBN - CNRS
GIP Cyceron
Bd Becquerel, BP5229
14074 Caen cedex
FRANCE
Tel. 33.2.31.47.01.32
Fax. 33.2.31.47.02.22
[EMAIL PROTECTED]