Re: [ccp4bb] mmCIF as working format?
I hope that some [X]Emacs expert can rewrite Charlie Bond's wonderful pdb-mode to work with mmCIF files (or at least the coordinate bits) … for exactly the reasons Phil Jeffrey points out Phil On 8 Aug 2013, at 00:54, Jeffrey, Philip D. pjeff...@princeton.edu wrote: Nat Echols wrote: Personally, if I need to change a chain ID, I can use Coot or pdbset or many other tools. Writing code for this should only be necessary if you're processing large numbers of models, or have a spectacularly misformatted PDB file. Problem. Coot is bad at the chain label aspect. Create a pdb file containing residues A1-A20 and X101-X120 - non-overlapping numbering. Try to change the chain label of X to A. I get WARNING:: CONFLICT: chain id already exists in this molecule This is (IMHO) a bizarre feature because this is exactly the sort of thing you do when building structures. Therefore I do one of two things: 1. Open it in (x)emacs, replace X with A and Bob's your uncle. 2. Start Peek2 - that's my interactive program for doing simple and stupid things like this. I type read test.pdb and chain and Peek2 prompts me at perceived chain breaks (change in chain label, CA-CA breaks, ATOM/HETATM transitions c) and then write test.pdb. Takes less than 10 seconds. CCP4i would probably still be launching, as would Phenix. The reason I do #1 or #2 is not to be a Luddite, but to do something trivial and boring quickly so I can get back to something interesting like building structures, or beating subjects to death on CCP4bb. What's lacking is an interactive, or just plain fast method in any guise, way of doing simple PDB manipulations that we do tons of times when building protein structures. I've used Peek2 thousands of times for this purpose, which is the only reason it still exists because it's a fairly stupid program. A truly interactive version of PDBSET would be splendid. But, again, it always runs in batch mode. mmCIF looked promising, apropos emacs, when I looked at the spec page at: http://www.iucr.org/__data/iucr/cifdic_html/2/cif_mm.dic/Catom_site.html because that ATOM data is column-formatted. Cool. However looking at 6LYZ.cif from RCSB's site revealed that the XYZ's were LEFT-justified: http://www.rcsb.org/pdb/files/6LYZ.cif which makes me recoil in horror and resolve to use PDB format until someone puts a gun to my head. Really, guys, if you can put multiple successive spaces to the RIGHT of the number, why didn't you put them to the LEFT of it instead ? Same parsing, better readability. Phil Jeffrey Princeton (using the vernacular but deathly serious about protein structure)
Re: [ccp4bb] mmCIF as working format?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/07/2013 11:54 PM, Nat Echols wrote: PLEASE tell the developers what you need to get your job done; we can't read minds. -Nat Dear Nat, I have a student working for me until the end of the month. I asked her to calculate the mean ratio of U(H)/U(X) where X is the atom the corresponding hydrogen is bound to. I would like her to group together as follows: 1) all N-H and O-H within that protein 2) all Calpha-Halpha 3) all remaining C-H bonds 4) all O-H from the H2O and H3O in the structure. I am not sure whom to address this request to, so please forward it to the developer. If the could would actually work on a shelxl res-file it would be brilliant. I shall not ask George for this software because as a scientist he has much more important and much more general problems to work on than this. At the moment the person is doing it by hand which might take a day. So if you could return the code by tomorrow that would be nice. Out of the tens of thousands of crystallographers coming up with funny ideas (because, yes, you cannot read minds) you might receive such requests several times a day. And you seriously think this is the way we should go? Bless your funding agencies. Cheers, Tim P.S.: I found this discussing about mmCIF quite interesting, and since I was reminded that mmCIF is still kind of line oriented, I am pretty relieved. I just don't think that a 'universal' API exists - the student I am talking about does not know any programming language at all, and the next student might require an API in scheme, ruby, java, C#++-3.141, fortran-123, ... - -- - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFSA0YIUxlJ7aRr7hoRApyzAJ94tzJVf81vOggf7KO9SEwoidUz2QCcCkwQ 9IB2FlSTW7oiMP21vUP7QsY= =dGz8 -END PGP SIGNATURE-
[ccp4bb] Call for MX-beamtime proposals at HZB-BESSY, deadline September 1, 2013 is approaching
Next MX-proposal application deadline: September 1, 2013 is approaching The Pilatus 6M is operational at BL14.1, which leads to a substantial performance increase of this station Single 8h beamtime bookings are now possible We kindly invite new MX-proposals for beamtime applications for the next beamtime period. In order to apply for beamtime, please register at the HZB on-line access tool GATE (https://www.helmholtz-berlin.de/pubbin/hzbgate) and submit a new beamtime application proposal. Please note: Your old accounts are not valid for the new system GATE. Proposals cannot be submitted via BOAT (GATE-Photons) HZB provides beamtime at the MX-beamlines 14.1, 14.2 and 14.3. The requested beamtime is granted based on the reviewed proposal and reports from previous research activities. Reported results from previous beamtimes stated in the Experimental Reports form will affect the chances for future beamtimes significantly. Please make sure to include them if available. Experimental setup: BL14.1 setup: - Photon flux: 1.4x10¹¹ Phot/sx100mAx0.05%BW at sample position (0.1-1 sec exposure time per frame) - User defined beam shaping from 30µm-100µm diameter possible - Pilatus 6M detector, 164mm-680mm max. distance from the sample - Microdiffractometer (MD2) with Mini-kappa goniometer MK3 (STAC controlled) - Automatic sample changer (CATS), 90 sample storage capacity (SPINE-Pin EMBL sample magazine compatibility) - 96-well crystallization plate scanning operational upon request - 32-core XEON-CPU server, with 10Gb uplink to Pilatus 6M - EDNA installed and available - Common MX-software installed including XDS, IMOSFLM, CCP4, Phenix, SHELXC-E, etc. - Automated data processing with XDSAPP available - Remotely controlled cryo-shutter for crystal annealing - Bruker AXS X-Flash XRF detector We are offering the hard- and software environment for carrying out: - UVRIP experiments at BL14.1. For further information, please visit: http://www.helmholtz-berlin.de/forschung/funkma/soft-matter/forschung/bessy-mx/ancillary-facilities/uvrip_en.html - In situ crystal screening experiments, please visit: http://www.helmholtz-berlin.de/forschung/funkma/soft-matter/forschung/bessy-mx/ancillary-facilities/insitu-screening_en.html BL14.2 setup: - Photon flux: 1.9x10¹¹ Phot/sx100mAx0.05%BW at sample position (3-20 sec exposure time per frame) - MX-225 X-ray detector, 45mm-380mm distance from the sample, 30 deg 2-Theta possible - mardtb goniometer installed - 40-core XEON-CPU server, with fibre channel SAN up-link data processing environment - EDNA installed and available - Common MX-software installed including XDS, IMOSFLM, CCP4, Phenix, SHELXC-E, etc. - Automated data processing with XDSAPP available - Remotely controlled cryo-shutter for crystal annealing - Bruker AXS X-Flash XRF detector - Pressure chamber for noble gas derivatization (Xe, Kr available upon request) - Ultra high performance stereo microscope Leica M205A, 20-255x zoom, 8 Mpixel CCD-camera BL14.3 setup: - Photon flux: 4x10¹0 Phot/sx100mAx0.05%BW at sample position (3-20 sec exposure time per frame) - MX-225 X-ray detector, 45mm-380mm distance from the sample, 30 deg 2-Theta possible - mardtb goniometer installed - 40-core XEON-CPU server, with fibre channel SAN up-link data processing environment - EDNA installed and available - Common MX software installed including HKL2000, XDS, IMOSFLM, CCP4, Phenix, SHELXC-E, etc. - Automated data processing with ixds and xdsi available - Remotely controlled cryo-shutter for crystal annealing - HC-1c dehydration device installed, HC1-beamtime upon request - Pressure chamber for noble gas derivatization (Xe, Kr available upon request) - Ultra high performance stereo microscope Leica M205A, 20-255x zoom, 8 Mpixel CCD-camera S1-biolab facilities: - Protein production and purification - Nanoliter 96 well crystallization plate formulation and storage at 5 °C and 20 °C - Biophysical characterization with real time PCR (thermofluor assay) Please visit our web page www.helmholtz-berlin.de/bessy-mxhttp://www.helmholtz-berlin.de/bessy-mx to gain updated information about our experimental setup and other requirements. Uwe Mueller, Manfred Weiss and the HZB BESSY-MX group Dr. Uwe Mueller Soft Matter and Functional Materials Macromolecular Crystallography (BESSY-MX) | Group leader Elektronenspeicherring BESSY II Albert-Einstein-Str. 15, D-12489 Berlin, Germany Fon: +49 30 8062 14974 Fax: +49 30 8062 14975 url: www.helmholtz-berlin.de/bessy-mxhttp://www.helmholtz-berlin.de/bessy-mx email:u...@helmholtz-berlin.demailto:u...@helmholtz-berlin.de Helmholtz-Zentrum Berlin für Materialien und Energie GmbH Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V. Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas
Re: [ccp4bb] mmCIF as working format?
Apart from editors we also need tools to validate mmCIF files for integrity, similar to what W3C has for (x)html and css. I've mostly dealt with mmCIF reflection files so my experience with what can go wrong is limited. So far, I encountered these 'issues' that may be flagged. 1) Data items given twice with different values. This ambiguous, I suppose most parsers will use the last value given. 2) Values that should not occur for a specific data item. E.g. 19 in _refln.status 3) Proper closing of text blocks. 4) Things that can go in one loop, should go in one loop. I've seen examples where the Fmean and sigF are in one loop and I+ and I- are in another. It's not wrong, but annoying. 5) Proper space delimited values in loops. 6) Wrapping. Should this be allowed or not? I'm not a fan... 7) Data given in plain text or in new data items, even though proper data items exists. 8) Silly data such as negative amplitudes, suspiciously high values for h,k,l (such as 999), intensities between -180 and 180 There must be more things that could be checked. Cheers, Robbie Sent from my Windows Phone -Oorspronkelijk bericht- Van: Ethan Merritt Verzonden: 8-8-2013 2:28 Aan: CCP4BB@JISCMAIL.AC.UK Onderwerp: Re: [ccp4bb] mmCIF as working format?
[ccp4bb] PhD program at the Free University of Bolzano (Italy)
Dear All, a new call for applicants for a PhD fellowship at the Free University of Bolzano is now out. Please follow the link http://www.unibz.it/en/public/research/phd/Documents/bando_dottorati_29esimo_ciclo_en.pdf A suitable candidate will be selected for a position in my group at the Faculty of Science and Technology PhD programme in MOUNTAIN ENVIRONMENTS AND AGRICULTURE Website: http://www.unibz.it/en/sciencetechnology/progs/phd/phdmountainenvironment/default.html The following two projects are available for the selected candidate 1)Biomolecular characterization of proteins from Erwinia amylovora's amylovoran biosynthetic pathway 2)Biomolecular characterization of proteins from Erwinia amylovora's bacteriophages. How to fight fire blight using its natural killer. candidate interested are welcome to contact me for information bust MUST apply following the rules and links as specified in the call other links http://www.unibz.it/en/public/research/phd/prospectivePhdstudents.html pre-enrole here: https://aws.unibz.it/exup/en/Account/Logon?ReturnUrl=%2fexup%2fen%2fHome%2fIndex Please note that Bolzano is located near the UNESCO site of the Dolomites with some of the best hiking paths and slopes for skiing. http://whc.unesco.org/en/list/1237/ http://www.obereggen.com/en/winter_activities/ with my best regards Dr Stefano Benini, Ph.D. Assistant Professor http://pro.unibz.it/staff2/sbenini/ I don't like anything that's fake and I hate pretenders! Sir Arthur Thispairof * Bioorganic chemistry and Bio-Crystallography laboratory (B2Cl) Faculty of Science and Technology Free University of Bolzano Piazza Università, 5 39100 Bolzano, Italy Office (room K2.14): +39 0471 017128 Laboratory (room E.021): +39 0471 017910 Fax: +39 0471 017009
Re: [ccp4bb] Problems with SANS data analysis
I agree with Ed's suggestion - the folks on that forum are very helpful and very insightful with regards to small-angle scattering. Some thoughts to offer: Mark - it's hard to evaluate from the Primus screen shots, simply because Primus is not rendering the experimental noise. I'd suggesting plotting your data out on a log-log plot in Origin or via the Igor Pro macros if this data is from an American beamline (NIST, ORNL) and using those renderings to evaluate. Rendering the experimental noise is important, as in those middle D2O concentrations you're going to have a considerable amount of incoherent scatter contributing to your profiles. In your first 30% data shown, the discrepancy is concerning. Check the reduction parameters and make sure the correct correction files were used for that particular sample to detector distance. The rendering of the experimental noise would be helpful in evaluating. In your 50% and 70% data, the experimental noise would be helpful to evaluate, but on the whole they seem pretty good. The discrepancy seen at middle Q in this profile (http://postimg.org/image/m358pazb7/) is a little concerning though. I'm concerned with the first set of 90% data you show, assuming the incoherent scatter is very low at that concentration of D20 and signal-to-noise is high. There seems to be a discrepancy in the middle Q regime (~0.15 Q) Again, might be worth double-checking the correction files used for reduction. HTH, Kushol Kushol Gupta, Ph.D. Research Associate - Van Duyne Laboratory Perelman School of Medicine University of Pennsylvania BLOCKED::mailto:kgu...@stwing.upenn.edu kgu...@mail.med.upenn.edu 215-573-7260 / 267-259-0082 From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Ed Pozharski Sent: Wednesday, August 07, 2013 11:54 AM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Problems with SANS data analysis This question may be better suited for more small-angle-oriented forum, e.g. http://www.saxier.org/forum/ On 08/07/2013 11:22 AM, Remec, Mark wrote: Dear CCP4bb, I have a few questions concerning SANS data recently collected that I'm having trouble analyzing. The data was collected at 2 different detector distances (4m, 2.5m) to achieve higher q-range, but I worry that the curves don't overlap enough at intermediate q, which might indicate a problem with the data. The links below are pictures of the corresponding datasets, before truncating the 4m high-q data and merging them into one. Is there a problem evident with the data, or am I imagining a problem? http://postimg.org/image/qb00y20qr/ http://postimg.org/image/8trbp7akj/ http://postimg.org/image/hni86axj7/ http://postimg.org/image/3sjxnu343/ http://postimg.org/image/4ysj0dgsj/ http://postimg.org/image/9ypz8bmf7/ http://postimg.org/image/m358pazb7/ http://postimg.org/image/jzuthmzib/ My second question concerns the values obtained in the analysis of the final scattering curves. The second sample in my experiment shows serious deviation in the values obtained for I(0) and Rg by Guinier analysis compared to the values obtained by the P(r) analysis. In other words, either the P(r) values match the Guinier and the P(r) fit is terrible, or else the P(r) fit is good but doesn't match the Guinier at all (5-10 difference in Rg, 2x difference in I(0)). I've checked to make sure the buffer subtraction algorithm was OK, and I'm pretty certain that the buffers were exact matches, so I don't know how to explain this variation. There's no evidence of aggregation or polydispersity to throw off the values, either. Does anyone know how this can happen? -- Oh, suddenly throwing a giraffe into a volcano to make water is crazy? Julian, King of Lemurs
Re: [ccp4bb] Advice on setting up / maintaining a Ubuntu cluster
I wanted to thank everyone who responded, for a whole bunch of advice and suggestions! Sergei On 29-Jul-13 12:22 PM, Sergei Strelkov wrote: Dear all, In old times I, just like about any protein crystallographer, used to work on a cluster of SGI/IRIX workstations with complete NFS-based cross-mounting of hard disks. A typical operation included: 1. A single home directory location for every user: if my home directory was on workstation X, I would by default use it after logging on any of the workstations in the cluster. 2. A single location for all software for general use. (And, obviously, 3. The ability to log on any node from any terminal; today this is done via the 'ssh -X' command). I wondered if someone could give us an advice on a painless setup enabling 1. and 2., for a small cluster of Ubuntu computers. We (will) have about five similar Dell computers in a local (192.168.*.*) network (wired/wireless). Any tips on the hardware (especially the LAN and network disks) are also welcome. Many thanks, Sergei -- Prof. Sergei V. Strelkov Laboratory for Biocrystallography Dept of Pharmaceutical and Pharmacological Sciences, KU Leuven Herestraat 49 bus 822, 3000 Leuven, Belgium Work phone: +32 16 330845 Mobile: +32 486 294132 Lab pages: http://pharm.kuleuven.be/anafar
Re: [ccp4bb] mmCIF as working format?
On 8/7/13 8:27 PM, Ethan Merritt wrote: That would be a bug. But it hasn't been true for any version of coot that I have used. As you say, this is a common thing to do and I am certain I would have noticed if it didn't work. I just checked that it isn't true for 0.7.1-pre. Thanks. Turns out I'm using 0.7 and 0.7-pre on the octacore Mac and the laptop I use for building - slightly different versions updated at different times. I'll change versions. Apropos the other point I invariably do segment reordering via xemacs cut and paste although clearly Peek2 needs a reorder command. Phil
Re: [ccp4bb] mmCIF as working format?
Tim, I'm sure your email was tongue-in-check, but it's provocative nevertheless. I suspect that Nat's point was that scientific software developers (who are predominantly scientists of course) are helpful people who want to see their field of research be successful. If it is possible to spend an hour writing a tool that helps several thousand researchers to do their work that's probably a valuable use of time. An enlightened funding agency might even see the value! Sometimes it's a challenge to figure out exactly what would be of most help, hence Nat's plea for input. I don't know about other software development efforts, but we're very happy to get ideas and suggestions from researchers - just don't assume that we can implement them all (by tomorrow)! Cheers, Paul On Aug 8, 2013, at 12:17 AM, Tim Gruene t...@shelx.uni-ac.gwdg.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/07/2013 11:54 PM, Nat Echols wrote: PLEASE tell the developers what you need to get your job done; we can't read minds. -Nat Dear Nat, I have a student working for me until the end of the month. I asked her to calculate the mean ratio of U(H)/U(X) where X is the atom the corresponding hydrogen is bound to. I would like her to group together as follows: 1) all N-H and O-H within that protein 2) all Calpha-Halpha 3) all remaining C-H bonds 4) all O-H from the H2O and H3O in the structure. I am not sure whom to address this request to, so please forward it to the developer. If the could would actually work on a shelxl res-file it would be brilliant. I shall not ask George for this software because as a scientist he has much more important and much more general problems to work on than this. At the moment the person is doing it by hand which might take a day. So if you could return the code by tomorrow that would be nice. Out of the tens of thousands of crystallographers coming up with funny ideas (because, yes, you cannot read minds) you might receive such requests several times a day. And you seriously think this is the way we should go? Bless your funding agencies. Cheers, Tim P.S.: I found this discussing about mmCIF quite interesting, and since I was reminded that mmCIF is still kind of line oriented, I am pretty relieved. I just don't think that a 'universal' API exists - the student I am talking about does not know any programming language at all, and the next student might require an API in scheme, ruby, java, C#++-3.141, fortran-123, ... - -- - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFSA0YIUxlJ7aRr7hoRApyzAJ94tzJVf81vOggf7KO9SEwoidUz2QCcCkwQ 9IB2FlSTW7oiMP21vUP7QsY= =dGz8 -END PGP SIGNATURE- -- Paul Adams Deputy Division Director, Physical Biosciences Division, Lawrence Berkeley Lab Division Deputy for Biosciences, Advanced Light Source, Lawrence Berkeley Lab Adjunct Professor, Department of Bioengineering, U.C. Berkeley Vice President for Technology, the Joint BioEnergy Institute Laboratory Research Manager, ENIGMA Science Focus Area Building 64, Room 248 Building 80, Room 247 Building 978, Room 4126 Tel: 1-510-486-4225, Fax: 1-510-486-5909 http://cci.lbl.gov/paul Lawrence Berkeley Laboratory 1 Cyclotron Road BLDG 64R0121 Berkeley, CA 94720, USA. Executive Assistant: Louise Benvenue [ lbenve...@lbl.gov ][ 1-510-495-2506 ] --
Re: [ccp4bb] mmCIF as working format?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Paul, my email was meant to be provocative but neither insulting nor offensive (having provoked quite a few responses when I last used the word 'offense' this email does not suffer from a subtle misinterpretation of mine while not using my mothertongue. The German 'Provokation' is something a scientist would welcome since it is critism expressed in a rhetorically pleasing or intelectually amusing way, and criticism drives science forward). I am very grateful never to have met a non-helpful developer when I addressed one with a request or suggestion and I fully agree with you. I rather meant to point out that most developers are usually overwhelmed with work, suggestions, or ideas for improvements, and for that reason I think having formats that allow users to help themselves or each other (while of course they still can suggest their ideas to the developers) is a good thing, and having a format that only allows access through some API (or help from a developer) is not. I would also like to point out that my initial fear that we were moving away from such a format with the replacement of PDB with mmCIF has been soothened with this discussion and hence the content of my previous paragraph is deprecated w.r.t this thread's context. Regards, Tim On 08/08/2013 05:29 PM, Paul Adams wrote: Tim, I'm sure your email was tongue-in-check, but it's provocative nevertheless. I suspect that Nat's point was that scientific software developers (who are predominantly scientists of course) are helpful people who want to see their field of research be successful. If it is possible to spend an hour writing a tool that helps several thousand researchers to do their work that's probably a valuable use of time. An enlightened funding agency might even see the value! Sometimes it's a challenge to figure out exactly what would be of most help, hence Nat's plea for input. I don't know about other software development efforts, but we're very happy to get ideas and suggestions from researchers - just don't assume that we can implement them all (by tomorrow)! Cheers, Paul On Aug 8, 2013, at 12:17 AM, Tim Gruene t...@shelx.uni-ac.gwdg.de wrote: On 08/07/2013 11:54 PM, Nat Echols wrote: PLEASE tell the developers what you need to get your job done; we can't read minds. -Nat Dear Nat, I have a student working for me until the end of the month. I asked her to calculate the mean ratio of U(H)/U(X) where X is the atom the corresponding hydrogen is bound to. I would like her to group together as follows: 1) all N-H and O-H within that protein 2) all Calpha-Halpha 3) all remaining C-H bonds 4) all O-H from the H2O and H3O in the structure. I am not sure whom to address this request to, so please forward it to the developer. If the could would actually work on a shelxl res-file it would be brilliant. I shall not ask George for this software because as a scientist he has much more important and much more general problems to work on than this. At the moment the person is doing it by hand which might take a day. So if you could return the code by tomorrow that would be nice. Out of the tens of thousands of crystallographers coming up with funny ideas (because, yes, you cannot read minds) you might receive such requests several times a day. And you seriously think this is the way we should go? Bless your funding agencies. Cheers, Tim P.S.: I found this discussing about mmCIF quite interesting, and since I was reminded that mmCIF is still kind of line oriented, I am pretty relieved. I just don't think that a 'universal' API exists - the student I am talking about does not know any programming language at all, and the next student might require an API in scheme, ruby, java, C#++-3.141, fortran-123, ... - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFSA8/4UxlJ7aRr7hoRAkzkAJ9ZLVYbzRQKerwADyH3c9nkqd44EwCeMlLD iDGIYVZuI1YDhgbyaWtOJkQ= =cwrn -END PGP SIGNATURE-
[ccp4bb] TLS refinement and ANISOU records
Dear all, I was about to deposit a few structures to the pdb when I noticed the mean B-factors were larger than one might expect. All the structures were refined using TLS refinement. During refinement in Refmac the average temperature factors for each structure is reasonable. For example, a structure at 2.75Å has a mean B-factor of 40; however, after adding the ANISOU records as required by the PDB, I noticed the average B-factors double. Is this normal? Sincerely, Omid --- --- Omid Haji-Ghassemi, Graduate Student Department of Biochemistry Microbiology University of Victoria PO Box 3055 STN CSC Victoria, BC, V8W 3P6 CANADA Tel:250-721-8945 Fax:250-721-8855
Re: [ccp4bb] TLS refinement and ANISOU records
On Thursday, August 08, 2013 11:39:22 am Omid Haji-Ghassemi wrote: Dear all, I was about to deposit a few structures to the pdb when I noticed the mean B-factors were larger than one might expect. All the structures were refined using TLS refinement. During refinement in Refmac the average temperature factors for each structure is reasonable. For example, a structure at 2.75� has a mean B-factor of 40; however, after adding the ANISOU records as required by the PDB, I noticed the average B-factors double. Please see my paper: E. A. Merritt (2011). Some Beq are more equivalent than others. Acta Cryst. A67, 512-516. http://skuld.bmsc.washington.edu/parvati/ActaA_67_512.pdf In short, the quantity stored in the B field of a PDB file after TLS refinement is Beq, which overestimates what the isotropic B factor would have been if you had refined without TLS. So in general the average B after TLS refinement is always higher than the average B without TLS. The problem is that the two quantities marked average B are not directly comparable. Having said that, the overestimate is not usually as much as a factor of 2. So something else may indeed be causing a problem in your case. Ethan Is this normal? Sincerely, Omid --- --- Omid Haji-Ghassemi, Graduate Student Department of Biochemistry Microbiology University of Victoria PO Box 3055 STN CSC Victoria, BC, V8W 3P6 CANADA Tel:250-721-8945 Fax:250-721-8855 -- Ethan A Merritt Biomolecular Structure Center, K-428 Health Sciences Bldg University of Washington, Seattle 98195-7742
Re: [ccp4bb] TLS refinement and ANISOU records
Dear Ethan, Thank you for your reply. I will try to review my refinement protocol once more; however, I am still perplexed at what lies at the heart of the problem. Overestimation of average B-factor using TLS is perfectly sound, but I am not sure why all my structures the average increases tremendously. In one case it increases from 16.36 to 73.02 for a 2.3Ang structure. I already tried changing weights and number of TLS rounds, which resulting in only a small change in average B. Omid On Thursday, August 08, 2013 11:39:22 am Omid Haji-Ghassemi wrote: Dear all, I was about to deposit a few structures to the pdb when I noticed the mean B-factors were larger than one might expect. All the structures were refined using TLS refinement. During refinement in Refmac the average temperature factors for each structure is reasonable. For example, a structure at 2.75� has a mean B-factor of 40; however, after adding the ANISOU records as required by the PDB, I noticed the average B-factors double. Please see my paper: E. A. Merritt (2011). Some Beq are more equivalent than others. Acta Cryst. A67, 512-516. http://skuld.bmsc.washington.edu/parvati/ActaA_67_512.pdf In short, the quantity stored in the B field of a PDB file after TLS refinement is Beq, which overestimates what the isotropic B factor would have been if you had refined without TLS. So in general the average B after TLS refinement is always higher than the average B without TLS. The problem is that the two quantities marked average B are not directly comparable. Having said that, the overestimate is not usually as much as a factor of 2. So something else may indeed be causing a problem in your case. Ethan Is this normal? Sincerely, Omid --- --- Omid Haji-Ghassemi, Graduate Student Department of Biochemistry Microbiology University of Victoria PO Box 3055 STN CSC Victoria, BC, V8W 3P6 CANADA Tel:250-721-8945 Fax:250-721-8855 -- Ethan A Merritt Biomolecular Structure Center, K-428 Health Sciences Bldg University of Washington, Seattle 98195-7742
Re: [ccp4bb] TLS refinement and ANISOU records
Hi Omid, Sometimes the choice of TLS groups and to a lesser extent the initial B-factor matter a lot. You should try a few other TLS group selections and see if these give nicer results. Things to try: TLSMD, including or excluding ligands and carbohydrates, other common-sense or gut-feeling structure partitionings. If you have a lot of different groupings to test, you can reset the B-factor and do pure TLS refinement (i.e. 0 cycles of restrained refinement) for all of them. You can then use the best one for your 'final' refinement. It's much faster then trying your final refinement with all TLS groups selections. Cheers, Robbie Sent from my Windows Phone Van: Omid Haji-Ghassemi Verzonden: 8-8-2013 21:55 Aan: CCP4BB@JISCMAIL.AC.UK Onderwerp: Re: [ccp4bb] TLS refinement and ANISOU records Dear Ethan, Thank you for your reply. I will try to review my refinement protocol once more; however, I am still perplexed at what lies at the heart of the problem. Overestimation of average B-factor using TLS is perfectly sound, but I am not sure why all my structures the average increases tremendously. In one case it increases from 16.36 to 73.02 for a 2.3Ang structure. I already tried changing weights and number of TLS rounds, which resulting in only a small change in average B. Omid On Thursday, August 08, 2013 11:39:22 am Omid Haji-Ghassemi wrote: Dear all, I was about to deposit a few structures to the pdb when I noticed the mean B-factors were larger than one might expect. All the structures were refined using TLS refinement. During refinement in Refmac the average temperature factors for each structure is reasonable. For example, a structure at 2.75� has a mean B-factor of 40; however, after adding the ANISOU records as required by the PDB, I noticed the average B-factors double. Please see my paper: E. A. Merritt (2011). Some Beq are more equivalent than others. Acta Cryst. A67, 512-516. http://skuld.bmsc.washington.edu/parvati/ActaA_67_512.pdf In short, the quantity stored in the B field of a PDB file after TLS refinement is Beq, which overestimates what the isotropic B factor would have been if you had refined without TLS. So in general the average B after TLS refinement is always higher than the average B without TLS. The problem is that the two quantities marked average B are not directly comparable. Having said that, the overestimate is not usually as much as a factor of 2. So something else may indeed be causing a problem in your case. Ethan Is this normal? Sincerely, Omid --- --- Omid Haji-Ghassemi, Graduate Student Department of Biochemistry Microbiology University of Victoria PO Box 3055 STN CSC Victoria, BC, V8W 3P6 CANADA Tel:250-721-8945 Fax:250-721-8855 -- Ethan A Merritt Biomolecular Structure Center, K-428 Health Sciences Bldg University of Washington, Seattle 98195-7742
Re: [ccp4bb] TLS refinement and ANISOU records
Dear Robbie, Marcus and Reginald, Thanks again for your replies, I truly appreciate the help. The B-factors was set to 20 when performing TLS refinement so I don't think that is the problem. I also tried Marcus's suggestion using output from coot, with no luck. The only thing left to try is to test alternative TLS group as Reginald have suggested. Cheers Omid Hi Omid, Sometimes the choice of TLS groups and to a lesser extent the initial B-factor matter a lot. You should try a few other TLS group selections and see if these give nicer results. Things to try: TLSMD, including or excluding ligands and carbohydrates, other common-sense or gut-feeling structure partitionings. If you have a lot of different groupings to test, you can reset the B-factor and do pure TLS refinement (i.e. 0 cycles of restrained refinement) for all of them. You can then use the best one for your 'final' refinement. It's much faster then trying your final refinement with all TLS groups selections. Cheers, Robbie Sent from my Windows Phone Van: Omid Haji-Ghassemi Verzonden: 8-8-2013 21:55 Aan: CCP4BB@JISCMAIL.AC.UK Onderwerp: Re: [ccp4bb] TLS refinement and ANISOU records Dear Ethan, Thank you for your reply. I will try to review my refinement protocol once more; however, I am still perplexed at what lies at the heart of the problem. Overestimation of average B-factor using TLS is perfectly sound, but I am not sure why all my structures the average increases tremendously. In one case it increases from 16.36 to 73.02 for a 2.3Ang structure. I already tried changing weights and number of TLS rounds, which resulting in only a small change in average B. Omid On Thursday, August 08, 2013 11:39:22 am Omid Haji-Ghassemi wrote: Dear all, I was about to deposit a few structures to the pdb when I noticed the mean B-factors were larger than one might expect. All the structures were refined using TLS refinement. During refinement in Refmac the average temperature factors for each structure is reasonable. For example, a structure at 2.75� has a mean B-factor of 40; however, after adding the ANISOU records as required by the PDB, I noticed the average B-factors double. Please see my paper: E. A. Merritt (2011). Some Beq are more equivalent than others. Acta Cryst. A67, 512-516. http://skuld.bmsc.washington.edu/parvati/ActaA_67_512.pdf In short, the quantity stored in the B field of a PDB file after TLS refinement is Beq, which overestimates what the isotropic B factor would have been if you had refined without TLS. So in general the average B after TLS refinement is always higher than the average B without TLS. The problem is that the two quantities marked average B are not directly comparable. Having said that, the overestimate is not usually as much as a factor of 2. So something else may indeed be causing a problem in your case. Ethan Is this normal? Sincerely, Omid --- --- Omid Haji-Ghassemi, Graduate Student Department of Biochemistry Microbiology University of Victoria PO Box 3055 STN CSC Victoria, BC, V8W 3P6 CANADA Tel:250-721-8945 Fax:250-721-8855 -- Ethan A Merritt Biomolecular Structure Center, K-428 Health Sciences Bldg University of Washington, Seattle 98195-7742
Re: [ccp4bb] TLS refinement and ANISOU records
On Thursday, August 08, 2013 01:51:34 pm Omid Haji-Ghassemi wrote: Dear Robbie, Marcus and Reginald, Thanks again for your replies, I truly appreciate the help. The B-factors was set to 20 when performing TLS refinement so I don't think that is the problem. I also tried Marcus's suggestion using output from coot, with no luck. The only thing left to try is to test alternative TLS group as Reginald have suggested. You have only told us about an increase in average B, not whether it is uniformly inflated. Possibly the output from analysis by the Parvati server http://skuld.bmsc.washington.edu/parvati would indicate specific parts of your structure that are behaving badly during refinement. Ethan Cheers Omid Hi Omid, Sometimes the choice of TLS groups and to a lesser extent the initial B-factor matter a lot. You should try a few other TLS group selections and see if these give nicer results. Things to try: TLSMD, including or excluding ligands and carbohydrates, other common-sense or gut-feeling structure partitionings. If you have a lot of different groupings to test, you can reset the B-factor and do pure TLS refinement (i.e. 0 cycles of restrained refinement) for all of them. You can then use the best one for your 'final' refinement. It's much faster then trying your final refinement with all TLS groups selections. Cheers, Robbie Sent from my Windows Phone Van: Omid Haji-Ghassemi Verzonden: 8-8-2013 21:55 Aan: CCP4BB@JISCMAIL.AC.UK Onderwerp: Re: [ccp4bb] TLS refinement and ANISOU records Dear Ethan, Thank you for your reply. I will try to review my refinement protocol once more; however, I am still perplexed at what lies at the heart of the problem. Overestimation of average B-factor using TLS is perfectly sound, but I am not sure why all my structures the average increases tremendously. In one case it increases from 16.36 to 73.02 for a 2.3Ang structure. I already tried changing weights and number of TLS rounds, which resulting in only a small change in average B. Omid On Thursday, August 08, 2013 11:39:22 am Omid Haji-Ghassemi wrote: Dear all, I was about to deposit a few structures to the pdb when I noticed the mean B-factors were larger than one might expect. All the structures were refined using TLS refinement. During refinement in Refmac the average temperature factors for each structure is reasonable. For example, a structure at 2.75� has a mean B-factor of 40; however, after adding the ANISOU records as required by the PDB, I noticed the average B-factors double. Please see my paper: E. A. Merritt (2011). Some Beq are more equivalent than others. Acta Cryst. A67, 512-516. http://skuld.bmsc.washington.edu/parvati/ActaA_67_512.pdf In short, the quantity stored in the B field of a PDB file after TLS refinement is Beq, which overestimates what the isotropic B factor would have been if you had refined without TLS. So in general the average B after TLS refinement is always higher than the average B without TLS. The problem is that the two quantities marked average B are not directly comparable. Having said that, the overestimate is not usually as much as a factor of 2. So something else may indeed be causing a problem in your case. Ethan Is this normal? Sincerely, Omid --- --- Omid Haji-Ghassemi, Graduate Student Department of Biochemistry Microbiology University of Victoria PO Box 3055 STN CSC Victoria, BC, V8W 3P6 CANADA Tel:250-721-8945 Fax:250-721-8855 -- Ethan A Merritt Biomolecular Structure Center, K-428 Health Sciences Bldg University of Washington, Seattle 98195-7742 -- Ethan A Merritt Biomolecular Structure Center, K-428 Health Sciences Bldg University of Washington, Seattle 98195-7742
[ccp4bb] Substrate/Ligand Induced Oligomerization of enzymes
Dear All, I am looking for references and/or example of substrate or ligand induced oligomerization of enzymes related to activation. Any help in this regard would be greatly appreciated. Thanks. Shiva
Re: [ccp4bb] Substrate/Ligand Induced Oligomerization of enzymes
FKBP ? http://www.pnas.org/content/97/13/7096.full.pdf Jürgen On Aug 8, 2013, at 8:03 PM, Shiva Bhowmik wrote: Dear All, I am looking for references and/or example of substrate or ligand induced oligomerization of enzymes related to activation. Any help in this regard would be greatly appreciated. Thanks. Shiva .. Jürgen Bosch Johns Hopkins University Bloomberg School of Public Health Department of Biochemistry Molecular Biology Johns Hopkins Malaria Research Institute 615 North Wolfe Street, W8708 Baltimore, MD 21205 Office: +1-410-614-4742 Lab: +1-410-614-4894 Fax: +1-410-955-2926 http://lupo.jhsph.edu
Re: [ccp4bb] Substrate/Ligand Induced Oligomerization of enzymes
Jaffe's morpheeins might be of interest to you. Here is one paper: http://www.ncbi.nlm.nih.gov/pubmed/15710608 Sent from Jack's iPad On Aug 8, 2013, at 7:21 PM, Shiva Bhowmik gene1...@gmail.com wrote: Dear All, I am looking for references and/or example of substrate or ligand induced oligomerization of enzymes related to activation. Any help in this regard would be greatly appreciated. Thanks. Shiva
