Re: [ccp4bb] Hosed-Up X-Ray Structures: A Big Problem
Hei Tom, We may not be able to prevent deposition of dodgy structures, but we could at least give optimal support to those of us wanting to do a good job. With respect to ligands, the support could sometimes be better - thinking in particular of carbohydrate ligands. Best, Ute From: CCP4 bulletin board CCP4BB@JISCMAIL.AC.UK on behalf of Tom Peat tom.p...@csiro.au Sent: 13 June 2014 09:08 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Hosed-Up X-Ray Structures: A Big Problem I’ll wade into this quagmire before the weekend starts. There are without question some dodgy structures and some of these are due to poor inputs in terms of the cif files that we use for the ligands, or the way we have constructed the ligands, or allowed them to distort during refinement. Some distortions are probably legitimate as maybe you have 1.4 A data and some strain has been introduced, or in fact you put the substrate in and it is partially reacted, so we are seeing an intermediate and that wasn’t taken into account, or some other story. Chemical space is big (really, really BIG) and it is hard to account for all possibilities by just defining each bond type, angle, etc. although we can certainly do better than we have (and in fact I think we are!). And even with everything defined, your mileage will vary (look at all of the safety features we have in cars these days that weren’t there 20 years ago and still thousands die on the road each year). We are really good at protein structures- but if the crystallographer doesn’t look at the data carefully, you get the attached (a recent one that I pulled down that has 1.4 A data and still got this loop wrong- clearly wasn’t looked at very carefully or at all). So, even with really good data, and many automated features, and even good input files, you need the person to actually look at the data and see whether the model fits the density and make a judgement call as to whether the chemistry is plausible and correct. As some people are too busy (or lazy) to do this, there will be structures put into the database which are not only not perfect, but not very good. There are lots of people working on this- PDB REDO, better programs for generating more plausible dictionary files, etc. and they have made our lives much, much easier- Thank You! But all of these won’t eliminate the bad structures deposited (just make it harder to justify a poor structure) unless there is a change in the way structures are deposited (actual criteria for deposition). Do we want that? That is a big question and would really change the dynamics that we currently have. My 2 cents. Cheers, tom From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Jeffrey Bell Sent: Friday, 13 June 2014 3:05 AM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Hosed-Up X-Ray Structures: A Big Problem Hi, Tim, Thanks for your comment. Do you agree with the editorial's claim that some 25% of the deposited protein-ligand complexes might be dodgy in significant details? This editorial comment represents something that I often hear from drug discovery professionals. Is it a matter of PR between crystallographers and other scientists, or does a real problem exist? Cheers, Jeff Bell PrimeX developer Schrödinger, Inc. On Tuesday, June 10, 2014 10:27 AM, Tim Gruene t...@shelx.uni-ac.gwdg.demailto:t...@shelx.uni-ac.gwdg.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I hope that the contents of this section is obvious to most readers of the ccp4 bulletin board. Cheer, Tim On 06/10/2014 03:40 PM, Jeffrey Bell wrote: An editorial comment about protein crystallography appeared under that title. It's short and worth considering. http://pipeline.corante.com/ - -- - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iD8DBQFTlxXkUxlJ7aRr7hoRAlbpAKCcqVkkUwVa2r/M1r9Rp+1rbF6JzgCgiFWR XnSRSZpGKHrDa0tOFgNixJM= =UVlP -END PGP SIGNATURE-
Re: [ccp4bb] SAXS facility and Cryo EM facility
Dear Ruby, They are a dedicated beam line for Biological Sample at the ESRF (BM29); informations are here: http://www.esrf.eu/UsersAndScience/Experiments/MX/About_our_beamlines/BM29 and scheme to apply is here: http://www.esrf.eu/UsersAndScience/UserGuide/Applying/ProposalGuidelines/MXnon-BAGproposal Sincerely, David. On 12/06/2014 18:42, Ruby Sharma wrote: Hello folks can u please help me by telling that where can i avail SAXS facility?? and Cryo EM too?? Regards Ruby -- Dr David FLOT Beam-Line Operation Manager Tel : (+33) 4 76 88 17 63 Structural Biology GroupFax : (+33) 4 76 88 26 24 ESRF B.P. 220, 6 rue Jules Horowitz e-mail : david.f...@esrf.fr F-38043 GRENOBLE CEDEX http://www.esrf.eu
Re: [ccp4bb] CNS MR Help
Dear Appu, If it is possible to solve your structure with currently available MR models using any currently existing technology, one of these programs will be able to do it. Throwing yet another program at the problem won’t help, especially an older program that was good in its time (and is still, to be fair, cutting edge for some things) but is not up-to-date with current molecular replacement algorithms. Some structures can’t be solved by molecular replacement. We can now do a better job of predicting which ones will be very hard, and this is given in the expected LLG output of Phaser. If that says that the problem is expected to be very difficult, you haven’t made any mistakes in running the programs, and you’ve tried all the strategies recommended by the authors of those programs, then your efforts will be better spent in trying to grow better crystals or doing experimental phasing. Best wishes, Randy Read On 12 Jun 2014, at 20:14, Appu kumar appu.kum...@gmail.com wrote: Hello All, I have tried MR in Phaser, MRage, Molrep , Mrbump but i am not getting the true solution which it supposed to be. Although the resoution of data is 6.1A, but i want to give a try to CNS and see if I can find right solution. I have read the manual of CNS but i am unable to get the CNS running. Would you please help me in running the CNS program. Thank you Appu -- Randy J. Read Department of Haematology, University of Cambridge Cambridge Institute for Medical Research Tel: + 44 1223 336500 Wellcome Trust/MRC Building Fax: + 44 1223 336827 Hills RoadE-mail: rj...@cam.ac.uk Cambridge CB2 0XY, U.K. www-structmed.cimr.cam.ac.uk
Re: [ccp4bb] Hosed-Up X-Ray Structures: A Big Problem
I sense someone should quickly point out, on behalf of the developers (I assume it's they that are requested to magically give optimal support), that it's not for want of awareness, intelligence or diligence that this functions are suboptimal: it's want of TIME. As Paul suggested, in ccp4 alone there are several active projects on carbohydrates, nucleic acids, and general restraints. And it's not as if the tools to do this aren't available: defining custom restraints has been possible for ages. It's just not as fantastically convenient as everything else. The fact that /these/ errors are now becoming prominent is testament to how excellent the /rest/ of our toolset has become... presumably the reason we've become too lazy to look at our restraints in detail, because to be honest, few /other /aspects of the analysis require such detailed attention. Now THAT's what I call impressive. phx. P.S. The first C in CCP4 stands for Collaborative, i.e. anybody with good ideas is welcome to contribute the tools they write into the mix... On 13/06/2014 08:43, Ute Krengel wrote: Hei Tom, We may not be able to prevent deposition of dodgy structures, but we could at least give optimal support to those of us wanting to do a good job. With respect to ligands, the support could sometimes be better - thinking in particular of carbohydrate ligands. Best, Ute *From:* CCP4 bulletin board CCP4BB@JISCMAIL.AC.UK on behalf of Tom Peat tom.p...@csiro.au *Sent:* 13 June 2014 09:08 *To:* CCP4BB@JISCMAIL.AC.UK *Subject:* Re: [ccp4bb] Hosed-Up X-Ray Structures: A Big Problem I’ll wade into this quagmire before the weekend starts. There are without question some dodgy structures and some of these are due to poor inputs in terms of the cif files that we use for the ligands, or the way we have constructed the ligands, or allowed them to distort during refinement. Some distortions are probably legitimate as maybe you have 1.4 A data and some strain has been introduced, or in fact you put the substrate in and it is partially reacted, so we are seeing an intermediate and that wasn’t taken into account, or some other story. Chemical space is big (really, really BIG) and it is hard to account for all possibilities by just defining each bond type, angle, etc. although we can certainly do better than we have (and in fact I think we are!). And even with everything defined, your mileage will vary (look at all of the safety features we have in cars these days that weren’t there 20 years ago and still thousands die on the road each year). We are really good at protein structures- but if the crystallographer doesn’t look at the data carefully, you get the attached (a recent one that I pulled down that has 1.4 A data and still got this loop wrong- clearly wasn’t looked at very carefully or at all). So, even with really good data, and many automated features, and even good input files, you need the person to actually look at the data and see whether the model fits the density and make a judgement call as to whether the chemistry is plausible and correct. As some people are too busy (or lazy) to do this, there will be structures put into the database which are not only not perfect, but not very good. There are lots of people working on this- PDB REDO, better programs for generating more plausible dictionary files, etc. and they have made our lives much, much easier- Thank You! But all of these won’t eliminate the bad structures deposited (just make it harder to justify a poor structure) unless there is a change in the way structures are deposited (actual criteria for deposition). Do we want that? That is a big question and would really change the dynamics that we currently have. My 2 cents. Cheers, tom *From:*CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] *On Behalf Of *Jeffrey Bell *Sent:* Friday, 13 June 2014 3:05 AM *To:* CCP4BB@JISCMAIL.AC.UK *Subject:* Re: [ccp4bb] Hosed-Up X-Ray Structures: A Big Problem Hi, Tim, Thanks for your comment. Do you agree with the editorial's claim that some 25% of the deposited protein-ligand complexes might be dodgy in significant details? This editorial comment represents something that I often hear from drug discovery professionals. Is it a matter of PR between crystallographers and other scientists, or does a real problem exist? Cheers, Jeff Bell PrimeX developer Schrödinger, Inc. On Tuesday, June 10, 2014 10:27 AM, Tim Gruene t...@shelx.uni-ac.gwdg.de mailto:t...@shelx.uni-ac.gwdg.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I hope that the contents of this section is obvious to most readers of the ccp4 bulletin board. Cheer, Tim On 06/10/2014 03:40 PM, Jeffrey Bell wrote: An editorial comment about protein crystallography appeared under that title. It's short and worth considering. http://pipeline.corante.com/ - -- -
Re: [ccp4bb] Hosed-Up X-Ray Structures: A Big Problem
Hi Ethan, Maybe I miss something, but whenever an error in one of the cif-files has been reported, be it directly to Garib, or publicly on the ccp4bb, Garib (I assume) fixed very quickly - I don't quite understand why we need a new term for this process? Best, Tim On 06/12/2014 10:45 PM, Ethan A Merritt wrote: [...] Indeed. All of the library-generation tools I am aware of are flawed in their own idiosyncratic ways. I think I shall start a campaign to treat errors in the cif libraries as bugs, and encourage people to report these bugs in the libraries we all use just as they do for bugs in the programs we all use. Ethan [...] -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A signature.asc Description: OpenPGP digital signature
[ccp4bb] Postdoctoral position at Karolinska Institutet
A postdoctoral position is available immediately on structural studies of protein-protein interactions at the core of the human Hedgehog signaling pathway, as part of a long-term collaboration between the laboratories of Rune Toftgård and Luca Jovine at the Department of Biosciences and Nutrition Center for Innovative Medicine at Karolinska Institutet. The Department of Biosciences and Nutrition has state-of-the-art equipment for protein expression in E. coli, insect and mammalian cells, purification, crystallization and in house X-ray diffraction data collection (including Mosquito robotics and a brand new Rigaku CompactHome Lab system with a Pilatus P200K detector). Frequent access to synchrotron sites and excellent computational facilities are also available. With their close integration of academic, clinical and industrial research, KI and the Center for Innovative Medicine offer a highly international and collaborative environment for biomedical studies. To qualify, applicants must hold a Ph.D. or a foreign qualification deemed equivalent to a doctoral degree. The candidate must have significant experience in studying protein-protein interactions using both biochemical and crystallographic approaches. Previous experience with protein expression in mammalian cells will be a distinct advantage. Familiarity with SAXS data collection and processing will also be a plus. At least one first author paper in a high quality international peer-reviewed journal, fluency in english and a strong personal drive to excel in science are required. For additional information and to apply please visit the Karolinska Institutet NetRecruiter system (deadline 29 June): https://ki.mynetworkglobal.com/en/what:job/jobID:38811/where:4/ Further information may also be found here: http://ki.se/people/rutoft http://jovinelab.org Cherry et al. Acta Cryst. D 69:2563-2579 (2013) http://www.ncbi.nlm.nih.gov/pubmed/24311597 Teglund Toftgard Biochim. Biophys. Acta 1805:181-208 (2010) http://www.ncbi.nlm.nih.gov/pubmed/20085802 With best regards, Luca Jovine Rune Toftgård Luca Jovine, Ph.D. Professor of Structural Biology EMBO Young Investigator Karolinska Institutet Department of Biosciences and Nutrition Center for Biosciences Halsovagen 7, SE-141 83 Huddinge, Sweden Voice: +46.(0)8.524-81136 FAX: +46.(0)8.6081-501 E-mail: luca.jov...@ki.se W3: http://jovinelab.org
Re: [ccp4bb] ccp4 ligand tools + wwPDB validation = bug reports?
Dear Ethan, Alexander Schuettelkopf has sent us modified PRODRG parameter file to fix this issue. We'll distribute it in CCP4 updates soon. If you'd like to test it now, the prodrg.param file is here: http://fg.oisin.rc-harwell.ac.uk/scm/loggerhead/cprodrg/trunk/download/head:/prodrg.param-20121005112644-zpoo2favxepvzj8p-80/prodrg.param Marcin On Thu, Jun 12, 2014 at 04:19:46PM -0700, Ethan A Merritt wrote: Earlier this year for the first time I got back a validation report from the PDB for a deposited structure that included wwPDB validation of a ligand. This is great stuff. I approve. I am happy. Unfortunately the validation check reported problems with my ligand. This is bad. I am unhappy. What went wrong? A long story follows. Skip to the end for the TL;DNR summary. Basically I am advocating to treat errors, omissions, or inadequacies in the CCP4 ligand dictionaries as bugs in exactly the same sense as program bugs. Report them when you find them, get them fixed in CCP4 updates, and down the road we will all have better structures. Long version Since last year I have been happily using the integrated tools Coot, Jligand, cprodrg, and refmac5 to sketch a ligand, generate a dictionary, fit to initial difference density, and refine. In the absence of an independent validation check, I thought everything was working acceptably. The bad grade on my wwPDB validation report [pun intended] made me look into the guts of this tool chain more carefully trying to see what went wrong. In short here is what happens: - coot fires up jligand - I sketch the compound and click accept - jligand creates a file prodrg-in.mdl that contains only atom type, connectivity, single/double bond flag - cprodrg takes this and assigns each atom a more complete chemical label, for example O 15.9994 CARBONYL OXYGEN (C=O) CH2 12.011 ALIPHATIC CH2-GROUP NR 14.0067 AROMATIC NITROGEN - cprodrg then categorizes each bond by the assigned types of the two bonded atoms, and similarly categorizes each bond angle by the assigned types of its three constituent atoms. So far so good. Now comes the problematic part. - cprodrg tries to find a target geometry (ideal bond length or angle) for each category by matching against the contents of the file .../Prodrg/param/ff/default If an exact match is not found, it falls through to ... well I'm not sure exactly what the rule is for falling through. This is the part that goes wrong. The content of this default parameter file is rather impoverished. My ligand contained a pyrazole (5-membered ring with 2 adjacent nitrogens). The nitrogens were assigned a category NR5 14.0067 NITROGEN (5-RING) But the default file contains no bond or angle entries for this atom type, so it falls through to the only N-N bond it does contain NSP - NSP target length 1.12Å That's miles off, or at any rate more than 1/3 Å off, the expected length of 1.396Å tabulated in the Mogul database for a pyrazole. (The wwPDB report listed a target of 1.37Å). I don't expect perfection, but target errors of more than 0.3Å in bond length are large compared to the expected accuracy of even a modest resolution protein structure. No wonder the wwPDB validation report flagged it as a 13 sigma outlier in the refined structure. TL;DNR version The $CCP4/share/prodrg/prodrg.param file does not contain target values for many bond types that are correctly identified by prodrg itself. Adding a single line handling NR5-NR5 bonds to the source file ccp4-6.4.0/src/Prodrg/param/ff/default yields a significant improvement in my refined protein structure. Even the R/Rfree are improved, which surprised me. These were identical runs except for the regenerated ligand dictionary. Would it be appropriate to report this as a bug?I think so. Where should I report it? -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
[ccp4bb] Invisible atoms in ligands
Hi all - talking about ligands, a quick question on that old conundrum, of what to do about invisible atoms -- build them with occ=0, or omit them? For bits of protein, I know all the arguments; personally I prefer omitting atoms because: * for amino acid sidechains, their presence is implied in the residue name. * for whole residues, their presence is implied in the sequence numbering However: what about ligands? Nowhere else in the PDB file is their presence implied - or have I missed something? (Certainly disorder in a ligand is important information that needs to be captured!) Cheers phx
Re: [ccp4bb] Invisible atoms in ligands
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Frank, if you can calculate their position, i.e. it is part of a rigid group, I would leave it. If it is flexible, I would remove it because the reader of my deposited structure may not be a crystallographer and misinterpret the result. If it is obvious that some atoms are missing, it is even better because it is more likely to make the reader think about the reasons why part of the ligand is not displayed in the model. Cheers, Tim On 06/13/2014 11:45 AM, Frank von Delft wrote: Hi all - talking about ligands, a quick question on that old conundrum, of what to do about invisible atoms -- build them with occ=0, or omit them? For bits of protein, I know all the arguments; personally I prefer omitting atoms because: * for amino acid sidechains, their presence is implied in the residue name. * for whole residues, their presence is implied in the sequence numbering However: what about ligands? Nowhere else in the PDB file is their presence implied - or have I missed something? (Certainly disorder in a ligand is important information that needs to be captured!) Cheers phx - -- - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iD8DBQFTmsx7UxlJ7aRr7hoRAhxOAJ9YXwdr4kZULidLAdzTgEjdZwfXNQCeKYTA 9vSeeDh7eq2v4CwBII64wn8= =uviV -END PGP SIGNATURE-
Re: [ccp4bb] Invisible atoms in ligands
Hi Frank, I agree with what Tim has just posted. Personally I would not think occupancy=0, since this would mean the atom is not where you placed it (i.e. nowhere near). This could be useful if all your ligand has the same partial occupancy or, if you have multiple poses, the sum of occupancies of the single atoms equals that of the whole ligand. None of the above seems to fit your case. Another possibility is to define the whole ligand and letting the B-factors for those atoms go very high, but this provides an information on coordinates which some would just take for granted... if that structure ends up in the PDB, the less experienced readers would be tempted to say that x,y,z are the coordinates of that atom, which we would know from the B factors they are not. Since a PDB file contains a model (i.e. our understanding and interpretation of the electron density maps), omitting those atoms seems to me the more correct way. Having said so, I agree some important information is missing, but this can be explained in the paper supporting the entry. If the structure is only for internal use, then people dealing with it should be warned and the insanely-high B-factors option might be preferable. Hope this helps, Ciao Marco 2014-06-13 10:45 GMT+01:00 Frank von Delft frank.vonde...@sgc.ox.ac.uk: Hi all - talking about ligands, a quick question on that old conundrum, of what to do about invisible atoms -- build them with occ=0, or omit them? For bits of protein, I know all the arguments; personally I prefer omitting atoms because: - for amino acid sidechains, their presence is implied in the residue name. - for whole residues, their presence is implied in the sequence numbering However: what about ligands? Nowhere else in the PDB file is their presence implied - or have I missed something? (Certainly disorder in a ligand is important information that needs to be captured!) Cheers phx
[ccp4bb] 2nd International Workshop on Pontin/RUVBL1 Reptin/RUVBL2 - 3rd Announcement
Dear CCP4ers, We would like to remind you that the registration for this workshop, that will take place in very nice surroundings in Oeiras (Portugal) next October 10-12, is still open. The Workshop will divided into 5 sessions covering the following topics: - Structural Biology - Chromatin remodeling and pre-rRNA processing - Regulation of gene expression - Transcription - Pathophysiology Each session will be structured as follows: - Invited lecture 35 minutes - Invited lecture 35 minutes - Coffee/Tea break 50 minutes - Selected talks from Abstracts Poster sessions will be held during coffee/tea and lunch breaks. Please visit http://pontinreptin2014.itqb.unl.pt where you will find regularly updated information on this meeting. A lot has happened since the exciting First Workshop in 2012 that gathered people from 15 countries in Bordeaux in 2012. For those of you who did not attend, you can get a flavor of it by reading its Proceedings (Sci. Signal. 2013; 6, mr1). Whether Pontin/RUVBL1 Reptin/RUVBL2 are at the core of your studies, or whether you recently fell upon them in the course of your research, this Workshop will allow you to meet all the specialists in this complex field and find collaborations. To take advantage of the reduced registration fee, please register until June 30. There are still many open slots for oral communications besides invited speakers. Important dates: Early registration deadline - June 30 (150 Eur PhD students / 200 Eur PhD holders) Registration deadline - July 31 (200 Eur PhD students / 250 Eur PhD holders) Registration fee accomodation payment deadline - August 15 Abstract submission deadline - August 31 We have secured a special single room rate of 50 Eur/night at nearby Hotel Riviera () - this rate is good until August 15. We look forward to meeting you soon in Portugal! The local organizing committee, Pedro Matias Tiago Bandeiras Sara Silva Industry and Medicine Applied Crystallography Macromolecular Crystallography Unit ___ Phones : (351-21) 446-9100 Ext. 1669 (351-21) 446-9669 (direct) Fax : (351-21) 441-1277 or 443-3644 email : mat...@itqb.unl.pt http://www.itqb.unl.pt/research/biological-chemistry/industry-and-medicine-applied-crystallography http://www.itqb.unl.pt/labs/macromolecular-crystallography-unit Mailing address : Instituto de Tecnologia Quimica e Biologica Apartado 127 2781-901 OEIRAS Portugal
Re: [ccp4bb] Invisible atoms in ligands
Hi Tim, The problem with missing atoms in ligands is that you cannot use the coordinates for any follow-up calculation that requires ligand topology (e.g. restraint generation). That forces you to rely on the annotation of the compound, for instance at the PDB. That can be quite messy and leaves extra room for errors and misunderstandings. Cheers, Robbie -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Tim Gruene Sent: Friday, June 13, 2014 12:04 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Invisible atoms in ligands -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Frank, if you can calculate their position, i.e. it is part of a rigid group, I would leave it. If it is flexible, I would remove it because the reader of my deposited structure may not be a crystallographer and misinterpret the result. If it is obvious that some atoms are missing, it is even better because it is more likely to make the reader think about the reasons why part of the ligand is not displayed in the model. Cheers, Tim On 06/13/2014 11:45 AM, Frank von Delft wrote: Hi all - talking about ligands, a quick question on that old conundrum, of what to do about invisible atoms -- build them with occ=0, or omit them? For bits of protein, I know all the arguments; personally I prefer omitting atoms because: * for amino acid sidechains, their presence is implied in the residue name. * for whole residues, their presence is implied in the sequence numbering However: what about ligands? Nowhere else in the PDB file is their presence implied - or have I missed something? (Certainly disorder in a ligand is important information that needs to be captured!) Cheers phx - -- - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iD8DBQFTmsx7UxlJ7aRr7hoRAhxOAJ9YXwdr4kZULidLAdzTgEjdZwfXNQCeKYT A 9vSeeDh7eq2v4CwBII64wn8= =uviV -END PGP SIGNATURE-
[ccp4bb] Www
wwdwwwy
Re: [ccp4bb] Www
avinash singh avns.si...@gmail.com writes: wwdwwwy Wow, imagine the fluorescence from that… -- Ian ◎
Re: [ccp4bb] Www
Solubility issues though? Dr David C Briggs PhD http://about.me/david_briggs On 13 Jun 2014 11:45, Ian Clifton ian.clif...@chem.ox.ac.uk wrote: avinash singh avns.si...@gmail.com writes: wwdwwwy Wow, imagine the fluorescence from that… -- Ian ◎
Re: [ccp4bb] ccp4 ligand tools + wwPDB validation = bug reports?
On 13/06/2014 03:43, Paul Emsley wrote: On 13/06/14 00:19, Ethan A Merritt wrote: snip This is a known problem with cprodrg - no need to report it. Cprodrg will undergo little to no maintainance from now on. Well, it was not known to me. While there is indeed little active development at the moment, we do generally fix bugs if they are reported. This one will be taken care of by the next CCP4 update. Cheers, Alexander FWIW, my CCP4 colleagues are throwing their weight behind ACEDRG - which should be available in the next CCP4 release. As an aside, I wonder how you got Coot to fire up JLigand without a link (and I thought that jligand used libcheck as its backend). I wonder if you instead meant Coot's lbg. In the mean-time you can use the Coot's Mogul plug-in to update the restraint information from cprodrg. Or of course, Just Use Grade (as you imply :-). Regards, Paul. -- Alexander W. Schuettelkopf a.schuettelk...@beatson.gla.ac.uk the Beatson Institute for Cancer ResearchTel: +44-141-3306565 Garscube Estate, Switchback Road Fax: +44-141-9426521 Glasgow, G61 1BD
[ccp4bb] m_range_check error in aimless
Dear all, I'm trying to scale/merge mtz files in ccp4 (Pointless/Aimless/ctruncate/Rfree pipeline) and keep getting an UNHANDLED EXCEPTION: vector::_M_range_check at the end of the aimless step, right after the standard deviation v. intensity tables. The output mtz file is not written and consequently ctruncate craps out because of no input file. This occurs with the temporary directory on NSF and local, and with one or two mtz files as input. How can I go beyond this? Andreas -- Andreas Förster Crystallization and X-ray Facility Manager Centre for Structural Biology Imperial College London
Re: [ccp4bb] m_range_check error in aimless
What version of Aimless are you running? I thought I had fixed that bug Phil On 13 Jun 2014, at 11:59, Andreas Förster docandr...@gmail.com wrote: Dear all, I'm trying to scale/merge mtz files in ccp4 (Pointless/Aimless/ctruncate/Rfree pipeline) and keep getting an UNHANDLED EXCEPTION: vector::_M_range_check at the end of the aimless step, right after the standard deviation v. intensity tables. The output mtz file is not written and consequently ctruncate craps out because of no input file. This occurs with the temporary directory on NSF and local, and with one or two mtz files as input. How can I go beyond this? Andreas -- Andreas Förster Crystallization and X-ray Facility Manager Centre for Structural Biology Imperial College London
Re: [ccp4bb] Invisible atoms in ligands
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Robbie, maybe it is good not to use coordinates for calculations if you cannot measure the coordinates? Cheers, Tim On 06/13/2014 12:35 PM, Robbie Joosten wrote: Hi Tim, The problem with missing atoms in ligands is that you cannot use the coordinates for any follow-up calculation that requires ligand topology (e.g. restraint generation). That forces you to rely on the annotation of the compound, for instance at the PDB. That can be quite messy and leaves extra room for errors and misunderstandings. Cheers, Robbie -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Tim Gruene Sent: Friday, June 13, 2014 12:04 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Invisible atoms in ligands Hi Frank, if you can calculate their position, i.e. it is part of a rigid group, I would leave it. If it is flexible, I would remove it because the reader of my deposited structure may not be a crystallographer and misinterpret the result. If it is obvious that some atoms are missing, it is even better because it is more likely to make the reader think about the reasons why part of the ligand is not displayed in the model. Cheers, Tim On 06/13/2014 11:45 AM, Frank von Delft wrote: Hi all - talking about ligands, a quick question on that old conundrum, of what to do about invisible atoms -- build them with occ=0, or omit them? For bits of protein, I know all the arguments; personally I prefer omitting atoms because: * for amino acid sidechains, their presence is implied in the residue name. * for whole residues, their presence is implied in the sequence numbering However: what about ligands? Nowhere else in the PDB file is their presence implied - or have I missed something? (Certainly disorder in a ligand is important information that needs to be captured!) Cheers phx - -- - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iD8DBQFTmuJyUxlJ7aRr7hoRAjdqAJ95tqbDlWhqW01lAuVvLwsMIAkv1wCaA0Bk O0z7t7Bl7O7amDF9CxM0CI0= =QSdy -END PGP SIGNATURE-
Re: [ccp4bb] Invisible atoms in ligands
Hi Tim, The problem I see with including atoms with no density is that the one place you can guarantee those atoms are not (at 100% occupancy), is at the coordinates assigned to them. I would argue that the scientific inaccuracy of such a model should outweigh the desire to use the coordinates for downstream calculations. A better solution may be for the PDB to require us to submit the PDB and CIF file we generate for the full ligand in addition to the protein PDB file which may only contain a truncated portion of the ligand as part of the model. I prefer omitting the atoms in the same way I do for the protein model and for the same reasons. I accept this makes it potentially more troublesome for downstream users as things stand, although would argue that there is greater potential for harm if the unsuspecting user believes the atomic positions are correct, where a ligand (or protein) atom has been modeled into a region with no density. Best, Isaac Westwood On 13 June 2014 11:35, Robbie Joosten robbie_joos...@hotmail.com wrote: Hi Tim, The problem with missing atoms in ligands is that you cannot use the coordinates for any follow-up calculation that requires ligand topology (e.g. restraint generation). That forces you to rely on the annotation of the compound, for instance at the PDB. That can be quite messy and leaves extra room for errors and misunderstandings. Cheers, Robbie -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Tim Gruene Sent: Friday, June 13, 2014 12:04 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Invisible atoms in ligands -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Frank, if you can calculate their position, i.e. it is part of a rigid group, I would leave it. If it is flexible, I would remove it because the reader of my deposited structure may not be a crystallographer and misinterpret the result. If it is obvious that some atoms are missing, it is even better because it is more likely to make the reader think about the reasons why part of the ligand is not displayed in the model. Cheers, Tim On 06/13/2014 11:45 AM, Frank von Delft wrote: Hi all - talking about ligands, a quick question on that old conundrum, of what to do about invisible atoms -- build them with occ=0, or omit them? For bits of protein, I know all the arguments; personally I prefer omitting atoms because: * for amino acid sidechains, their presence is implied in the residue name. * for whole residues, their presence is implied in the sequence numbering However: what about ligands? Nowhere else in the PDB file is their presence implied - or have I missed something? (Certainly disorder in a ligand is important information that needs to be captured!) Cheers phx - -- - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iD8DBQFTmsx7UxlJ7aRr7hoRAhxOAJ9YXwdr4kZULidLAdzTgEjdZwfXNQCeKYT A 9vSeeDh7eq2v4CwBII64wn8= =uviV -END PGP SIGNATURE-
Re: [ccp4bb] Invisible atoms in ligands
Hi Tim, The decision of which atoms you can and cannot see in your map is rather subjective. Also the way you generate your map can make a big (enough) difference. A new map after additional refinement, an NCS averaged map, or a feature-enhanced map might show you the position of (some of) the missing atoms. I prefer the 'high B-factor' model unless you have a very good reason to believe the compound is in any way chemically modified. Cheers, Robbie -Original Message- From: Tim Gruene [mailto:t...@shelx.uni-ac.gwdg.de] Sent: Friday, June 13, 2014 13:37 To: Robbie Joosten; CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Invisible atoms in ligands -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Robbie, maybe it is good not to use coordinates for calculations if you cannot measure the coordinates? Cheers, Tim On 06/13/2014 12:35 PM, Robbie Joosten wrote: Hi Tim, The problem with missing atoms in ligands is that you cannot use the coordinates for any follow-up calculation that requires ligand topology (e.g. restraint generation). That forces you to rely on the annotation of the compound, for instance at the PDB. That can be quite messy and leaves extra room for errors and misunderstandings. Cheers, Robbie -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Tim Gruene Sent: Friday, June 13, 2014 12:04 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Invisible atoms in ligands Hi Frank, if you can calculate their position, i.e. it is part of a rigid group, I would leave it. If it is flexible, I would remove it because the reader of my deposited structure may not be a crystallographer and misinterpret the result. If it is obvious that some atoms are missing, it is even better because it is more likely to make the reader think about the reasons why part of the ligand is not displayed in the model. Cheers, Tim On 06/13/2014 11:45 AM, Frank von Delft wrote: Hi all - talking about ligands, a quick question on that old conundrum, of what to do about invisible atoms -- build them with occ=0, or omit them? For bits of protein, I know all the arguments; personally I prefer omitting atoms because: * for amino acid sidechains, their presence is implied in the residue name. * for whole residues, their presence is implied in the sequence numbering However: what about ligands? Nowhere else in the PDB file is their presence implied - or have I missed something? (Certainly disorder in a ligand is important information that needs to be captured!) Cheers phx - -- - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iD8DBQFTmuJyUxlJ7aRr7hoRAjdqAJ95tqbDlWhqW01lAuVvLwsMIAkv1wCaA0 Bk O0z7t7Bl7O7amDF9CxM0CI0= =QSdy -END PGP SIGNATURE-
Re: [ccp4bb] Invisible atoms in ligands
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Robbie, Frank probably meant the status of the model when the author is ready for deposition, i.e., already after additional refinement. The B-factor assumes a harmonic oscillation of its atom on a linear trajectory (maybe the superposition of one trajectory in each of the three dimensions) - that's almost always a very poor assumption for an atom for which you don't see the density, and by using the B-value to mop up, you only adjust a parameter and may reduce the R-value, i.e. improve your model w.r.t. crystallographic data. As you remove the atoms you don't see, you improve your model with respect to its usability after deposition. Cheers, Tim On 06/13/2014 01:59 PM, Robbie Joosten wrote: Hi Tim, The decision of which atoms you can and cannot see in your map is rather subjective. Also the way you generate your map can make a big (enough) difference. A new map after additional refinement, an NCS averaged map, or a feature-enhanced map might show you the position of (some of) the missing atoms. I prefer the 'high B-factor' model unless you have a very good reason to believe the compound is in any way chemically modified. Cheers, Robbie -Original Message- From: Tim Gruene [mailto:t...@shelx.uni-ac.gwdg.de] Sent: Friday, June 13, 2014 13:37 To: Robbie Joosten; CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Invisible atoms in ligands Hi Robbie, maybe it is good not to use coordinates for calculations if you cannot measure the coordinates? Cheers, Tim On 06/13/2014 12:35 PM, Robbie Joosten wrote: Hi Tim, The problem with missing atoms in ligands is that you cannot use the coordinates for any follow-up calculation that requires ligand topology (e.g. restraint generation). That forces you to rely on the annotation of the compound, for instance at the PDB. That can be quite messy and leaves extra room for errors and misunderstandings. Cheers, Robbie -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Tim Gruene Sent: Friday, June 13, 2014 12:04 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Invisible atoms in ligands Hi Frank, if you can calculate their position, i.e. it is part of a rigid group, I would leave it. If it is flexible, I would remove it because the reader of my deposited structure may not be a crystallographer and misinterpret the result. If it is obvious that some atoms are missing, it is even better because it is more likely to make the reader think about the reasons why part of the ligand is not displayed in the model. Cheers, Tim On 06/13/2014 11:45 AM, Frank von Delft wrote: Hi all - talking about ligands, a quick question on that old conundrum, of what to do about invisible atoms -- build them with occ=0, or omit them? For bits of protein, I know all the arguments; personally I prefer omitting atoms because: * for amino acid sidechains, their presence is implied in the residue name. * for whole residues, their presence is implied in the sequence numbering However: what about ligands? Nowhere else in the PDB file is their presence implied - or have I missed something? (Certainly disorder in a ligand is important information that needs to be captured!) Cheers phx - -- - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iD8DBQFTmuzWUxlJ7aRr7hoRAsazAJ0bkmlFBRPNxDDOnvuzRp9y5FMYBwCg3yj0 XosHt98UyfOcUrW4OWizoow= =YDU4 -END PGP SIGNATURE-
[ccp4bb] GRC and GRS on Diffraction Methods in Structural Biology 7/27/2014 - 8/1/2014
Dear all, As I did give the full promotional message for why these are just outstanding meetings to attend, I will only invite you to look at the latest programs GRC (http://www.grc.org/programs.aspx?id=11654) GRS (http://www.grc.org/programs.aspx?year=2014program=grs_diff). and also remind you that the registration is closing in 15 days (June 29). There are still spots available for selected abstracts to be presented towards the end of the meeting, and participant places are filling up soon (especially after a wave of 15 new registrations only yesterday!) We hope to see you all at Bates college and promise you two exciting meetings and a great time! On behalf of the GRC and GRS organizers, Tassos
Re: [ccp4bb] Hosed-Up X-Ray Structures: A Big Problem
Do those fixes also make it to the phenix version of the library? Yes, this is the CCP4bb, but the monomer library is also used by Phenix, and a good number of structures (almost half of those deposited this year?) in the PDB now come from phenix.refine. Or in other words, is there a central, high quality monomer library shared among the two most common refinement programs? (The phenix version is more like a fork of the CCP4, I think.) And not all fixes are obvious. Think of the thread from June 4 this year about XYP and HSZ. https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ccp4bb;e617308e.1406 The atoms here have non-standard numbering, which would break the way sugar linkages are defined (and sugar linkages in glycoproteins are just as standard as peptide linkages are in glyco- and non-glyco-proteins.) Would this be fixed, or not, I am not sure. I think it might encourage those of us who spot these errors to report, if there was a clear call for, or a place to submit these errors. CCP4bb might be that place; that should depend on what Garib and the phenix folk prefer. Engin P.S. I should, as always, say that while the libraries we use are imperfect, without them the situation would be much, much worse, so many thanks to Garib et al for their hard work. On 6/13/14, 3:12 AM, Tim Gruene wrote: Hi Ethan, Maybe I miss something, but whenever an error in one of the cif-files has been reported, be it directly to Garib, or publicly on the ccp4bb, Garib (I assume) fixed very quickly - I don't quite understand why we need a new term for this process? Best, Tim On 06/12/2014 10:45 PM, Ethan A Merritt wrote: [...] Indeed. All of the library-generation tools I am aware of are flawed in their own idiosyncratic ways. I think I shall start a campaign to treat errors in the cif libraries as bugs, and encourage people to report these bugs in the libraries we all use just as they do for bugs in the programs we all use. Ethan [...]
[ccp4bb] Postdoctoral Position at Cancer Research UK, London Research Institute.
To all who may be interested. Neil McDonald has asked me to forward this message to the bulletin board. Please reply to him at neil.mcdon...@cancer.org.uk and NOT to me. Thanks Andrew = Postdoctoral Position (4 years), Structural Biology Laboratory London Research Institute (LRI), Cancer Research UK Structural Biology of Growth Factor Signalling A postdoctoral position is available in the Structural Biology Laboratory headed by Neil McDonald to work on molecular mechanisms underlying the assembly and activation of growth factor signalling complexes. The successful candidate will join a multidisciplinary group using structural biology, biochemistry, biophysics and cell biology. We are interested in how signals are initiated at the plasma membrane and are propagated into the cell nucleus. This project will focus on the RET receptor tyrosine kinase activation (see Plaza-Menacho et al. Mol. Cell 2014, Kjær et al. Nat. Struc. Mol. Biol. 2010 and Knowles et al. J. Biol. Chem. 2006). More information on our research activities is available at the lab website: http://www.london-research-institute.org.uk/research/neil-mcdonald. The postdoctoral fellow will join the lab at an exciting phase prior to the London Research Institute becoming part of the Francis Crick Institute (www.crick.ac.uk). The fellow will benefit from both the multidisciplinary environment in the lab and a highly collaborative LRI/Crick community. The lab has extensive crystallographic and robotics equipment with local access to electron microscopy, TIRF and confocal microscopes. We have regular access to synchrotron beamlines at Diamond and ESRF as part of a Cancer Block Allocation Group. The successful candidate will have a relevant PhD or be in the final stages of completing their PhD and have a strong interest in structural biology or cell signalling. Previous experience in protein purification, tissue culture, electron microscopy or crystallography would be an advantage. Informal enquires from interested individuals should be made by email to Professor Neil McDonald at neil.mcdon...@cancer.org.uk. Closing date for applications is sometime over the summer, 2014. -- Andrew Purkiss X-ray Laboratory London Research Institute Cancer Research UK
Re: [ccp4bb] Hosed-Up X-Ray Structures: A Big Problem
On Friday, 13 June 2014 10:12:50 AM Tim Gruene wrote: Hi Ethan, Maybe I miss something, but whenever an error in one of the cif-files has been reported, be it directly to Garib, or publicly on the ccp4bb, Garib (I assume) fixed very quickly - I don't quite understand why we need a new term for this process? See the other thread ccp4 ligand tools + wwPDB validation = bug reports Because the error is not in a pre-packaged cif file. Nor is it in a ccp4 program per se. It is in a library that is used by cprodrg to generate a cif file for previously unknown ligands. This library originally came from the Dundee folks, not ccp4, and it was not clear who if anyone was maintaining it. In an admirably quick response, Alexander Schuettelkopf has now expressed his willingness to respond to such bug reports and update the library. So that's good news for cprodrg, and I gather that indeed the fixes will appear in future ccp4 updates. But the problem is more general. For example, I have had analogous problems with Grade. There again it is clear that this can affect other ccp4-ers, so ccp4bb seems to me a good place to mention any bugs or quirks that contribute to structure refinement errors so that others are aware of potential problems. The eventual fix may have to come from elsewhere (e.g. GlobalPhasing in the case of Grade). Unlike prodrg, the Grade code and libraries so far as I know are not available for inspection or patching locally. Paul Emsley has Emailed my separately that there is a new project ACEDRG in the offing that may take over the prodeg/Grade niche inside ccp4. Perhaps someone involved in ACEDRG will post a summary of what it will offer? cheers, Ethan On 06/12/2014 10:45 PM, Ethan A Merritt wrote: [...] Indeed. All of the library-generation tools I am aware of are flawed in their own idiosyncratic ways. I think I shall start a campaign to treat errors in the cif libraries as bugs, and encourage people to report these bugs in the libraries we all use just as they do for bugs in the programs we all use. Ethan [...] -- mail: Biomolecular Structure Center, K-428 Health Sciences Bldg MS 357742, University of Washington, Seattle 98195-7742
[ccp4bb] Position for a Research Technician at the Membrane Protein Laboratory at Diamond Light Source
To all who might be interested We are seeking a full-time Research Technician to work at the Membrane Protein Laboratory (MPL) located at the Diamond Light Source in Oxfordshire. The MPL at Diamond Light Source is a Wellcome Trust funded facility created in collaboration between Imperial College London and Diamond Light Source. This laboratory allows scientists to determine medically relevant membrane protein structures more efficiently by combining recently developed high throughput technologies for protein production/crystallisation and X-ray diffraction data collection system at Diamond. The MPL is located in laboratories around the ring at Diamond and also at the Research Complex at Harwell. MPL is equipped with state-of-the-art technology and equipment. The successful candidate will report directly to Dr Isabel Moraes, the MPL Group Leader. In the group he/she would assist in all aspects of the lab work, in particular repairing and maintenance of crystallisation robots, assisting with training users in crystallisation with robots; production and crystallisation of membrane proteins. The technician will also be responsible for the general running of the laboratory, including placing orders, maintaining stocks of chemicals, preparing solutions, maintaining all the equipment and general laboratory maintenance. The applicant will also have a role in maintaining safety standards and documentation and have excellent communication skills. The successful candidate must have 2 A-Levels (or equivalent) in relevant subjects and experience in a technical or scientific role. A BSc in Biochemistry/Biology or equivalent is desirable. Practical experience with protein purification and laboratory-based research is essential while experience in Protein expression, Cell Culture and mutagenesis and cloning techniques is desirable. You also must have excellent verbal and written communication skills, a methodical approach to work and the ability to pay close attention to details. You will also have the ability to work with limited supervision, good interpersonal and organisational skills as well as the ability to work as part of a team. These are full-time post available for up to 12 months in the first instance, with possibility of extension subject to funding.Informal enquiries may be made to Dr Isabel Moraes, the MPL group leader (i.mor...@imperial.ac.ukmailto:i.mor...@imperial.ac.uk). http://www.diamond.ac.uk/Beamlines/Mx/MPL.html Closing date: 8 July 2014 (midnight BST) To apply, Job Description and Person Specification please refer to the following webpage https://www4.ad.ic.ac.uk/OA_HTML/OA.jsp?page=/oracle/apps/irc/candidateSelfService/webui/VisVacDispPGakRegionApplicationId=821transactionid=1538103408retainAM=YaddBreadCrumb=Sp_svid=43842p_spid=1669138oapc=9oas=dHtHWqciP0_3C_VtnV-LXQ Kind regards, Isabel Dr Isabel De Moraes, MRSC Membrane Protein Laboratory Diamond Light Source Dr Isabel De Moraes, MRSC Head of the Membrane Protein Laboratory Diamond Light Source Ltd, Harwell Science and Innovation Campus, Chilton, Didcot, Oxfordshire, OX11 ODE, UK -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
Re: [ccp4bb] ccp4 ligand tools + wwPDB validation = bug reports?
On 13/06/14 11:39, Alexander Schuettelkopf wrote: On 13/06/2014 03:43, Paul Emsley wrote: On 13/06/14 00:19, Ethan A Merritt wrote: snip This is a known problem with cprodrg - no need to report it. Cprodrg will undergo little to no maintainance from now on. Well, it was not known to me. While there is indeed little active development at the moment, we do generally fix bugs if they are reported. This one will be taken care of by the next CCP4 update. Oh! That's news to me obviously. I thought that I was echoing CCP4 policy. I thought that you'd been out of the picture for 3 years or more. OK, cool. Hmmm... so here's a feature request: I have been doing some dictionary comparisons. It would be good if cprodrg could join the set of tested programs. The input files are the dictionary cifs of the refmac monomer library. It would be great if you could get cprodrg to read such files and produce new dictionaries. Cheers, Paul.
[ccp4bb] CCP4-6.4.0 Update 018
Dear CCP4 Users An update for the CCP4-6.4.0 series has just been released, consisting of the following changes • refmac5 (all platforms): – Fixed restraints for M- and P-peptides – Fixed SAD scaling issue • monomers (all): – Fixed description for M- and P-peptides and some other entries • pointless (all): – Update to 1.9.10 fixing a long-standing bug in reindexing files with different (permuted) unit cells • aimless (all): – Fix to explicit run definitioin Note that auto-updates work only with CCP4 6.4.0 series, therefore please upgrade if necessary. The Update Manager is now included in the package so you do not need to install it separately. In addition, all available updates will be installed automatically if you are using Setup Manager for CCP4 installation. Please report any bugs to c...@stfc.ac.ukmailto:c...@stfc.ac.uk. Many thanks for using CCP4. The CCP4 Core Team -- Scanned by iCritical.
