[ccp4bb] mar345 version of generate_XDS.INP
Dear all, sorry for the slightly off-topic question: Does anyone have a modified version of generate_XDS.INP for the mar345 image plate detector? I know I could -relative easily- make it on my own, but why inventing the wheel twice? Regards, Jan -- Dr. Jan Gebauer AG Prof. Baumann Institut für Biochemie / Uni-Köln Otto-Fischer-Str. 12-14 / 50674 Köln Fon: +49 (221) 470 3212 Fax: +49 (221) 470 5066 http://px.uni-koeln.de/
Re: [ccp4bb] mar345 version of generate_XDS.INP
Dear all, thanks to all for your first responses; however, I probably wasn't precise enough in my original message. I DO have an XDS.INP for the mar345 image plate (and i also now where to find the others). What I would like to have is a modified version of Kay Diederichs generate_XDS.INP script, to generate XDS.INPs automatically... It's very handy if you have datasets from multiple detectors. (here the wiki: http://strucbio.biologie.uni-konstanz.de/xdswiki/index.php/Generate_XDS.INP) Best, Jan Am 21.06.2013, 10:23 Uhr, schrieb Jan Gebauer ccp...@science.jan-gebauer.de: Dear all, sorry for the slightly off-topic question: Does anyone have a modified version of generate_XDS.INP for the mar345 image plate detector? I know I could -relative easily- make it on my own, but why inventing the wheel twice? Regards, Jan -- Dr. Jan Gebauer AG Prof. Baumann Institut für Biochemie / Uni-Köln Otto-Fischer-Str. 12-14 / 50674 Köln Fon: +49 (221) 470 3212 Fax: +49 (221) 470 5066 http://px.uni-koeln.de/
Re: [ccp4bb] NAG-NAG
Hello, Monika, 1) Add NAGs 2) Remove their hydrogens and O1 atom and put them in density 3) In menu: Calculate-merge molecules, choose your pdb and both NAG residues 4) save coordinate file 2013/6/20 Monika Pathak m.pat...@nottingham.ac.uk Hi Please can I ask about how can I put NAG to asparagine in coot (I think its 2NAG that I can put in density) and if possible to refine it in refmac then. Thanks in advance for help Regards Monika Monika Pathak University of Nottingham NG7 2RD This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. -- Eugene Osipov Junior Research Scientist Laboratory of Enzyme Engineering A.N. Bach Institute of Biochemistry Russian Academy of Sciences Leninsky pr. 33, 119071 Moscow, Russia e-mail: e.m.osi...@gmail.com
Re: [ccp4bb] PIMS XtalView Help
Hello Everyone, I'm looking for a group/person that has PIMS and Xtailpims installed which does not throw Java errors while using the program. I've been struggling to get the program to work without error trying different versions of the below programs. I believe PIMS and Xtalpims has potential for my group so I looking for outside help. I need to know the following, with no errors, to make sure my setup is correct: Java Version Tomcat Version Windows or Linux version Apache Version Thanks in advance. Dwayne Dwayne McCully Structural Biology Section, NIAID, NIH Contractor
[ccp4bb] Postdoctoral position at Humboldt University Berlin and Helmholtz Zentrum Berlin (BESSY II)
The Helmholtz Zentrum Berlin für Materialien und Energie, the Max-Delbrück-Center, the Freie Universität Berlin and the Humboldt Universität zu Berlin jointly operate three experimental stations for bio-macromolecular crystallography at BESSY II, one of the world’s most modern synchrotron radiation sources for VUV and soft X-rays. The Institute of Biology of the Humboldt-Universität zu Berlin is seeking a Post Doctoral Research Assistant to conduct research on enzymes involved in the energy metabolism at the Laboratory for Structural Biology / Biochemistry (headed by Prof. Dr. Holger Dobbek) of the Humboldt-Universität zu Berlin. The successful candidate will also be involved in the operation of the BESSY II bio-macromolecular crystallography beamlines (headed by Dr. Uwe Müller Dr. Manfred Weiss) and will take part in graduate student education. Initially, a three-year contract will be offered to the successful candidate with the possibility for an extension. The salary will be based on German Federal TVöD (i.d.F.d. Anw.-TV HUB). The position is available immediately and applications will be considered until the position is filled. Applicants should hold a Ph.D. in the biological, chemical or physical sciences and have a background in bio-macromolecular crystallography, biochemistry or computational chemistry. The position also requires the documented ability to conduct independent research as well as excellent communication and interpersonal skills. Please send your application (CV, list of publications, 2 referees, .pdf-file format) in electronic form until July 12, 2013, with the Code DR/075/13 to: Dr. Uwe Müller Helmholtz-Zentrum Berlin / BESSY II Albert-Einstein-Str. 15, 12489 Berlin Dr. Uwe Mueller Fon: +49 30 8062 14974 Fax: +49 30 8062 14975 url: www.helmholtz-berlin.de/bessy-mx email: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 Frederking Sitz Berlin, AG Charlottenburg, 89 HRB 5583 Postadresse: Hahn-Meitner-Platz 1 D-14109 Berlin http://www.helmholtz-berlin.de
[ccp4bb] AW: Twinning problem - almost solved.
Dear Bulletin Board, After some headbanging (Refmac5 had helpfully created gap records for all insertions and deletions present in the structure), I got refmac5 running with the TWIN option. Refmac5 also found the k,h,-l domain and rejected the other possible domains because they were too small. The Rfactor's are now extremely good: ~14% and the Rfree's are for me acceptable: ~24%. Since I found the difference between R and Rfree somewhat large, I have been playing with the weighting. By using a weight of 0.01, I can bring the Rfactor up to 18%, but the Rfree stays about the same or even gets a little worse. My question: is there a way to bring R and Rfree closer together, or is it related to the twinned data and is it something we have to live with? Best regards, Herman -Ursprüngliche Nachricht- Von: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] Im Auftrag von Miller, Mitchell D. Gesendet: Donnerstag, 20. Juni 2013 17:43 An: CCP4BB@JISCMAIL.AC.UK Betreff: Re: [ccp4bb] Twinning problem You are welcome. Let me also for the benefit of others who may search the archives in the future, let me correct two errors below - (typo and a miss-recollection). Specially, I was thinking that phenix.refine was now able to refine multiple twin laws, but according to Nat Echols on the phenix mailing list http://phenix-online.org/pipermail/phenixbb/2013-March/019538.html phenix.refine only handles 1 twin law at this time. (My typo was that and our second structure was 3nuz with twin fractions 0.38, 0.32, 0.16 and 0.14 -- not 2nuz). A useful search for deposited structures mentioning tetartohedral http://www.ebi.ac.uk/pdbe-srv/view/search?search_type=all_texttext=TETARTOHEDRALLY+OR+TETARTOHEDRAL Regards, Mitch -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of herman.schreu...@sanofi.com Sent: Thursday, June 20, 2013 8:04 AM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] AW: Twinning problem Dear Mitch (and Philip and Phil), It is clear that I should give refmac a go with the non-detwinned F's and just the TWIN command. Thank you for your suggestions, Herman -Ursprüngliche Nachricht- Von: Miller, Mitchell D. [mailto:mmil...@slac.stanford.edu] Gesendet: Donnerstag, 20. Juni 2013 16:18 An: Schreuder, Herman RD/DE Betreff: RE: Twinning problem Hi Herman, Have you considered the possibility of your crystals being tetartohedral twinned. That is more than one of the twin laws may apply to your crystals. E.g. in P32 it is possible to have tetartohedral twinning which would have 4 twin domains - (h,k,l), (k,h,-l), (-h,-k,l) and (-k,-h,-l). Perfect tetartohedral twinning of P3 would merge in P622 and each twin domain would have a faction of 0.25. We have had 2 cases like this (the first 2PRX was before there was support for this type of twinning except for in shelxl and we ended up with refined twin fractions of 0.38, 0.28, 0.19, 0.15 for the deposited crystal and a 2nd crystal that we did not deposit had twin fractions of 0.25, 0.27, 0.17, 0.31). The 2nd case we had was after support for twining (including tetartohedral twinning) was added to refmac (and I think phenix.refine can also handle this). For 2NUZ, it was P32 with refined twin fractions of 0.25, 0.27, 0.17, 0.31. Pietro Roversi wrote a review of tetartohedral twinning for the CCP4 proceedings issues of acta D http://dx.doi.org/10.1107/S0907444912006737 I would try refinement with refmac using the original (non-detwinned F's) with just the TWIN command to see if it ends up keeping twin fractions for all 3 operators (4 domains) -- especially with crystals 1 and 3 which appear to have the largest estimates of the other twin fractions. Regards, Mitch == Mitchell Miller, Ph.D. Joint Center for Structural Genomics Stanford Synchrotron Radiation Lightsource 2575 Sand Hill Rd -- SLAC MS 99 Menlo Park, CA 94025 Phone: 1-650-926-5036 FAX: 1-650-926-3292 -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of herman.schreu...@sanofi.com Sent: Thursday, June 20, 2013 6:47 AM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] Twinning problem Dear Bulletin Board, Prodded by pdb annotators, which are very hesitant to accept coordinate files when their Rfactor does not correspond with our Rfactor, I had a look again into some old data sets, which I suspect are twinned. Below are the results of some twinning tests with the Detwin program (top value: all reflections, lower value: reflections Nsig*obs (whatever that may mean). The space group is P32, the resolution is 2.3 - 2.6 Å and data are reasonable complete: 95 - 100%. From the Detwin analysis, it seems that the crystals are twinned with twin operator k,h,-l with a twinning fraction of 0.3 for crystal 1, 0.15 for crystal 2 and 0.4 for crystal 3. Crystal 2 can be refined while ignoring twinning to get
Re: [ccp4bb] NAG-NAG
On 06/20/2013 06:56 PM, Monika Pathak wrote: Hi Please can I ask about how can I put NAG to asparagine in coot (I think its 2NAG that I can put in density) and if possible to refine it in refmac then. Calculate - Scripting - Scheme: (add-linked-residue imol chain-id res-no ins-code NAG NAG-ASN) for some value of imol, chain-id, res-no and ins-code of course. HTH, Paul.
Re: [ccp4bb] AW: Twinning problem - almost solved.
I have found PDB_REDO is an efficient way of tweaking structure solutions. Among other things, it sorts through various MATRIX and BFAC weights and tests effectiveness of TLS if not used already. It usually improves typical final structure solutions for our group by about 1% or so Rfree and reduces the Rfree-R spread, as well as improves a variety of other structural measures. You can of course adjust weights and TLS manually, but if you can get a local version of PDB_REDO running it saves a lot of time, and has some extra features. I've modified v. 5.0.9 for this purpose. Depending on the packages you do or don't have, it is a little tricky to get running locally. Roger Rowlett On Jun 21, 2013 4:42 AM, herman.schreu...@sanofi.com wrote: Dear Bulletin Board, After some headbanging (Refmac5 had helpfully created gap records for all insertions and deletions present in the structure), I got refmac5 running with the TWIN option. Refmac5 also found the k,h,-l domain and rejected the other possible domains because they were too small. The Rfactor's are now extremely good: ~14% and the Rfree's are for me acceptable: ~24%. Since I found the difference between R and Rfree somewhat large, I have been playing with the weighting. By using a weight of 0.01, I can bring the Rfactor up to 18%, but the Rfree stays about the same or even gets a little worse. My question: is there a way to bring R and Rfree closer together, or is it related to the twinned data and is it something we have to live with? Best regards, Herman -Ursprüngliche Nachricht- Von: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] Im Auftrag von Miller, Mitchell D. Gesendet: Donnerstag, 20. Juni 2013 17:43 An: CCP4BB@JISCMAIL.AC.UK Betreff: Re: [ccp4bb] Twinning problem You are welcome. Let me also for the benefit of others who may search the archives in the future, let me correct two errors below - (typo and a miss-recollection). Specially, I was thinking that phenix.refine was now able to refine multiple twin laws, but according to Nat Echols on the phenix mailing list http://phenix-online.org/pipermail/phenixbb/2013-March/019538.html phenix.refine only handles 1 twin law at this time. (My typo was that and our second structure was 3nuz with twin fractions 0.38, 0.32, 0.16 and 0.14 -- not 2nuz). A useful search for deposited structures mentioning tetartohedral http://www.ebi.ac.uk/pdbe-srv/view/search?search_type=all_texttext=TETARTOHEDRALLY+OR+TETARTOHEDRAL Regards, Mitch -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of herman.schreu...@sanofi.com Sent: Thursday, June 20, 2013 8:04 AM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] AW: Twinning problem Dear Mitch (and Philip and Phil), It is clear that I should give refmac a go with the non-detwinned F's and just the TWIN command. Thank you for your suggestions, Herman -Ursprüngliche Nachricht- Von: Miller, Mitchell D. [mailto:mmil...@slac.stanford.edu] Gesendet: Donnerstag, 20. Juni 2013 16:18 An: Schreuder, Herman RD/DE Betreff: RE: Twinning problem Hi Herman, Have you considered the possibility of your crystals being tetartohedral twinned. That is more than one of the twin laws may apply to your crystals. E.g. in P32 it is possible to have tetartohedral twinning which would have 4 twin domains - (h,k,l), (k,h,-l), (-h,-k,l) and (-k,-h,-l). Perfect tetartohedral twinning of P3 would merge in P622 and each twin domain would have a faction of 0.25. We have had 2 cases like this (the first 2PRX was before there was support for this type of twinning except for in shelxl and we ended up with refined twin fractions of 0.38, 0.28, 0.19, 0.15 for the deposited crystal and a 2nd crystal that we did not deposit had twin fractions of 0.25, 0.27, 0.17, 0.31). The 2nd case we had was after support for twining (including tetartohedral twinning) was added to refmac (and I think phenix.refine can also handle this). For 2NUZ, it was P32 with refined twin fractions of 0.25, 0.27, 0.17, 0.31. Pietro Roversi wrote a review of tetartohedral twinning for the CCP4 proceedings issues of acta D http://dx.doi.org/10.1107/S0907444912006737 I would try refinement with refmac using the original (non-detwinned F's) with just the TWIN command to see if it ends up keeping twin fractions for all 3 operators (4 domains) -- especially with crystals 1 and 3 which appear to have the largest estimates of the other twin fractions. Regards, Mitch == Mitchell Miller, Ph.D. Joint Center for Structural Genomics Stanford Synchrotron Radiation Lightsource 2575 Sand Hill Rd -- SLAC MS 99 Menlo Park, CA 94025 Phone: 1-650-926-5036 FAX: 1-650-926-3292 -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of herman.schreu...@sanofi.com Sent: Thursday, June 20, 2013 6:47 AM To:
Re: [ccp4bb] AW: Twinning problem - almost solved.
At your resolution that seems to me a reasonable gap between R and Rfree? Eleanor On 21 Jun 2013, at 12:28, herman.schreu...@sanofi.com wrote: Dear Bulletin Board, After some headbanging (Refmac5 had helpfully created gap records for all insertions and deletions present in the structure), I got refmac5 running with the TWIN option. Refmac5 also found the k,h,-l domain and rejected the other possible domains because they were too small. The Rfactor's are now extremely good: ~14% and the Rfree's are for me acceptable: ~24%. Since I found the difference between R and Rfree somewhat large, I have been playing with the weighting. By using a weight of 0.01, I can bring the Rfactor up to 18%, but the Rfree stays about the same or even gets a little worse. My question: is there a way to bring R and Rfree closer together, or is it related to the twinned data and is it something we have to live with? Best regards, Herman -Ursprüngliche Nachricht- Von: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] Im Auftrag von Miller, Mitchell D. Gesendet: Donnerstag, 20. Juni 2013 17:43 An: CCP4BB@JISCMAIL.AC.UK Betreff: Re: [ccp4bb] Twinning problem You are welcome. Let me also for the benefit of others who may search the archives in the future, let me correct two errors below - (typo and a miss-recollection). Specially, I was thinking that phenix.refine was now able to refine multiple twin laws, but according to Nat Echols on the phenix mailing list http://phenix-online.org/pipermail/phenixbb/2013-March/019538.html phenix.refine only handles 1 twin law at this time. (My typo was that and our second structure was 3nuz with twin fractions 0.38, 0.32, 0.16 and 0.14 -- not 2nuz). A useful search for deposited structures mentioning tetartohedral http://www.ebi.ac.uk/pdbe-srv/view/search?search_type=all_texttext=TETARTOHEDRALLY+OR+TETARTOHEDRAL Regards, Mitch -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of herman.schreu...@sanofi.com Sent: Thursday, June 20, 2013 8:04 AM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] AW: Twinning problem Dear Mitch (and Philip and Phil), It is clear that I should give refmac a go with the non-detwinned F's and just the TWIN command. Thank you for your suggestions, Herman -Ursprüngliche Nachricht- Von: Miller, Mitchell D. [mailto:mmil...@slac.stanford.edu] Gesendet: Donnerstag, 20. Juni 2013 16:18 An: Schreuder, Herman RD/DE Betreff: RE: Twinning problem Hi Herman, Have you considered the possibility of your crystals being tetartohedral twinned. That is more than one of the twin laws may apply to your crystals. E.g. in P32 it is possible to have tetartohedral twinning which would have 4 twin domains - (h,k,l), (k,h,-l), (-h,-k,l) and (-k,-h,-l). Perfect tetartohedral twinning of P3 would merge in P622 and each twin domain would have a faction of 0.25. We have had 2 cases like this (the first 2PRX was before there was support for this type of twinning except for in shelxl and we ended up with refined twin fractions of 0.38, 0.28, 0.19, 0.15 for the deposited crystal and a 2nd crystal that we did not deposit had twin fractions of 0.25, 0.27, 0.17, 0.31). The 2nd case we had was after support for twining (including tetartohedral twinning) was added to refmac (and I think phenix.refine can also handle this). For 2NUZ, it was P32 with refined twin fractions of 0.25, 0.27, 0.17, 0.31. Pietro Roversi wrote a review of tetartohedral twinning for the CCP4 proceedings issues of acta D http://dx.doi.org/10.1107/S0907444912006737 I would try refinement with refmac using the original (non-detwinned F's) with just the TWIN command to see if it ends up keeping twin fractions for all 3 operators (4 domains) -- especially with crystals 1 and 3 which appear to have the largest estimates of the other twin fractions. Regards, Mitch == Mitchell Miller, Ph.D. Joint Center for Structural Genomics Stanford Synchrotron Radiation Lightsource 2575 Sand Hill Rd -- SLAC MS 99 Menlo Park, CA 94025 Phone: 1-650-926-5036 FAX: 1-650-926-3292 -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of herman.schreu...@sanofi.com Sent: Thursday, June 20, 2013 6:47 AM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] Twinning problem Dear Bulletin Board, Prodded by pdb annotators, which are very hesitant to accept coordinate files when their Rfactor does not correspond with our Rfactor, I had a look again into some old data sets, which I suspect are twinned. Below are the results of some twinning tests with the Detwin program (top value: all reflections, lower value: reflections Nsig*obs (whatever that may mean). The space group is P32, the resolution is 2.3 - 2.6 Å and data are reasonable
Re: [ccp4bb] Puzzling observation about size exclusion chromatography
Dear Zhen, I should also point out that the statement Matt made (Superdex is known to have some ion-exchange characteristics, so that it can weakly interact with some proteins.) is not completely correct. Superdex and all chromatographic media made from carbohydrates (dextran, agarose, etc.) are also quite hydrophobic (which is surprising to some). The observation Zhen made is the classic behavior of hydrophobic interaction with the gel filtration media, which led to the development of hydrophobic interaction chromatographic (HIC). For HIC, you load the protein in high salt, and elute with low salt or a chaotrope (LiCl). So when you redo you experiment, Zhen, try with AND without salt. As Matt said, if it is an ion-exchange interaction, extra salt will make it elute more normally. But if it gets worse, then the extra salt is increasing the hydrophobic interactions, and you should run the column in lower salt (~50 mM NaCl) or with a bit of detergent. Given that you are refolding your protein, a partially folded protein may have have more hydrophobic patches. As my lab is routinely refolding our target proteins, we are always watching for this behavior, including on our analytical Superdex 200 10/300 columns, which is one of our favorites. Excessive hydrophobic interactions can also lead to clogged columns, which is not what you want for this expensive column. Good luck, Michael R. Michael Garavito, Ph.D. Professor of Biochemistry Molecular Biology 603 Wilson Rd., Rm. 513 Michigan State University East Lansing, MI 48824-1319 Office: (517) 355-9724 Lab: (517) 353-9125 FAX: (517) 353-9334Email: rmgarav...@gmail.com On Jun 20, 2013, at 5:38 PM, Zhang, Zhen wrote: Hi Matthew, Thanks a lot. That is a great idea. I will try the high salt and worry about the crystallization later. Zhen -Original Message- From: Matthew Franklin [mailto:mfrank...@nysbc.org] Sent: Thursday, June 20, 2013 4:34 PM To: Zhang, Zhen Cc: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Puzzling observation about size exclusion chromatography Hi Zhen - Superdex is known to have some ion-exchange characteristics, so that it can weakly interact with some proteins. This is why the manufacturer recommends including a certain amount of salt in the running buffer. I have had the same experience with a few proteins, including one that came off the column well after the salt peak! (The protein was very clean after this step; all other proteins had eluted earlier.) As others have said, you can't rely on molecular weight calibrations in this case, but this behavior alone is no reason to think that the protein is misfolded or otherwise badly behaved. If you don't like the late elution, try increasing the salt concentration of your running buffer to 250 or even 500 mM. You'll probably need to exchange the eluted protein back into a low-salt buffer for your next steps (e.g. crystallization) if you do this. - Matt On 6/20/13 3:09 PM, Zhang, Zhen wrote: Dear all, I just observed a puzzling phenomenon when purifying a refolded protein with size exclusion chromatography. The protein was solubilized by 8M Urea and refolded by dialysis against 500mM Arginine in PBS. The protein is 40KDal and is expected to be a trimer. The puzzling part is the protein after refolding always eluted at 18ml from the superdex S200 column (10/300), which is calculated to be 5KDal by standard. However, the fractions appear to be at 40KDal with SDS PAGE and the protein is functional in term of in vitro binding to the protein-specific monoclonal antibody. I could not explain the observation and I am wondering if anyone has the similar experience or has an opinion on this. Any comments are welcome. Thanks. Zhen The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. -- Matthew Franklin, Ph. D. Senior Scientist New York Structural Biology Center 89 Convent Avenue, New York, NY 10027 (212) 939-0660 ext. 9374
Re: [ccp4bb] ctruncate bug?
On 21 June 2013 13:36, Ed Pozharski epozh...@umaryland.edu wrote: Replacing Iobs with E(J) is not only unnecessary, it's ill-advised as it will distort intensity statistics. For example, let's say you have translational NCS aligned with crystallographic axes, and hence some set of reflections is systematically absent. If all is well, Iobs~0 for the subset while E(J) is systematically positive. This obviously happens because the standard Wilson prior is wrong for these reflections, but I digress, as usual. Ed, If you observe the symptoms of translational NCS in the diffraction pattern (i.e. systematically weak zones of reflections) you must take it into account when calculating the averages, i.e. if you do it properly parity groups should be normalised separately (though I concede there may be a practical issue in that I'm not aware of any software that currently has this feature). In that case E(J) will be ~ 0, as expected. If you don't do that then clearly you can't expect to get the right answer! The theoretical intensities are based on the assumption that the intensity distributions are all positive, so it makes no sense to compare them with an experimental distribution where a significant fraction are negative. How exactly do you propose to deal properly with the P-Y L test that I described? - because of course that also inherently assumes that the intensities are all positive and it's certainly not valid to assume that E(J) = E(F)^2 ! Another point is that (to paraphrase G. Orwell) not all reflections are created equal, just some are more equal than others. What I mean is that in counting reflections for the cumulative distributions (i.e. you count the number of reflections in ranges of intensity or in ranges of L), a weak reflection should be counted as fractional with a contribution to the total which is less than 1, on a continuous scale from 0 to 1 related to I/sigma(I). In fact referring to your original posting reflections with h -4 will get such a small weight that it will be effectively zero and they won't be counted at all (or it won't make the slightest difference whether you count them or not). Of course when it comes to outputting reflections you can't have a fractional reflection, it's either included or it isn't. So then you may have to have an arbitrary cutoff, though such reflections would likely end up with zero intensity and large SD (but the programs may not currently be good at estimating the latter in such a situation, which is probably why they are currently rejected). Another point worth mentioning is that the observed distributions of E^n (E = normalised structure amplitude) tend to be very noisy, particularly for large n, and I have a suspicion (as yet untested) that this may come from weak reflections which have made a full contribution to the count when it should have been fractional (or even zero). I'm currently working on a revised version of TRUNCATE where some or all of the above issues will be addressed. Cheers -- Ian
Re: [ccp4bb] AW: Twinning problem - almost solved.
Hi Herman, Tighter restraints typically close the gap between R and R-free. This does not mean one should just tighten the restraints to satisfy one's own (or a referee's) idea of what the gap should be. I don't think there is a clear target of how large or small the gap should be. If you optimize the restraints to get the best (free) likelihood, you usually get a reasonable R gap without explicitly optimizing it. Cheers, Robbie -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Eleanor Dodson Sent: Friday, June 21, 2013 14:21 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] AW: Twinning problem - almost solved. At your resolution that seems to me a reasonable gap between R and Rfree? Eleanor On 21 Jun 2013, at 12:28, herman.schreu...@sanofi.com wrote: Dear Bulletin Board, After some headbanging (Refmac5 had helpfully created gap records for all insertions and deletions present in the structure), I got refmac5 running with the TWIN option. Refmac5 also found the k,h,-l domain and rejected the other possible domains because they were too small. The Rfactor's are now extremely good: ~14% and the Rfree's are for me acceptable: ~24%. Since I found the difference between R and Rfree somewhat large, I have been playing with the weighting. By using a weight of 0.01, I can bring the Rfactor up to 18%, but the Rfree stays about the same or even gets a little worse. My question: is there a way to bring R and Rfree closer together, or is it related to the twinned data and is it something we have to live with? Best regards, Herman -Ursprüngliche Nachricht- Von: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] Im Auftrag von Miller, Mitchell D. Gesendet: Donnerstag, 20. Juni 2013 17:43 An: CCP4BB@JISCMAIL.AC.UK Betreff: Re: [ccp4bb] Twinning problem You are welcome. Let me also for the benefit of others who may search the archives in the future, let me correct two errors below - (typo and a miss- recollection). Specially, I was thinking that phenix.refine was now able to refine multiple twin laws, but according to Nat Echols on the phenix mailing list http://phenix-online.org/pipermail/phenixbb/2013-March/019538.html phenix.refine only handles 1 twin law at this time. (My typo was that and our second structure was 3nuz with twin fractions 0.38, 0.32, 0.16 and 0.14 -- not 2nuz). A useful search for deposited structures mentioning tetartohedral http://www.ebi.ac.uk/pdbe- srv/view/search?search_type=all_texttext=TETARTOHEDRALLY+OR+TETAR TOHEDRAL Regards, Mitch -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of herman.schreu...@sanofi.com Sent: Thursday, June 20, 2013 8:04 AM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] AW: Twinning problem Dear Mitch (and Philip and Phil), It is clear that I should give refmac a go with the non-detwinned F's and just the TWIN command. Thank you for your suggestions, Herman -Ursprüngliche Nachricht- Von: Miller, Mitchell D. [mailto:mmil...@slac.stanford.edu] Gesendet: Donnerstag, 20. Juni 2013 16:18 An: Schreuder, Herman RD/DE Betreff: RE: Twinning problem Hi Herman, Have you considered the possibility of your crystals being tetartohedral twinned. That is more than one of the twin laws may apply to your crystals. E.g. in P32 it is possible to have tetartohedral twinning which would have 4 twin domains - (h,k,l), (k,h,-l), (-h,-k,l) and (-k,-h,-l). Perfect tetartohedral twinning of P3 would merge in P622 and each twin domain would have a faction of 0.25. We have had 2 cases like this (the first 2PRX was before there was support for this type of twinning except for in shelxl and we ended up with refined twin fractions of 0.38, 0.28, 0.19, 0.15 for the deposited crystal and a 2nd crystal that we did not deposit had twin fractions of 0.25, 0.27, 0.17, 0.31). The 2nd case we had was after support for twining (including tetartohedral twinning) was added to refmac (and I think phenix.refine can also handle this). For 2NUZ, it was P32 with refined twin fractions of 0.25, 0.27, 0.17, 0.31. Pietro Roversi wrote a review of tetartohedral twinning for the CCP4 proceedings issues of acta D http://dx.doi.org/10.1107/S0907444912006737 I would try refinement with refmac using the original (non-detwinned F's) with just the TWIN command to see if it ends up keeping twin fractions for all 3 operators (4 domains) -- especially with crystals 1 and 3 which appear to have the largest estimates of the other twin fractions. Regards, Mitch == Mitchell Miller, Ph.D. Joint Center for Structural Genomics Stanford Synchrotron Radiation Lightsource 2575 Sand Hill Rd -- SLAC MS 99 Menlo Park, CA 94025 Phone: 1-650-926-5036 FAX: 1-650-926-3292 -Original
Re: [ccp4bb] Puzzling observation about size exclusion chromatography
Hi Michael, Thank you very much for your suggestions. I will rerun with both buffer conditions and report back later. Thanks to everyone for your reply. Zhen From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of R. M. Garavito Sent: Friday, June 21, 2013 9:28 AM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Puzzling observation about size exclusion chromatography Dear Zhen, I should also point out that the statement Matt made (Superdex is known to have some ion-exchange characteristics, so that it can weakly interact with some proteins.) is not completely correct. Superdex and all chromatographic media made from carbohydrates (dextran, agarose, etc.) are also quite hydrophobic (which is surprising to some). The observation Zhen made is the classic behavior of hydrophobic interaction with the gel filtration media, which led to the development of hydrophobic interaction chromatographic (HIC). For HIC, you load the protein in high salt, and elute with low salt or a chaotrope (LiCl). So when you redo you experiment, Zhen, try with AND without salt. As Matt said, if it is an ion-exchange interaction, extra salt will make it elute more normally. But if it gets worse, then the extra salt is increasing the hydrophobic interactions, and you should run the column in lower salt (~50 mM NaCl) or with a bit of detergent. Given that you are refolding your protein, a partially folded protein may have have more hydrophobic patches. As my lab is routinely refolding our target proteins, we are always watching for this behavior, including on our analytical Superdex 200 10/300 columns, which is one of our favorites. Excessive hydrophobic interactions can also lead to clogged columns, which is not what you want for this expensive column. Good luck, Michael R. Michael Garavito, Ph.D. Professor of Biochemistry Molecular Biology 603 Wilson Rd., Rm. 513 Michigan State University East Lansing, MI 48824-1319 Office: (517) 355-9724 Lab: (517) 353-9125 FAX: (517) 353-9334Email: rmgarav...@gmail.commailto:garav...@gmail.com On Jun 20, 2013, at 5:38 PM, Zhang, Zhen wrote: Hi Matthew, Thanks a lot. That is a great idea. I will try the high salt and worry about the crystallization later. Zhen -Original Message- From: Matthew Franklin [mailto:mfrank...@nysbc.org] Sent: Thursday, June 20, 2013 4:34 PM To: Zhang, Zhen Cc: CCP4BB@JISCMAIL.AC.UKmailto:CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Puzzling observation about size exclusion chromatography Hi Zhen - Superdex is known to have some ion-exchange characteristics, so that it can weakly interact with some proteins. This is why the manufacturer recommends including a certain amount of salt in the running buffer. I have had the same experience with a few proteins, including one that came off the column well after the salt peak! (The protein was very clean after this step; all other proteins had eluted earlier.) As others have said, you can't rely on molecular weight calibrations in this case, but this behavior alone is no reason to think that the protein is misfolded or otherwise badly behaved. If you don't like the late elution, try increasing the salt concentration of your running buffer to 250 or even 500 mM. You'll probably need to exchange the eluted protein back into a low-salt buffer for your next steps (e.g. crystallization) if you do this. - Matt On 6/20/13 3:09 PM, Zhang, Zhen wrote: Dear all, I just observed a puzzling phenomenon when purifying a refolded protein with size exclusion chromatography. The protein was solubilized by 8M Urea and refolded by dialysis against 500mM Arginine in PBS. The protein is 40KDal and is expected to be a trimer. The puzzling part is the protein after refolding always eluted at 18ml from the superdex S200 column (10/300), which is calculated to be 5KDal by standard. However, the fractions appear to be at 40KDal with SDS PAGE and the protein is functional in term of in vitro binding to the protein-specific monoclonal antibody. I could not explain the observation and I am wondering if anyone has the similar experience or has an opinion on this. Any comments are welcome. Thanks. Zhen The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. -- Matthew Franklin, Ph. D. Senior Scientist New York Structural Biology Center 89 Convent Avenue, New York, NY 10027 (212) 939-0660 ext. 9374
[ccp4bb] AW: [ccp4bb] AW: Twinning problem - almost solved.
Hi Robbie, That is what I tried. The Rfactor got a lot worse (14%-18%) and the Rfree got a little worse (by 0.1-0.2%). My feeling is that that is not the right approach. Roger Rowlett suggested to give PDB_REDO a try. Maybe you have some instructions available how to get a local version? Best, Herman -Ursprüngliche Nachricht- Von: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] Im Auftrag von Robbie Joosten Gesendet: Freitag, 21. Juni 2013 16:21 An: CCP4BB@JISCMAIL.AC.UK Betreff: Re: [ccp4bb] AW: Twinning problem - almost solved. Hi Herman, Tighter restraints typically close the gap between R and R-free. This does not mean one should just tighten the restraints to satisfy one's own (or a referee's) idea of what the gap should be. I don't think there is a clear target of how large or small the gap should be. If you optimize the restraints to get the best (free) likelihood, you usually get a reasonable R gap without explicitly optimizing it. Cheers, Robbie -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Eleanor Dodson Sent: Friday, June 21, 2013 14:21 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] AW: Twinning problem - almost solved. At your resolution that seems to me a reasonable gap between R and Rfree? Eleanor On 21 Jun 2013, at 12:28, herman.schreu...@sanofi.com wrote: Dear Bulletin Board, After some headbanging (Refmac5 had helpfully created gap records for all insertions and deletions present in the structure), I got refmac5 running with the TWIN option. Refmac5 also found the k,h,-l domain and rejected the other possible domains because they were too small. The Rfactor's are now extremely good: ~14% and the Rfree's are for me acceptable: ~24%. Since I found the difference between R and Rfree somewhat large, I have been playing with the weighting. By using a weight of 0.01, I can bring the Rfactor up to 18%, but the Rfree stays about the same or even gets a little worse. My question: is there a way to bring R and Rfree closer together, or is it related to the twinned data and is it something we have to live with? Best regards, Herman -Ursprüngliche Nachricht- Von: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] Im Auftrag von Miller, Mitchell D. Gesendet: Donnerstag, 20. Juni 2013 17:43 An: CCP4BB@JISCMAIL.AC.UK Betreff: Re: [ccp4bb] Twinning problem You are welcome. Let me also for the benefit of others who may search the archives in the future, let me correct two errors below - (typo and a miss- recollection). Specially, I was thinking that phenix.refine was now able to refine multiple twin laws, but according to Nat Echols on the phenix mailing list http://phenix-online.org/pipermail/phenixbb/2013-March/019538.html phenix.refine only handles 1 twin law at this time. (My typo was that and our second structure was 3nuz with twin fractions 0.38, 0.32, 0.16 and 0.14 -- not 2nuz). A useful search for deposited structures mentioning tetartohedral http://www.ebi.ac.uk/pdbe- srv/view/search?search_type=all_texttext=TETARTOHEDRALLY+OR+TETAR TOHEDRAL Regards, Mitch -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of herman.schreu...@sanofi.com Sent: Thursday, June 20, 2013 8:04 AM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] AW: Twinning problem Dear Mitch (and Philip and Phil), It is clear that I should give refmac a go with the non-detwinned F's and just the TWIN command. Thank you for your suggestions, Herman -Ursprüngliche Nachricht- Von: Miller, Mitchell D. [mailto:mmil...@slac.stanford.edu] Gesendet: Donnerstag, 20. Juni 2013 16:18 An: Schreuder, Herman RD/DE Betreff: RE: Twinning problem Hi Herman, Have you considered the possibility of your crystals being tetartohedral twinned. That is more than one of the twin laws may apply to your crystals. E.g. in P32 it is possible to have tetartohedral twinning which would have 4 twin domains - (h,k,l), (k,h,-l), (-h,-k,l) and (-k,-h,-l). Perfect tetartohedral twinning of P3 would merge in P622 and each twin domain would have a faction of 0.25. We have had 2 cases like this (the first 2PRX was before there was support for this type of twinning except for in shelxl and we ended up with refined twin fractions of 0.38, 0.28, 0.19, 0.15 for the deposited crystal and a 2nd crystal that we did not deposit had twin fractions of 0.25, 0.27, 0.17, 0.31). The 2nd case we had was after support for twining (including tetartohedral twinning) was added to refmac (and I think phenix.refine can also handle this). For 2NUZ, it was P32 with refined twin fractions of 0.25, 0.27, 0.17, 0.31. Pietro Roversi wrote a review of tetartohedral twinning for the CCP4 proceedings issues of acta D
Re: [ccp4bb] AW: [ccp4bb] AW: Twinning problem - almost solved.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Herman, a large gap between R and Rfree might indicate a horrible geometry of your structure, especially if R increased by lowering the matrix weight in refmac. Or, to put it the other way round: it is easy to achieve a low R-value by screwing up the geometry of your model. Did you run the PDB file through molprobity? My guess is with the R=14% model you get a very red chart... Best, Tim On 06/21/2013 04:45 PM, herman.schreu...@sanofi.com wrote: Hi Robbie, That is what I tried. The Rfactor got a lot worse (14%-18%) and the Rfree got a little worse (by 0.1-0.2%). My feeling is that that is not the right approach. Roger Rowlett suggested to give PDB_REDO a try. Maybe you have some instructions available how to get a local version? Best, Herman -Ursprüngliche Nachricht- Von: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] Im Auftrag von Robbie Joosten Gesendet: Freitag, 21. Juni 2013 16:21 An: CCP4BB@JISCMAIL.AC.UK Betreff: Re: [ccp4bb] AW: Twinning problem - almost solved. Hi Herman, Tighter restraints typically close the gap between R and R-free. This does not mean one should just tighten the restraints to satisfy one's own (or a referee's) idea of what the gap should be. I don't think there is a clear target of how large or small the gap should be. If you optimize the restraints to get the best (free) likelihood, you usually get a reasonable R gap without explicitly optimizing it. Cheers, Robbie -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Eleanor Dodson Sent: Friday, June 21, 2013 14:21 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] AW: Twinning problem - almost solved. At your resolution that seems to me a reasonable gap between R and Rfree? Eleanor On 21 Jun 2013, at 12:28, herman.schreu...@sanofi.com wrote: Dear Bulletin Board, After some headbanging (Refmac5 had helpfully created gap records for all insertions and deletions present in the structure), I got refmac5 running with the TWIN option. Refmac5 also found the k,h,-l domain and rejected the other possible domains because they were too small. The Rfactor's are now extremely good: ~14% and the Rfree's are for me acceptable: ~24%. Since I found the difference between R and Rfree somewhat large, I have been playing with the weighting. By using a weight of 0.01, I can bring the Rfactor up to 18%, but the Rfree stays about the same or even gets a little worse. My question: is there a way to bring R and Rfree closer together, or is it related to the twinned data and is it something we have to live with? Best regards, Herman -Ursprüngliche Nachricht- Von: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] Im Auftrag von Miller, Mitchell D. Gesendet: Donnerstag, 20. Juni 2013 17:43 An: CCP4BB@JISCMAIL.AC.UK Betreff: Re: [ccp4bb] Twinning problem You are welcome. Let me also for the benefit of others who may search the archives in the future, let me correct two errors below - (typo and a miss- recollection). Specially, I was thinking that phenix.refine was now able to refine multiple twin laws, but according to Nat Echols on the phenix mailing list http://phenix-online.org/pipermail/phenixbb/2013-March/019538.html phenix.refine only handles 1 twin law at this time. (My typo was that and our second structure was 3nuz with twin fractions 0.38, 0.32, 0.16 and 0.14 -- not 2nuz). A useful search for deposited structures mentioning tetartohedral http://www.ebi.ac.uk/pdbe- srv/view/search?search_type=all_texttext=TETARTOHEDRALLY+OR+TETAR TOHEDRAL Regards, Mitch -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of herman.schreu...@sanofi.com Sent: Thursday, June 20, 2013 8:04 AM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] AW: Twinning problem Dear Mitch (and Philip and Phil), It is clear that I should give refmac a go with the non-detwinned F's and just the TWIN command. Thank you for your suggestions, Herman -Ursprüngliche Nachricht- Von: Miller, Mitchell D. [mailto:mmil...@slac.stanford.edu] Gesendet: Donnerstag, 20. Juni 2013 16:18 An: Schreuder, Herman RD/DE Betreff: RE: Twinning problem Hi Herman, Have you considered the possibility of your crystals being tetartohedral twinned. That is more than one of the twin laws may apply to your crystals. E.g. in P32 it is possible to have tetartohedral twinning which would have 4 twin domains - (h,k,l), (k,h,-l), (-h,-k,l) and (-k,-h,-l). Perfect tetartohedral twinning of P3 would merge in P622 and each twin domain would have a faction of 0.25. We have had 2 cases like this (the first 2PRX was before there was support for this type of twinning except for in shelxl and we ended up with refined twin fractions of 0.38, 0.28, 0.19, 0.15 for the deposited crystal
[ccp4bb] AW: [ccp4bb] AW: [ccp4bb] AW: Twinning problem - almost solved.
Dear Tim, I normally do not use Refmac, so I have no idea what to expect and what would be a good weight. I will do the molprobity test, but I do not expect major problems. This is a MR structure with a high resolution search model with 100% sequence identity. A few amino acids may have problems, but the overall structure should be ok. E.g. Refmac lists an RMSD bonds of 0.008 Å and an RMDS bond angles of 1.3°. Anyway, if the structure turns out to be really bad, I will get punished by the PDB annotators with lots of REMARK 500 records! Best, Herman -Ursprüngliche Nachricht- Von: Tim Gruene [mailto:t...@shelx.uni-ac.gwdg.de] Gesendet: Freitag, 21. Juni 2013 17:30 An: Schreuder, Herman RD/DE Cc: CCP4BB@JISCMAIL.AC.UK Betreff: Re: [ccp4bb] AW: [ccp4bb] AW: Twinning problem - almost solved. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Herman, a large gap between R and Rfree might indicate a horrible geometry of your structure, especially if R increased by lowering the matrix weight in refmac. Or, to put it the other way round: it is easy to achieve a low R-value by screwing up the geometry of your model. Did you run the PDB file through molprobity? My guess is with the R=14% model you get a very red chart... Best, Tim On 06/21/2013 04:45 PM, herman.schreu...@sanofi.com wrote: Hi Robbie, That is what I tried. The Rfactor got a lot worse (14%-18%) and the Rfree got a little worse (by 0.1-0.2%). My feeling is that that is not the right approach. Roger Rowlett suggested to give PDB_REDO a try. Maybe you have some instructions available how to get a local version? Best, Herman -Ursprüngliche Nachricht- Von: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] Im Auftrag von Robbie Joosten Gesendet: Freitag, 21. Juni 2013 16:21 An: CCP4BB@JISCMAIL.AC.UK Betreff: Re: [ccp4bb] AW: Twinning problem - almost solved. Hi Herman, Tighter restraints typically close the gap between R and R-free. This does not mean one should just tighten the restraints to satisfy one's own (or a referee's) idea of what the gap should be. I don't think there is a clear target of how large or small the gap should be. If you optimize the restraints to get the best (free) likelihood, you usually get a reasonable R gap without explicitly optimizing it. Cheers, Robbie -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Eleanor Dodson Sent: Friday, June 21, 2013 14:21 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] AW: Twinning problem - almost solved. At your resolution that seems to me a reasonable gap between R and Rfree? Eleanor On 21 Jun 2013, at 12:28, herman.schreu...@sanofi.com wrote: Dear Bulletin Board, After some headbanging (Refmac5 had helpfully created gap records for all insertions and deletions present in the structure), I got refmac5 running with the TWIN option. Refmac5 also found the k,h,-l domain and rejected the other possible domains because they were too small. The Rfactor's are now extremely good: ~14% and the Rfree's are for me acceptable: ~24%. Since I found the difference between R and Rfree somewhat large, I have been playing with the weighting. By using a weight of 0.01, I can bring the Rfactor up to 18%, but the Rfree stays about the same or even gets a little worse. My question: is there a way to bring R and Rfree closer together, or is it related to the twinned data and is it something we have to live with? Best regards, Herman -Ursprüngliche Nachricht- Von: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] Im Auftrag von Miller, Mitchell D. Gesendet: Donnerstag, 20. Juni 2013 17:43 An: CCP4BB@JISCMAIL.AC.UK Betreff: Re: [ccp4bb] Twinning problem You are welcome. Let me also for the benefit of others who may search the archives in the future, let me correct two errors below - (typo and a miss- recollection). Specially, I was thinking that phenix.refine was now able to refine multiple twin laws, but according to Nat Echols on the phenix mailing list http://phenix-online.org/pipermail/phenixbb/2013-March/019538.html phenix.refine only handles 1 twin law at this time. (My typo was that and our second structure was 3nuz with twin fractions 0.38, 0.32, 0.16 and 0.14 -- not 2nuz). A useful search for deposited structures mentioning tetartohedral http://www.ebi.ac.uk/pdbe- srv/view/search?search_type=all_texttext=TETARTOHEDRALLY+OR+TETAR TOHEDRAL Regards, Mitch -Original Message- From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of herman.schreu...@sanofi.com Sent: Thursday, June 20, 2013 8:04 AM To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] AW: Twinning problem Dear Mitch (and Philip and Phil), It is clear that I should give refmac a go with the non-detwinned F's and just the TWIN command. Thank you for your suggestions, Herman
Re: [ccp4bb] ctruncate bug?
On Jun 21, 2013, at 8:36 AM, Ed Pozharski epozh...@umaryland.edu wrote: On 06/20/2013 01:07 PM, Douglas Theobald wrote: How can there be nothing wrong with something that is unphysical? Intensities cannot be negative. I think you are confusing two things - the true intensities and observed intensities. But I'm not. Let me try to convince you ... True intensities represent the number of photons that diffract off a crystal in a specific direction or, for QED-minded, relative probabilities of a single photon being found in a particular area of the detector when it's probability wave function finally collapses. I agree. True intensities certainly cannot be negative and in crystallographic method they never are. They are represented by the best theoretical estimates possible, Icalc. These are always positive. I also very much agree. Observed intensities are the best estimates that we can come up with in an experiment. I also agree with this, and this is the clincher. You are arguing that Ispot-Iback=Iobs is the best estimate we can come up with. I claim that is absurd. How are you quantifying best? Usually we have some sort of discrepancy measure between true and estimate, like RMSD, mean absolute distance, log distance, or somesuch. Here is the important point --- by any measure of discrepancy you care to use, the person who estimates Iobs as 0 when IbackIspot will *always*, in *every case*, beat the person who estimates Iobs with a negative value. This is an indisputable fact. These are determined by integrating pixels around the spot where particular reflection is expected to hit the detector. Unfortunately, science did not yet invent a method that would allow to suspend a crystal in vacuum while also removing all of the outside solvent. Neither we have included diffuse scatter in our theoretical model. Because of that, full reflection intensity contains background signal in addition to the Icalc. This background has to be subtracted and what is perhaps the most useful form of observation is Ispot-Iback=Iobs. How can that be the most useful form, when 0 is always a better estimate than a negative value, by any criterion? These observed intensities can be negative because while their true underlying value is positive, random errorsmay result in IbackIspot. There is absolutely nothing unphysical here. Yes there is. The only way you can get a negative estimate is to make unphysical assumptions. Namely, the estimate Ispot-Iback=Iobs assumes that both the true value of I and the background noise come from a Gaussian distribution that is allowed to have negative values. Both of those assumptions are unphysical. Replacing Iobs with E(J) is not only unnecessary, it's ill-advised as it will distort intensity statistics. For example, let's say you have translational NCS aligned with crystallographic axes, and hence some set of reflections is systematically absent. If all is well, Iobs~0 for the subset while E(J) is systematically positive. This obviously happens because the standard Wilson prior is wrong for these reflections, but I digress, as usual. In summary, there is indeed nothing wrong, imho, with negative Iobs. The fact that some of these may become negative is correctly accounted for once sigI is factored into the ML target. Cheers, Ed. -- Oh, suddenly throwing a giraffe into a volcano to make water is crazy? Julian, King of Lemurs
Re: [ccp4bb] ctruncate bug?
On 21 June 2013 17:10, Douglas Theobald dtheob...@brandeis.edu wrote: Yes there is. The only way you can get a negative estimate is to make unphysical assumptions. Namely, the estimate Ispot-Iback=Iobs assumes that both the true value of I and the background noise come from a Gaussian distribution that is allowed to have negative values. Both of those assumptions are unphysical. Actually that's not correct: Ispot and Iback are both assumed to come from a _Poisson_ distribution which by definition is zero for negative values of its argument (you can't have a negative number of photons), so are _not_ allowed to have negative values. For large values of the argument (in fact the approximation is pretty good even for x ~ 10) a Poisson approximates to a Gaussian, and then of course the difference Ispot-Iback is also approximately Gaussian. But I think that doesn't affect your argument. Cheers -- Ian
Re: [ccp4bb] ctruncate bug?
On 06/21/2013 10:19 AM, Ian Tickle wrote: If you observe the symptoms of translational NCS in the diffraction pattern (i.e. systematically weak zones of reflections) you must take it into account when calculating the averages, i.e. if you do it properly parity groups should be normalised separately (though I concede there may be a practical issue in that I'm not aware of any software that currently has this feature). Ian, I think this is exactly what I was trying to emphasize, that applying some conversion to raw intensities may have negative impact when conversion is based on incorrect or incomplete assumptions. Cheers, Ed. -- Oh, suddenly throwing a giraffe into a volcano to make water is crazy? Julian, King of Lemurs
Re: [ccp4bb] ctruncate bug?
I kinda think we're saying the same thing, sort of. You don't like the Gaussian assumption, and neither do I. If you make the reasonable Poisson assumptions, then you don't get the Ispot-Iback=Iobs for the best estimate of Itrue. Except as an approximation for large values, but we are talking about the case when IbackIspot, where the Gaussian approximation to the Poisson no longer holds. The sum of two Poisson variates is also Poisson, which also can never be negative, unlike the Gaussian. So I reiterate: the Ispot-Iback=Iobs equation assumes Gaussians and hence negativity. The Ispot-Iback=Iobs does not follow from a Poisson assumption. On Jun 21, 2013, at 1:13 PM, Ian Tickle ianj...@gmail.com wrote: On 21 June 2013 17:10, Douglas Theobald dtheob...@brandeis.edu wrote: Yes there is. The only way you can get a negative estimate is to make unphysical assumptions. Namely, the estimate Ispot-Iback=Iobs assumes that both the true value of I and the background noise come from a Gaussian distribution that is allowed to have negative values. Both of those assumptions are unphysical. Actually that's not correct: Ispot and Iback are both assumed to come from a _Poisson_ distribution which by definition is zero for negative values of its argument (you can't have a negative number of photons), so are _not_ allowed to have negative values. For large values of the argument (in fact the approximation is pretty good even for x ~ 10) a Poisson approximates to a Gaussian, and then of course the difference Ispot-Iback is also approximately Gaussian. But I think that doesn't affect your argument. Cheers -- Ian
Re: [ccp4bb] ctruncate bug?
On Jun 20, 2013, at 2:13 PM, Ian Tickle ianj...@gmail.com wrote: Douglas, I think you are missing the point that estimation of the parameters of the proper Bayesian statistical model (i.e. the Wilson prior) in order to perform the integration in the manner you are suggesting requires knowledge of the already integrated intensities! Well, that's true, but that's how FW do it. They allow for negative integrated intensities. I'm arguing that we should not do that, since true intensities are positive, and so any estimate of them should also be positive. Examples are always better than words, so here goes (and I apologize for the length): The current way of doing things is summarized by Ed's equation: Ispot-Iback=Iobs. Here Ispot is the # of counts in the spot (the area encompassing the predicted reflection), and Iback is # of counts in the background (usu. some area around the spot). Our job is to estimate the true intensity Itrue. Ed and others argue that Iobs is a reasonable estimate of Itrue, but I say it isn't because Itrue can never be negative, whereas Iobs can. Now where does the Ispot-Iback=Iobs equation come from? It implicitly assumes that both Iobs and Iback come from a Gaussian distribution, in which Iobs and Iback can have negative values. Here's the implicit data model: Ispot = Iobs + Iback There is an Itrue, to which we add some Gaussian noise and randomly generate an Iobs. To that is added some background noise, Iback, which is also randomly generated from a Gaussian with a true mean of Ibtrue. This gives us the Ispot, the measured intensity in our spot. Given this data model, Ispot will also have a Gaussian distribution, with mean equal to the sum of Itrue + Ibtrue. From the properties of Gaussians, then, the ML estimate of Itrue will be Ispot-Iback, or Iobs. Now maybe you disagree with that Gaussian data model. If so, welcome to my POV. There are better models, ones that don't give Ispot-Iback as our best estimate of Itrue. Here is a simple example that incorporates our knowledge that Itrue cannot be negative (this example is primarily for illustrating the point, it's not exactly what I would recommend). Instead of using Gaussians, we will use Gamma distributions, which cannot be negative. We assume Iobs is distributed according to a Gamma(Itrue,1). The mean of this distribution is Itrue. (The Maxwell-Boltzmann energy distribution is also a gamma, just for comparison). We also assume that the noise is exponential (a special case of the gamma), Gamma(1,1). The mean of this distribution is 1. (You could imagine that you've normalized Ispot relative to its background --- again, just for ease of calculation). We still assume that Ispot = Iobs + Iback. Then, Ispot will also have a gamma distribution, Gamma(Itrue+1,1). The mean of the Ispot distribution, as you might expect, is Itrue+1. Now we measure Ispot. Given Ispot, the ML estimate of Itrue is: InvDiGamma[ln(Ispot)]-1 if Ispot0.561 or 0 if Ispot0.561 Note, the ML estimate is no longer Iobs, and the ML estimate cannot be negative. InvDiGamma is the inverse Digamma function --- a bit unusual, but easily calculated (actually no weirder than the exponential or logarithm, its a relative of factorial and the gamma function). Not something the Braggs would've used, but hey, we've got iPhones now. We can also estimate the SD of of our estimate, but I won't bore you with the equation. A few examples: Ispot ML Itrue SD - -- 0.5 0 0.78 0.6 0.04 0.80 0.8 0.25 0.91 0.9 0.36 0.97 1.0 0.46 1.0 1.5 0.97 1.2 2.0 1.48 1.4 3.0 2.49 1.7 5.0 4.49 2.2 10.09.50 3.2 20.019.5 4.5 100 99.5 10 Note that the first four entries in the table are the case when IspotIback. No negative estimates. You'd get qualitatively similar results if you assume Poisson for Iback and Ispot. To sum up --- the equation Ispot-Iback=Iobs is unphysical because it is founded on unphysical assumptions. If you make better physical assumptions (i.e., Itrue cannot be negative), you end up with different estimates for Itrue. I suppose we could iterate, i.e. assume an approximate prior, integrate, calculate a better prior, re-do the integration with the new prior and so on (hoping of course that the whole process converges), but I think most people would regard that as overkill. Also dealing with the issue of averaging estimates of intensities that no longer have a Gaussian error distribution, and also crucially outlier rejection, would require some rethinking of the algorithms. The question is would it make any difference in the end compared with the 'post-correction' we're doing now? Cheers -- Ian On 20 June 2013 18:14, Douglas Theobald dtheob...@brandeis.edu wrote: I still don't see how you get a negative
Re: [ccp4bb] ctruncate bug?
On Jun 21, 2013, at 2:48 PM, Ed Pozharski epozh...@umaryland.edu wrote: Douglas, Observed intensities are the best estimates that we can come up with in an experiment. I also agree with this, and this is the clincher. You are arguing that Ispot-Iback=Iobs is the best estimate we can come up with. I claim that is absurd. How are you quantifying best? Usually we have some sort of discrepancy measure between true and estimate, like RMSD, mean absolute distance, log distance, or somesuch. Here is the important point --- by any measure of discrepancy you care to use, the person who estimates Iobs as 0 when IbackIspot will *always*, in *every case*, beat the person who estimates Iobs with a negative value. This is an indisputable fact. First off, you may find it useful to avoid such words as absurd and indisputable fact. I know political correctness may be sometimes overrated, but if you actually plan to have meaningful discussion, let's assume that everyone responding to your posts is just trying to help figure this out. I apologize for offending and using the strong words --- my intention was not to offend. This is just how I talk when brainstorming with my colleagues around a blackboard, but of course then you can see that I smile when I say it. To address your point, you are right that J=0 is closer to true intensity then a negative value. The problem is that we are not after a single intensity, but rather all of them, as they all contribute to electron density reconstruction. If you replace negative Iobs with E(J), you would systematically inflate the averages, which may turn problematic in some cases. So, I get the point. But even then, using any reasonable criterion, the whole estimated dataset will be closer to the true data if you set all negative intensity estimates to 0. It is probably better to stick with raw intensities and construct theoretical predictions properly to account for their properties. What I was trying to tell you is that observed intensities is what we get from experiment. But they are not what you get from the detector. The detector spits out a positive value for what's inside the spot. It is we, as human agents, who later manipulate and massage that data value by subtracting the background estimate. A value that has been subjected to a crude background subtraction is not the raw experimental value. It has been modified, and there must be some logic to why we massage the data in that particular manner. I agree, of course, that the background should be accounted for somehow. But why just subtract it away? There are other ways to massage the data --- see my other post to Ian. My argument is that however we massage the experimentally observed value should be physically informed, and allowing negative intensity estimates violates the basic physics. [snip] These observed intensities can be negative because while their true underlying value is positive, random errorsmay result in IbackIspot. There is absolutely nothing unphysical here. Yes there is. The only way you can get a negative estimate is to make unphysical assumptions. Namely, the estimate Ispot-Iback=Iobs assumes that both the true value of I and the background noise come from a Gaussian distribution that is allowed to have negative values. Both of those assumptions are unphysical. See, I have a problem with this. Both common sense and laws of physics dictate that number of photons hitting spot on a detector is a positive number. There is no law of physics that dictates that under no circumstances there could be IspotIback. That's not what I'm saying. Sure, Ispot can be less than Iback randomly. That does not mean we have to estimate the detected intensity as negative, after accounting for background. Yes, E(Ispot)=E(Iback). Yes, E(Ispot-Iback)=0. But P(Ispot-Iback=0)0, and therefore experimental sampling of Ispot-Iback is bound to occasionally produce negative values. What law of physics is broken when for a given reflection total number of photons in spot pixels is less that total number of photons in equal number of pixels in the surrounding background mask? Cheers, Ed. -- Oh, suddenly throwing a giraffe into a volcano to make water is crazy? Julian, King of Lemurs
Re: [ccp4bb] ctruncate bug?
On Jun 21, 2013, at 2:52 PM, James Holton jmhol...@lbl.gov wrote: Yes, but the DIFFERENCE between two Poisson-distributed values can be negative. This is, unfortunately, what you get when you subtract the background out from under a spot. Perhaps this is the source of confusion here? Maybe, but if you assume Poisson background and intensities, the ML estimate when background measured intensity is not negative, nor is it the difference Ispot-Iback. The ML estimate is 0. (With a finite non-zero SD, smaller SD the smaller the Ispot/Iback ratio). On Fri, Jun 21, 2013 at 11:34 AM, Douglas Theobald dtheob...@brandeis.edu wrote: I kinda think we're saying the same thing, sort of. You don't like the Gaussian assumption, and neither do I. If you make the reasonable Poisson assumptions, then you don't get the Ispot-Iback=Iobs for the best estimate of Itrue. Except as an approximation for large values, but we are talking about the case when IbackIspot, where the Gaussian approximation to the Poisson no longer holds. The sum of two Poisson variates is also Poisson, which also can never be negative, unlike the Gaussian. So I reiterate: the Ispot-Iback=Iobs equation assumes Gaussians and hence negativity. The Ispot-Iback=Iobs does not follow from a Poisson assumption. On Jun 21, 2013, at 1:13 PM, Ian Tickle ianj...@gmail.com wrote: On 21 June 2013 17:10, Douglas Theobald dtheob...@brandeis.edu wrote: Yes there is. The only way you can get a negative estimate is to make unphysical assumptions. Namely, the estimate Ispot-Iback=Iobs assumes that both the true value of I and the background noise come from a Gaussian distribution that is allowed to have negative values. Both of those assumptions are unphysical. Actually that's not correct: Ispot and Iback are both assumed to come from a _Poisson_ distribution which by definition is zero for negative values of its argument (you can't have a negative number of photons), so are _not_ allowed to have negative values. For large values of the argument (in fact the approximation is pretty good even for x ~ 10) a Poisson approximates to a Gaussian, and then of course the difference Ispot-Iback is also approximately Gaussian. But I think that doesn't affect your argument. Cheers -- Ian
Re: [ccp4bb] ctruncate bug?
However you decide to argue the point, you must consider _all_ the observations of a reflection (replicates and symmetry related) together when you infer Itrue or F etc, otherwise you will bias the result even more. Thus you cannot (easily) do it during integration Phil Sent from my iPad On 21 Jun 2013, at 20:30, Douglas Theobald dtheob...@brandeis.edu wrote: On Jun 21, 2013, at 2:48 PM, Ed Pozharski epozh...@umaryland.edu wrote: Douglas, Observed intensities are the best estimates that we can come up with in an experiment. I also agree with this, and this is the clincher. You are arguing that Ispot-Iback=Iobs is the best estimate we can come up with. I claim that is absurd. How are you quantifying best? Usually we have some sort of discrepancy measure between true and estimate, like RMSD, mean absolute distance, log distance, or somesuch. Here is the important point --- by any measure of discrepancy you care to use, the person who estimates Iobs as 0 when IbackIspot will *always*, in *every case*, beat the person who estimates Iobs with a negative value. This is an indisputable fact. First off, you may find it useful to avoid such words as absurd and indisputable fact. I know political correctness may be sometimes overrated, but if you actually plan to have meaningful discussion, let's assume that everyone responding to your posts is just trying to help figure this out. I apologize for offending and using the strong words --- my intention was not to offend. This is just how I talk when brainstorming with my colleagues around a blackboard, but of course then you can see that I smile when I say it. To address your point, you are right that J=0 is closer to true intensity then a negative value. The problem is that we are not after a single intensity, but rather all of them, as they all contribute to electron density reconstruction. If you replace negative Iobs with E(J), you would systematically inflate the averages, which may turn problematic in some cases. So, I get the point. But even then, using any reasonable criterion, the whole estimated dataset will be closer to the true data if you set all negative intensity estimates to 0. It is probably better to stick with raw intensities and construct theoretical predictions properly to account for their properties. What I was trying to tell you is that observed intensities is what we get from experiment. But they are not what you get from the detector. The detector spits out a positive value for what's inside the spot. It is we, as human agents, who later manipulate and massage that data value by subtracting the background estimate. A value that has been subjected to a crude background subtraction is not the raw experimental value. It has been modified, and there must be some logic to why we massage the data in that particular manner. I agree, of course, that the background should be accounted for somehow. But why just subtract it away? There are other ways to massage the data --- see my other post to Ian. My argument is that however we massage the experimentally observed value should be physically informed, and allowing negative intensity estimates violates the basic physics. [snip] These observed intensities can be negative because while their true underlying value is positive, random errorsmay result in IbackIspot. There is absolutely nothing unphysical here. Yes there is. The only way you can get a negative estimate is to make unphysical assumptions. Namely, the estimate Ispot-Iback=Iobs assumes that both the true value of I and the background noise come from a Gaussian distribution that is allowed to have negative values. Both of those assumptions are unphysical. See, I have a problem with this. Both common sense and laws of physics dictate that number of photons hitting spot on a detector is a positive number. There is no law of physics that dictates that under no circumstances there could be IspotIback. That's not what I'm saying. Sure, Ispot can be less than Iback randomly. That does not mean we have to estimate the detected intensity as negative, after accounting for background. Yes, E(Ispot)=E(Iback). Yes, E(Ispot-Iback)=0. But P(Ispot-Iback=0)0, and therefore experimental sampling of Ispot-Iback is bound to occasionally produce negative values. What law of physics is broken when for a given reflection total number of photons in spot pixels is less that total number of photons in equal number of pixels in the surrounding background mask? Cheers, Ed. -- Oh, suddenly throwing a giraffe into a volcano to make water is crazy? Julian, King of Lemurs
Re: [ccp4bb] ctruncate bug?
I hope I am not duplicating too much of this fascinating discussion with these comments: perhaps the main reason there is confusion about what to do is that neither F nor I is really the most suitable thing to use in refinement. As pointed out several times in different ways, we don't measure F or I, we only measure counts on a detector. As a convenience, we process our diffraction images to estimate I or F and their uncertainties and model these uncertainties as simple functions (e.g., a Gaussian). There is no need in principle to do that, and if we were to refine instead against the raw image data these issues about positivity would disappear and our structures might even be a little better. Our standard procedure is to estimate F or I from counts on the detector, then to use these estimates of F or I in refinement. This is not so easy to do right because F or I contain many terms coming from many pixels and it is hard to model their statistics in detail. Further, attempts we make to estimate either F or I as physically plausible values (e.g., using the fact that they are not negative) will generally be biased (the values after correction will generally be systematically low or systematically high, as is true for the French and Wilson correction and as would be true for the truncation of I at zero or above). Randy's method for intensity refinement is an improvement because the statistics are treated more fully than just using an estimate of F or I and assuming its uncertainty has a simple distribution. So why not avoid all the problems with modeling the statistics of processed data and instead refine against the raw data. From the structural model you calculate F, from F and a detailed model of the experiment (the same model that is currently used in data processing) you calculate the counts expected on each pixel. Then you calculate the likelihood of the data given your models of the structure and of the experiment. This would have lots of benefits because it would allow improved descriptions of the experiment (decay, absorption, detector sensitivity, diffuse scattering and other background on the images,on and on) that could lead to more accurate structures in the end. Of course there are some minor issues about putting all this in computer memory for refinement -Tom T From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of Phil [p...@mrc-lmb.cam.ac.uk] Sent: Friday, June 21, 2013 2:50 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] ctruncate bug? However you decide to argue the point, you must consider _all_ the observations of a reflection (replicates and symmetry related) together when you infer Itrue or F etc, otherwise you will bias the result even more. Thus you cannot (easily) do it during integration Phil Sent from my iPad On 21 Jun 2013, at 20:30, Douglas Theobald dtheob...@brandeis.edu wrote: On Jun 21, 2013, at 2:48 PM, Ed Pozharski epozh...@umaryland.edu wrote: Douglas, Observed intensities are the best estimates that we can come up with in an experiment. I also agree with this, and this is the clincher. You are arguing that Ispot-Iback=Iobs is the best estimate we can come up with. I claim that is absurd. How are you quantifying best? Usually we have some sort of discrepancy measure between true and estimate, like RMSD, mean absolute distance, log distance, or somesuch. Here is the important point --- by any measure of discrepancy you care to use, the person who estimates Iobs as 0 when IbackIspot will *always*, in *every case*, beat the person who estimates Iobs with a negative value. This is an indisputable fact. First off, you may find it useful to avoid such words as absurd and indisputable fact. I know political correctness may be sometimes overrated, but if you actually plan to have meaningful discussion, let's assume that everyone responding to your posts is just trying to help figure this out. I apologize for offending and using the strong words --- my intention was not to offend. This is just how I talk when brainstorming with my colleagues around a blackboard, but of course then you can see that I smile when I say it. To address your point, you are right that J=0 is closer to true intensity then a negative value. The problem is that we are not after a single intensity, but rather all of them, as they all contribute to electron density reconstruction. If you replace negative Iobs with E(J), you would systematically inflate the averages, which may turn problematic in some cases. So, I get the point. But even then, using any reasonable criterion, the whole estimated dataset will be closer to the true data if you set all negative intensity estimates to 0. It is probably better to stick with raw intensities and construct theoretical predictions properly to account for their properties. What I was trying
[ccp4bb] peptide planarity restraints for modified residues
Dear CCP4ers/REFMACers, the C-terminal peptide bond of a modified lysyl, M3L, appears less planar than other peptide bonds in the same structure. What is the currently preferred method of restraining such planarity? I have currently not added any link record in the header of my coordinates file. Would that be required? Thank you, Wolfram Tempel
Re: [ccp4bb] str solving problem
Pramod: [1] Please refrain from posting excessively large (1MB) attachments to the ccp4bb. Either use a compression technique or use another means of transmitting large files to your recipients without spamming the entire group. [2] Your predictions are not overlaying well with the spots . Well it may be overlaying well with a subset of spots (in this case, the strongest spots that obey the symmetry *you* chose), but your are leaving out a large number of spots. As I said before, your diffraction pattern is exhibiting strong reflections with weak reflections at a given resolution. It looks as if there are multiple lattices probably due to bad crystal morphology ( a cracked crystal, twinning, pseudosymmetry) or multiple crystals in the beam, the list goes on I've experienced your case many, many times you'll get a good MR solution, but then the refinement becomes 'stuck'. I think the idiom... 'garbage in, garbage out' applies here.. [3] I have given several efforts to the XDS but its giving error data image of particular no. does not exist (initially it was saying 11th image than i change image range then it says 21st and so on) kindly check my data collection profile and XDS.INP file in attachment' Sounds like a file name problem. [4] Or if the crystal is big enough, you could try shooting it in different areas and 'searching' for a better spot to collect data. Or 'grow a better crystal'. raising the crystals and struggle is on the peak... There are a number of ccp4bb postings about crystal reproducibility or crystal diffraction improvement. Search the archives for these. F - Francis E. Reyes PhD 215 UCB University of Colorado at Boulder
