Re: [ccp4bb] Sftools and Phaser compatibility issues - continued Summary

2010-09-03 Thread Herman . Schreuder 
Dear Bulletin Board,

Thank you very much for the information and comments. In the last days I have 
learned a lot and it has been very helpful. It turned out that at the basis my 
problems were the fact that sftools was not up to date and that I had been 
looking in the wrong places for space group names:

Intl tables vol A for space group information -> should be intl tables vol G 
(see below)
Symop.lib for ccp4 symmetry information -> should be syminf.lib

Syminf.lib indeed seems to contain all information needed: four different names 
for space groups: "ccp4", "Hall", "xHM" and "old", where "old" seems to 
correspond to the PDB definition and "xHM" to the definition used by phaser. 
Since I was trying to fix the space group name for a process (autobuster) which 
was also using sftools, one starts going around in circles. Knowing this, I 
went back to cad and this program did indeed correctly replace the space group 
name "R 3 :H" by "H 3", so I assume that all ccp4 programs which use the 
official subroutines will correctly recognize alternative names for space 
groups.

Best regards,
Herman
 

-Original Message-
From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Miller, 
Mitchell D.
Sent: Thursday, September 02, 2010 6:31 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Sftools and Phaser compatibility issues - continued

FYI --

The :h suffix for R3 is described in the IUCr symmetry cif (intl tables vol G 
chapter 4.7) under _space_group.reference_setting where it states "For the 
space groups where more than one setting is given in International Tables, the 
following choices have been made. For monoclinic space groups: unique axis b 
and cell choice 1. For space groups with two origins: origin choice 2 (origin 
at inversion centre, indicated by adding :2 to the Hermann-Mauguin symbol in 
the enumeration list). For rhombohedral space groups: hexagonal axes (indicated 
by adding :h to the Hermann-Mauguin symbol in the enumeration list)."

http://it.iucr.org/Ga/ch4o7v0001/ch4o7.pdf
http://www.iucr.org/resources/cif/dictionaries/cif_sym 

The H3 / H32 designations are PDB conventions/standards. In the PDB format 
description it states that "For a rhombohedral space group in the hexagonal 
setting, the lattice type symbol used is H."  
>From an archive of the PDB documentation at the University of Washington, 
>there is list of changes by PDB version that suggests that the PDB introduced 
>the H designation with the release of PDB format v2.0 (sometime around March 
>1997) see 
>http://www.bmsc.washington.edu/CrystaLinks/man/pdb/guide2.2_frame.html
http://www.bmsc.washington.edu/CrystaLinks/man/pdb/part_6.html
The RCSB's archive of the 2.2 format gives a file not found error.
http://www.rcsb.org/pdb/docs/format/pdbguide2.2/guide2.2_frame.html 
 

Regards,
Mitch


-Original Message--
From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Nat Echols
Sent: Thursday, September 02, 2010 8:06 AM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Sftools and Phaser compatibility issues - continued

On Thu, Sep 2, 2010 at 5:31 AM,  wrote:
The other question is: why does phaser write 'R 3 :H' in the mtz? When the 
problem with the P21221 space group first popped up last year, Randy told me 
that space group numbers like 2018 are non-standard, and that space group 18 
with the name P21221 was the way to go. This is fair enough, but 'R 3 :H' is 
neither PDB nor ccp4 standard and I did not find it in the international 
tables. Is it maybe a phenix standard?

No, it pre-dates Phenix - it's the "extended Hermann Mauguin symbol", whatever 
that means:

http://www.ccp4.ac.uk/html/symmetry.html

I don't know why it's used preferentially in Phenix, but in theory it's 
supported by CCP4 programs, except those which are still using the older 
symmetry information.  syminfo.lib has the correct information (space group 
number 146), symop.lib does not.  As previously noted the last time this 
discussion came up (December, if memory serves), Coot also uses this notation:

http://www.biop.ox.ac.uk/coot/doc/coot/Reading-coordinates.html

-Nat

Re: [ccp4bb] Sftools and Phaser compatibility issues - continued

2010-09-02 Thread Miller, Mitchell D. 
FYI --

The :h suffix for R3 is described in the IUCr symmetry cif (intl tables vol G 
chapter 4.7) under _space_group.reference_setting where it states "For the
space groups where more than one setting is given in International
Tables, the following choices have been made. For monoclinic
space groups: unique axis b and cell choice 1. For space
groups with two origins: origin choice 2 (origin at inversion centre,
indicated by adding :2 to the Hermann-Mauguin symbol in
the enumeration list). For rhombohedral space groups: hexagonal
axes (indicated by adding :h to the Hermann-Mauguin symbol
in the enumeration list)."

