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 name comment > -3 P112 1003 P112 different space group numbers > -4 P1121 1004 P1121 different space group numbers > -5 A112 ?? not present in CCP4, probably > 2005: A2 > 146 R3 146 H3 different setting > 1146 R3 146 setting of SFTOOLS > -146 R3R > 1146 R3R different entries with the same name > -155 R32R different entries with the same name > 1155 R32R 1155 R32 different 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 wrote: >> Dear Claus, >> >> Thank you very much for this patch. We will install it, and I hope >> CCP4 will install it quickly as well ;-). Still I do not understand >> why sftools has all symmetry operations hardcoded, while most other >> programs use the CCP4 libraries. In that way, sftools would always be >> up to date and would not need to be patched. >> >> Best, >> Herman >> >> -----Original Message----- >> From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of >> Claus Flensburg >> Sent: Wednesday, September 01, 2010 1:18 PM >> To: CCP4BB@JISCMAIL.AC.UK >> Subject: Re: [ccp4bb] Sftools can not handle non-standard settings? >> >> Dear Herman, >> >> please find attached a patch for sftools that will add support for >> the > >> following non-standard space group settings: >> >> A2, C21, I21, P2122, P2212, P21221, P22121 >> >> Note: the number for I21 follows the upcomming change to >> syminfo.lib: 3004 -> 5005. >> >> diffstat -p0< >> CCP4-20091104-src-sftools_-sftools.f-Add-some-non-standard-spgrps-v1. >> p >> at >> ch >> src/sftools_/sftools.f | 52 >> ++++++++++++++++++++++++++++++++----------------- >> 1 files changed, 35 insertions(+), 17 deletions(-) >> >> The patch applies equally well to series-6_1 and trunk. >> >> >> Regards, >> >> ClAuS >> >> P.S. After applying the patch and compiling sftools, you can use it >> in > >> BUSTER with this command line option: >> >> % refine autoBUSTER_Exe_sftools=/path/to/patched-sftools/sftools ... >> >> On Wed, Sep 01, 2010 at 12:29:55PM +0200, >> herman.schreu...@sanofi-aventis.com wrote: >> >>> Dear CCP4, >>> >>> In our automated data processing and refinement pipeline, phaser >>> sometimes comes up with solutions in non-standard settings (e.g. P >>> 21 >>> 2 21). These solutions subsequently fail in autobuster and it turned >>> out that this is because autobuster invokes sftools and sftools >>> apparently is not able to handle non-standard settings. >>> >>> I am really puzzled. We upgraded to the latest CCP4 version (6.1.13) >>> and the symmetry libraries have P 21 2 21 (space group 2018) in them. >>> Other programs like reindex and coot handle this setting without any >>> >> problems. >> >>> Is sftools still supported by ccp4, or should we ask the buster >>> people >>> >> >>> to switch to some other program? >>> >>> Thank you for your help, >>> Herman Schreuder >>> >> > > -- > > ====================================================================== > == > ==== > > Bart Hazes (Associate Professor) > Dept. of Medical Microbiology& Immunology University of Alberta > 1-15 Medical Sciences Building > Edmonton, Alberta > Canada, T6G 2H7 > phone: 1-780-492-0042 > fax: 1-780-492-7521 > > ====================================================================== > == > ====
