[ccp4bb] Regarding BMCD
Dear all, I have bee trying to access the biomolecular crystallization database BMCD for quite sometime now, no matter which route I access it through the page shows an error as the server can not be contacted. I would like to know whether its a problem only I am coming across.Moreover, is there any registration or license required to access BMCD? if there is, I am not aware of it. Your help will be appreciated. Regards Nishant NISHANTÂ KUMAR VARSHNEY C/O Dr. C.G. Suresh, Biochemical Sciences Division, National Chemical Laboratory, Pune-411008, Maharastra, India. Explore and discover exciting holidays and getaways with Yahoo! India Travel http://in.travel.yahoo.com/
Re: [ccp4bb] Regarding BMCD
Have you tried: http://xpdb.nist.gov:8060/BMCD4/index.faces It works for me. David Nishant Varshney wrote: Dear all, I have bee trying to access the biomolecular crystallization database BMCD for quite sometime now, no matter which route I access it through the page shows an error as the server can not be contacted. I would like to know whether its a problem only I am coming across.Moreover, is there any registration or license required to access BMCD? if there is, I am not aware of it. Your help will be appreciated. Regards Nishant /NISHANT KUMAR VARSHNEY/ /C/O Dr. C.G. Suresh,/ /Biochemical Sciences Division,/ /National Chemical Laboratory,/ /Pune-411008, Maharastra,/ /India./ Share files, take polls, and make new friends - all under one roof. Click here. http://in.rd.yahoo..com/tagline_groups_8/*http://in.promos.yahoo.com/groups/ -- David Cobessi Institut de Biologie Structurale 41, Rue Jules Horowitz 38027 Grenoble Cedex-1, France Tel:33(0)438789613 33(0)608164340 Fax:33(0)438785122
Re: [ccp4bb] Regarding BMCD
Dear Nishant, You may follw this link below, after you indicate the protein/enzyme/nucleic acid name don't hit ENTER [probably it wont work] CLICK submit. http://xpdb.nist.gov:8060/BMCD4/index.faces;jsessionid=b196fdf1b356c8293b85a9f3981d  jaimohan --- On Fri, 12/6/09, Nishant Varshney nishant_varsh...@yahoo.com wrote: From: Nishant Varshney nishant_varsh...@yahoo.com Subject: [ccp4bb] Regarding BMCD To: Date: Friday, 12 June, 2009, 12:38 PM Dear all, I have bee trying to access the biomolecular crystallization database BMCD for quite sometime now, no matter which route I access it through the page shows an error as the server can not be contacted. I would like to know whether its a problem only I am coming across.Moreover, is there any registration or license required to access BMCD? if there is, I am not aware of it. Your help will be appreciated. Regards Nishant NISHANT KUMAR VARSHNEY C/O Dr. C.G. Suresh, Biochemical Sciences Division, National Chemical Laboratory, Pune-411008, Maharastra, India. Share files, take polls, and make new friends - all under one roof. Click here. Own a website.Get an unlimited package.Pay next to nothing.*Go to http://in.business.yahoo.com/
[ccp4bb] crystool
Dear all, is the Rupp Segelke CRYSTOOL still accessible somewhere? The old link http://www-structure.llnl.gov/crystool/crystool.htm seems not to work anymore. Or are there alternatives? Thanks Clemens
Re: [ccp4bb] crystool
Unfortunately, due to licensing issues and onerous rules here about hosting dynamic content it has become very difficult for me to keep CrysTool available to the public. Expressed interest in CrysTool does help me to press the case. I am hopeful that licensing issues can be worked out, if so, I'll see if I can find a willing host so that CrysTool may again become available. Thank you to all of those that are still interested in CrysTool. Brent Brent W. Segelke, Ph.D. Biosciences and Biotechnology Division Physical and Life Sciences Directorate Lawrence Livermore National Laboratory 7000 East Ave. Livermore, CA 94550 (925) 424 4752 segel...@llnl.gov -Original Message- From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Clemens Grimm Sent: Friday, June 12, 2009 7:01 AM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] crystool Dear all, is the Rupp Segelke CRYSTOOL still accessible somewhere? The old link http:// www-structure.llnl.gov/crystool/crystool.htm seems not to work anymore. Or are there alternatives? Thanks Clemens
Re: [ccp4bb] mtz2various is broken [ was: Another pointless question ]
Apologies, have been away. I hope I have extracted the relevant points from this thread. For the record, the CCP4 library also uses the symops to determine the spacegroup, when it can. Hence the observation below that mtzdmp and refmac find the right spacegroup. However there are plenty of cases where the symops are not available, PDB files with CRYST1 card only, user keywords, etc. And there is plenty of independently developed application code which may not follow the library (bearing in mind that we are an anarcho-syndicalist commune etc etc). Ian is right that the surest way of checking the MTZ file is to open in a text editor. You can also edit the SYMINF line this way, though this is probably classed as advanced ccp4 usage... So in my tests SYMINF 4 2 I 4005 'I 1 2 1' PG2 works fine, while SYMINF 4 2 I 5 'I 1 2 1' PG2 shows the problem. And yes, the problem is then MSYMLB3 using the 5 rather than the spacegroup name or the operators. We should be able to fix that. 4005 is for internal usage, converting to 5 on export from the suite. Probably the generating program should have used 4005. Cheers Martyn My mtz file contains CELL 148.6099 98.3798 251.9687 90. 90.3258 90. SORT1 2 3 0 0 SYMINF 4 2 I 5 'I121' PG2 SYMM X, Y, Z SYMM -X, Y, -Z SYMM X+1/2, Y+1/2, Z+1/2 SYMM -X+1/2, Y+1/2, -Z+1/2 RESO 0.607290094194 0.1371708661317825 So there is a difference, but not the expected one. My mtz file has exactly the info that should go into the cif headers, including the space group number of the standard setting: 5. But mtzdmp and refmac, etc, do manage to find and report the spacegroup as 4005 from this same file. Could there be two conflicting spacegroup numbers stored in the header? For what it's worth. I see the same behavior on files created by pointless (re-indexed from C2), files created directly by mosflm/scala/truncate, and files merged by CAD. Ethan -- *** * * * Dr. Martyn Winn * * * * STFC Daresbury Laboratory, Daresbury, Warrington, WA4 4AD, U.K. * * Tel: +44 1925 603455E-mail: martyn.w...@stfc.ac.uk* * Fax: +44 1925 603825Skype name: martyn.winn * * URL: http://www.ccp4.ac.uk/martyn/ * ***
Re: [ccp4bb] mtz2various is broken [ was: Another pointless question ]
Hi Martyn Since seeing Ethan's last posting I guessed immediately, following on from what Kevin had said earlier, that the program in Ethan's sequence which made the change from SG #4005 to #5 in the MTZ header (and my tests confirm this) is ctruncate; this behaviour presumably is a feature of the Clipper library, so I guess is common to all programs using Clipper (though pointless appears to be an exception - presumably because it specifically creates the 4005 code rather than simply transferring it from input to output). All the other programs in his sequence copy the SG #4005 unchanged. So essentially the problem is an incompatibility between the old (c)symlib and the Clipper library; the former still uses the old conventions that 1) the SG number uniquely identifies alternative settings corresponding to a given standard setting, and 2) the SG number takes precedence over the SG name and/or symm ops to determine the space group, whereas the latter doesn't use unique numbers to identify alternative settings, and assumes the reverse precedence. You suggest changing MSYMLB3 to fix this, i.e. essentially changing it to conform to the symlib documentation (!), so that the SG name takes precedence over the number - I agree this ought to work. The only issue I see is that many programs (e.g. see several examples of this usage in SFALL documentation) allow user input of either the SG name or number, e.g. in SFALL, PDBSET etc: SYMM I2 and SYMM 4005 are equivalent. If we are going to move to the new Clipper-style convention I wonder how this would be handled, if the SG numbers no longer uniquely identify the setting. I guess we would lose this rather useful (IMO at least) feature! I assume you would at least continue to allow use of CCP4-style SG numbers via MSYMLB3 - all our internal scripts rely on this feature. Cheers -- Ian -Original Message- From: owner-ccp...@jiscmail.ac.uk [mailto:owner-ccp...@jiscmail.ac.uk] On Behalf Of Martyn Winn Sent: 12 June 2009 20:46 To: Ethan Merritt Cc: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] mtz2various is broken [ was: Another pointless question ] Apologies, have been away. I hope I have extracted the relevant points from this thread. For the record, the CCP4 library also uses the symops to determine the spacegroup, when it can. Hence the observation below that mtzdmp and refmac find the right spacegroup. However there are plenty of cases where the symops are not available, PDB files with CRYST1 card only, user keywords, etc. And there is plenty of independently developed application code which may not follow the library (bearing in mind that we are an anarcho-syndicalist commune etc etc). Ian is right that the surest way of checking the MTZ file is to open in a text editor. You can also edit the SYMINF line this way, though this is probably classed as advanced ccp4 usage... So in my tests SYMINF 4 2 I 4005 'I 1 2 1' PG2 works fine, while SYMINF 4 2 I 5 'I 1 2 1' PG2 shows the problem. And yes, the problem is then MSYMLB3 using the 5 rather than the spacegroup name or the operators. We should be able to fix that. 4005 is for internal usage, converting to 5 on export from the suite. Probably the generating program should have used 4005. Cheers Martyn My mtz file contains CELL 148.6099 98.3798 251.9687 90. 90.3258 90. SORT1 2 3 0 0 SYMINF 4 2 I 5 'I121' PG2 SYMM X, Y, Z SYMM -X, Y, -Z SYMM X+1/2, Y+1/2, Z+1/2 SYMM -X+1/2, Y+1/2, -Z+1/2 RESO 0.607290094194 0.1371708661317825 So there is a difference, but not the expected one. My mtz file has exactly the info that should go into the cif headers, including the space group number of the standard setting: 5. But mtzdmp and refmac, etc, do manage to find and report the spacegroup as 4005 from this same file. Could there be two conflicting spacegroup numbers stored in the header? For what it's worth. I see the same behavior on files created by pointless (re-indexed from C2), files created directly by mosflm/scala/truncate, and files merged by CAD. Ethan -- *** * * * Dr. Martyn Winn * * * * STFC Daresbury Laboratory, Daresbury, Warrington, WA4 4AD, U.K. * * Tel: +44 1925 603455E-mail: martyn.w...@stfc.ac.uk * * Fax: +44 1925 603825Skype name: martyn.winn * * URL: http://www.ccp4.ac.uk/martyn/ * *** Disclaimer This communication is confidential and may contain privileged information intended solely for the named addressee(s). It may not be used or disclosed except for the purpose for which it has been sent. If you are not the intended recipient you must not review, use, disclose, copy, distribute or take any
Re: [ccp4bb] mtz2various is broken [ was: Another pointless question ]
I didn't mean to commit to a particular solution. That wouldn't be wise on a Friday night with jet lag ;) As an internal call in mtz2various, it should use symops ... but I need to check that this works. Spacegroup number vs name is an issue for the user interface (graphical or otherwise). We always try to support as many standards as possible, but there will always be ambiguities. m -Original Message- From: Ian Tickle [mailto:i.tic...@astex-therapeutics.com] Sent: Fri 6/12/2009 10:45 PM To: Winn, MD (Martyn) Cc: CCP4BB@JISCMAIL.AC.UK; Kevin Cowtan; Phil Evans; Ethan Merritt; Eleanor Dodson Subject: RE: [ccp4bb] mtz2various is broken [ was: Another pointless question ] Hi Martyn Since seeing Ethan's last posting I guessed immediately, following on from what Kevin had said earlier, that the program in Ethan's sequence which made the change from SG #4005 to #5 in the MTZ header (and my tests confirm this) is ctruncate; this behaviour presumably is a feature of the Clipper library, so I guess is common to all programs using Clipper (though pointless appears to be an exception - presumably because it specifically creates the 4005 code rather than simply transferring it from input to output). All the other programs in his sequence copy the SG #4005 unchanged. So essentially the problem is an incompatibility between the old (c)symlib and the Clipper library; the former still uses the old conventions that 1) the SG number uniquely identifies alternative settings corresponding to a given standard setting, and 2) the SG number takes precedence over the SG name and/or symm ops to determine the space group, whereas the latter doesn't use unique numbers to identify alternative settings, and assumes the reverse precedence. You suggest changing MSYMLB3 to fix this, i.e. essentially changing it to conform to the symlib documentation (!), so that the SG name takes precedence over the number - I agree this ought to work. The only issue I see is that many programs (e.g. see several examples of this usage in SFALL documentation) allow user input of either the SG name or number, e.g. in SFALL, PDBSET etc: SYMM I2 and SYMM 4005 are equivalent. If we are going to move to the new Clipper-style convention I wonder how this would be handled, if the SG numbers no longer uniquely identify the setting. I guess we would lose this rather useful (IMO at least) feature! I assume you would at least continue to allow use of CCP4-style SG numbers via MSYMLB3 - all our internal scripts rely on this feature. Cheers -- Ian -Original Message- From: owner-ccp...@jiscmail.ac.uk [mailto:owner-ccp...@jiscmail.ac.uk] On Behalf Of Martyn Winn Sent: 12 June 2009 20:46 To: Ethan Merritt Cc: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] mtz2various is broken [ was: Another pointless question ] Apologies, have been away. I hope I have extracted the relevant points from this thread. For the record, the CCP4 library also uses the symops to determine the spacegroup, when it can. Hence the observation below that mtzdmp and refmac find the right spacegroup. However there are plenty of cases where the symops are not available, PDB files with CRYST1 card only, user keywords, etc. And there is plenty of independently developed application code which may not follow the library (bearing in mind that we are an anarcho-syndicalist commune etc etc). Ian is right that the surest way of checking the MTZ file is to open in a text editor. You can also edit the SYMINF line this way, though this is probably classed as advanced ccp4 usage... So in my tests SYMINF 4 2 I 4005 'I 1 2 1' PG2 works fine, while SYMINF 4 2 I 5 'I 1 2 1' PG2 shows the problem. And yes, the problem is then MSYMLB3 using the 5 rather than the spacegroup name or the operators. We should be able to fix that. 4005 is for internal usage, converting to 5 on export from the suite. Probably the generating program should have used 4005. Cheers Martyn My mtz file contains CELL 148.6099 98.3798 251.9687 90. 90.3258 90. SORT1 2 3 0 0 SYMINF 4 2 I 5 'I121' PG2 SYMM X, Y, Z SYMM -X, Y, -Z SYMM X+1/2, Y+1/2, Z+1/2 SYMM -X+1/2, Y+1/2, -Z+1/2 RESO 0.607290094194 0.1371708661317825 So there is a difference, but not the expected one. My mtz file has exactly the info that should go into the cif headers, including the space group number of the standard setting: 5. But mtzdmp and refmac, etc, do manage to find and report the spacegroup as 4005 from this same file. Could there be two conflicting spacegroup numbers stored in the header? For what it's worth. I see the same behavior on files created by pointless (re-indexed from C2), files created directly by mosflm/scala/truncate, and files merged by CAD. Ethan --
Re: [ccp4bb] Regarding BMCD
That seems likely. I also can't reach the BMCD link, but I can reach the same host on port 80. I understand my institution has a very restrictive firewall, due to being associated with a hospital with lots of medical records and other personal information. Ed Manish Chandra Pathak wrote: It is due to your local computer's or LAN's firewall denying access to the port 8060. Is it correct? all the best Manish *From:* Nishant Varshney nishant_varsh...@yahoo.com *To:* CCP4BB@JISCMAIL.AC.UK *Sent:* Friday, June 12, 2009 3:08:14 AM *Subject:* [ccp4bb] Regarding BMCD Dear all, I have bee trying to access the biomolecular crystallization database BMCD for quite sometime now, no matter which route I access it through the page shows an error as the server can not be contacted. I would like to know whether its a problem only I am coming across.Moreover, is there any registration or license required to access BMCD? if there is, I am not aware of it. Your help will be appreciated. Regards Nishant /NISHANT KUMAR VARSHNEY/ /C/O Dr. C.G. Suresh,/ /Biochemical Sciences Division,/ /National Chemical Laboratory,/ /Pune-411008, Maharastra,/ /India./ http://in.rd.yahoo..com/tagline_groups_8/*http://in.promos.yahoo.com/groups/