http://it.iucr.org/Ga/ch4o7v0001/ch4o7.pdf 
http://www.iucr.org/resources/cif/dictionaries/cif_sym 

The H3 / H32 designations are PDB conventions/standards. In the PDB
format description it states that "For a rhombohedral space group in 
the hexagonal setting, the lattice type symbol used is H."  
>From an archive of the PDB documentation at the University of Washington,
there is list of changes by PDB version that suggests that the PDB
introduced the H designation with the release of PDB format v2.0 
(sometime around March 1997) see
http://www.bmsc.washington.edu/CrystaLinks/man/pdb/guide2.2_frame.html 
http://www.bmsc.washington.edu/CrystaLinks/man/pdb/part_6.html 
The RCSB's archive of the 2.2 format gives a file not found error.
http://www.rcsb.org/pdb/docs/format/pdbguide2.2/guide2.2_frame.html 
 

Regards,
Mitch


-Original Message--
From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Nat Echols
Sent: Thursday, September 02, 2010 8:06 AM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Sftools and Phaser compatibility issues - continued

On Thu, Sep 2, 2010 at 5:31 AM,  wrote:
The other question is: why does phaser write 'R 3 :H' in the mtz? When
the problem with the P21221 space group first popped up last year, Randy
told me that space group numbers like 2018 are non-standard, and that
space group 18 with the name P21221 was the way to go. This is fair
enough, but 'R 3 :H' is neither PDB nor ccp4 standard and I did not find
it in the international tables. Is it maybe a phenix standard?

No, it pre-dates Phenix - it's the "extended Hermann Mauguin symbol", whatever 
that means:

http://www.ccp4.ac.uk/html/symmetry.html

I don't know why it's used preferentially in Phenix, but in theory it's 
supported by CCP4 programs, except those which are still using the older 
symmetry information.  syminfo.lib has the correct information (space group 
number 146), symop.lib does not.  As previously noted the last time this 
discussion came up (December, if memory serves), Coot also uses this notation:

http://www.biop.ox.ac.uk/coot/doc/coot/Reading-coordinates.html

-Nat

Re: [ccp4bb] Sftools and Phaser compatibility issues - continued

2010-09-02 Thread Kevin Cowtan 
Well, CCP4 programs using the core libraries should ignore the 
spacegroup symbol and use the operators instead, which bypasses the 
whole problem. I would advise anyone using the CCP4 libraries in their 
own programs to do the same.


That works for mtz and map, but not for pdb files of course.

Kevin

Nat Echols wrote:
  On Thu, Sep 2, 2010 at 5:31 AM,  > wrote:


The other question is: why does phaser write 'R 3 :H' in the mtz? When
the problem with the P21221 space group first popped up last year, Randy
told me that space group numbers like 2018 are non-standard, and that
space group 18 with the name P21221 was the way to go. This is fair
enough, but 'R 3 :H' is neither PDB nor ccp4 standard and I did not find
it in the international tables. Is it maybe a phenix standard?


No, it pre-dates Phenix - it's the " extended Hermann Mauguin symbol", 
whatever that means:


http://www.ccp4.ac.uk/html/symmetry.html

I don't know why it's used preferentially in Phenix, but in theory it's 
supported by CCP4 programs, except those which are still using the older 
symmetry information.  syminfo.lib has the correct information (space 
group number 146), symop.lib does not.  As previously noted the last 
time this discussion came up (December, if memory serves), Coot also 
uses this notation:


http://www.biop.ox.ac.uk/coot/doc/coot/Reading-coordinates.html

-Nat



--
EMAIL DISCLAIMER http://www.york.ac.uk/docs/disclaimer/email.htm

Re: [ccp4bb] Sftools and Phaser compatibility issues - continued

2010-09-02 Thread Nat Echols 
On Thu, Sep 2, 2010 at 5:31 AM,  wrote:

> The other question is: why does phaser write 'R 3 :H' in the mtz? When
> the problem with the P21221 space group first popped up last year, Randy
> told me that space group numbers like 2018 are non-standard, and that
> space group 18 with the name P21221 was the way to go. This is fair
> enough, but 'R 3 :H' is neither PDB nor ccp4 standard and I did not find
> it in the international tables. Is it maybe a phenix standard?
>

No, it pre-dates Phenix - it's the "extended Hermann Mauguin symbol",
whatever that means:

http://www.ccp4.ac.uk/html/symmetry.html

I don't know why it's used preferentially in Phenix, but in theory it's
supported by CCP4 programs, except those which are still using the older
symmetry information.  syminfo.lib has the correct information (space group
number 146), symop.lib does not.  As previously noted the last time this
discussion came up (December, if memory serves), Coot also uses this
notation:

http://www.biop.ox.ac.uk/coot/doc/coot/Reading-coordinates.html

-Nat

Re: [ccp4bb] Sftools and Phaser compatibility issues - continued

2010-09-02 Thread Herman . Schreuder 
Dear Phil,

CAD would also be an excellent alternative. I used REINDEX which also
worked. The point I tried to make is that if people do not know that
SFTOOLS is not up to date, they may use it in good faith and get into
trouble. If they know it, they might use it to hack an mtz file when
neccessary, but use other program for more serious purposes.

Herman


-Original Message-
From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of
Phil Evans
Sent: Thursday, September 02, 2010 3:02 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Sftools and Phaser compatibility issues -
continued

I'm sure it would be a good thing if SFTOOLS recognised all possible
space groups, but I wonder why you are using SFTOOLS at all. I've almost
never had the need to use it myself. Space group changes and many other
things can be done with CAD for example

Phil


On 2 Sep 2010, at 13:31, herman.schreu...@sanofi-aventis.com wrote:

> Dear bulletin board,
> 
> After downloading and recompiling the complete CCP4 package (we had 
> the precompiled 32bits version on our 64bits machines) we were able to

> apply the patches of Claus and the problem case P21221 went through 
> without problems.
> 
> However, with the next problem case tested, things immediately went 
> wrong again. The space group was R3 and phaser had written the 
> following space group information in the mtz file: 146  'R 3 :H'. 
> Attempts to change the space group with sftools to 'H 3' failed 
> because sftools does not know 'H 3'. Resetting the space group 146 
> with sftools was successful, however, the name written in the mtz was 
> R3. This prompted autobuster to try to reset the spacegroup to 'H 3' 
> using sftools (with the results described above).
> 
> I did a quick comparison of the space groups implemented in sftools 
> and the CCP4 library, I found the following discrepancies and there 
> are probably more:
> 
> SFTOOLS   CCP4 
> number  name  number   namecomment
>  -3P112   1003P112different space group numbers
>  -4P1121  1004P1121   different space group numbers
>  -5 A112  ?? not present in CCP4, probably
> 2005: A2
>  146 R3146  H3different setting
>   1146  R3146 setting of SFTOOLS
> -146R3R
> 1146R3R   different entries with the same name
> -155R32R  different entries with the same name
> 1155R32R  1155 R32different name
> All non-chiral and origin shifted space groups are missing from
SFTOOLS.
> 
> As Bart told us, sftools was made to ease the transition from the 
> groningen biomol package to ccp4 and he added a lot of options to 
> manipulate the reflection data. I find this options very useful e.g. 
> to simulate the effects of lattice translocation disorder. In a 
> private mail, Bart told me that he has currently little time to 
> maintain sftools and since the program does all he needs, there is 
> little incentive for him to put a lot of time in it.
> 
> This leaves me, and probably many other ccp4 users, with the problem 
> that sftools may produce incompatible mtz files, especially in problem

> and non-standard settings. These are exactly the cases where one would

> use a program like sftools. In my opinion, either sftools should be 
> fixed to use the ccp4 library (they really did a wonderful job to 
> implement all space groups and all settings!), or sftools should be 
> labeled an unsupported program to be used at ones own risk. For 
> general scripts like autobuster, one should then probably switch to 
> supported programs. E.g. I solved the R3/H3 problem by using the 
> reindex program to change the space group.
> 
> The other question is: why does phaser write 'R 3 :H' in the mtz? When

> the problem with the P21221 space group first popped up last year, 
> Randy told me that space group numbers like 2018 are non-standard, and

> that space group 18 with the name P21221 was the way to go. This is 
> fair enough, but 'R 3 :H' is neither PDB nor ccp4 standard and I did 
> not find it in the international tables. Is it maybe a phenix
standard?
> 
> Best regards,
> Herman
> 
> -Original Message-
> From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of 
> Bart Hazes
> Sent: Wednesday, September 01, 2010 5:03 PM
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] Sftools can not handle non-standard settings?
> 
> Hi Herman,
> 
> As a former biomol user you might have guessed why. SFTOOLS found its 
> origin as a transitional program helping the Groningen group move to 
> the
> CCP4 mtz format. Since the Gro

Re: [ccp4bb] Sftools and Phaser compatibility issues - continued

2010-09-02 Thread Phil Evans 
I'm sure it would be a good thing if SFTOOLS recognised all possible space 
groups, but I wonder why you are using SFTOOLS at all. I've almost never had 
the need to use it myself. Space group changes and many other things can be 
done with CAD for example

Phil


On 2 Sep 2010, at 13:31, herman.schreu...@sanofi-aventis.com wrote:

> Dear bulletin board,
> 
> After downloading and recompiling the complete CCP4 package (we had the
> precompiled 32bits version on our 64bits machines) we were able to apply
> the patches of Claus and the problem case P21221 went through without
> problems. 
> 
> However, with the next problem case tested, things immediately went
> wrong again. The space group was R3 and phaser had written the following
> space group information in the mtz file: 146  'R 3 :H'. Attempts to
> change the space group with sftools to 'H 3' failed because sftools does
> not know 'H 3'. Resetting the space group 146 with sftools was
> successful, however, the name written in the mtz was R3. This prompted
> autobuster to try to reset the spacegroup to 'H 3' using sftools (with
> the results described above).
> 
> I did a quick comparison of the space groups implemented in sftools and
> the CCP4 library, I found the following discrepancies and there are
> probably more:
> 
> SFTOOLS   CCP4 
> number  name  number   namecomment
>  -3P112   1003P112different space group numbers
>  -4P1121  1004P1121   different space group numbers
>  -5 A112  ?? not present in CCP4, probably
> 2005: A2
>  146 R3146  H3different setting
>   1146  R3146 setting of SFTOOLS
> -146R3R
> 1146R3R   different entries with the same name
> -155R32R  different entries with the same name
> 1155R32R  1155 R32different name
> All non-chiral and origin shifted space groups are missing from SFTOOLS.
> 
> As Bart told us, sftools was made to ease the transition from the
> groningen biomol package to ccp4 and he added a lot of options to
> manipulate the reflection data. I find this options very useful e.g. to
> simulate the effects of lattice translocation disorder. In a private
> mail, Bart told me that he has currently little time to maintain sftools
> and since the program does all he needs, there is little incentive for
> him to put a lot of time in it.
> 
> This leaves me, and probably many other ccp4 users, with the problem
> that sftools may produce incompatible mtz files, especially in problem
> and non-standard settings. These are exactly the cases where one would
> use a program like sftools. In my opinion, either sftools should be
> fixed to use the ccp4 library (they really did a wonderful job to
> implement all space groups and all settings!), or sftools should be
> labeled an unsupported program to be used at ones own risk. For general
> scripts like autobuster, one should then probably switch to supported
> programs. E.g. I solved the R3/H3 problem by using the reindex program
> to change the space group.
> 
> The other question is: why does phaser write 'R 3 :H' in the mtz? When
> the problem with the P21221 space group first popped up last year, Randy
> told me that space group numbers like 2018 are non-standard, and that
> space group 18 with the name P21221 was the way to go. This is fair
> enough, but 'R 3 :H' is neither PDB nor ccp4 standard and I did not find
> it in the international tables. Is it maybe a phenix standard? 
> 
> Best regards,
> Herman
> 
> -Original Message-
> From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of
> Bart Hazes
> Sent: Wednesday, September 01, 2010 5:03 PM
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] Sftools can not handle non-standard settings?
> 
> Hi Herman,
> 
> As a former biomol user you might have guessed why. SFTOOLS found its
> origin as a transitional program helping the Groningen group move to the
> CCP4 mtz format. Since the Groningen MDF and CCP4 mtz had different
> ideas about space group symmetry and, especially, asymmetric unit
> definitions SFTOOLS needed to handle both. Since the biomol space group
> routine was basically a very large spaghetti of nested if-then-elses to
> accommodate all the peculiar choices I chose to reimplement using a
> simple set of symmetry generators and a matrix to define the asymmetric
> unit.
> 
> Since there is no longer need to support MDF, sftools could switch to
> use the ccp4 library but my code is used for many other things,
> determining if a reflection is (a)centric, on a symmetry axis, should be
> systematically absent, expected intensity, convertion to standard
> asymmetric unit etc. So this will be a major undertaking. Alternatively,
> you can create a list of symmetry generators and add space groups as
> Claus has apparently already done.
> 
> Bart
> 
> On 10-09-01 05:39 AM, herman.schreu...@sanofi-aventis.com