Re: [ccp4bb] Bug in c_truncate?
Dear All, Thank you kindly for the replies and concerns over the problem I've experienced. I really appreciate them. I do not know how often the I - F conversion is done in CCP4i's F2MTZ GUI, especially with the FreeR flags preserved. Nevertheless, as mentioned, the problem seems to arise because [c]truncate does not recognize the FreeR column, unlike old-truncate. Whether this is a bug or new feature, it would be great if [c]truncate is (re-)programmed to recognize the FreeR column for a more streamlined import/I - F conversion/uniqueify process executed in F2MTZ. Also thanks for pointing out a relatively straight forward workaround using cad. Best, Peter
Re: [ccp4bb] Help with model bias in merihedral twin + Refmac5
Dear Colin, Thank you for the email. To be honest, I don't know exactly which map they are. From my understanding (and according to http://www.ccp4.ac.uk/schools/India-2010/tutorials/refmac/Murshudov30th.pdf), Refmac5 outputs 'normal map' 2mF(obs)-DF(calc) and 'difference map' 2mF(obs)-DF(calc). I believe this is better than looking at the typical 2F(obs)-F(calc), although there still appears to be a fair amount of model bias. Best, Peter Subject: RE: [ccp4bb] Help with model bias in merihedral twin Date: Wed, 27 Oct 2010 17:38:41 +0100 From: colin.n...@diamond.ac.uk To: pc...@hotmail.com Peter Regarding the question Although the electron density map looks good, I am not sure if I should have too much confidence in it because I was not able to obtain 'strong electron densities' from omitted sections of the model in a refinement. I don't know if this is an indicator for bias introduced somewhere. I would like to ask what may be some procedures I can try for checking and removing these biases Can you state what type of maps these are? The reason is the following. Taking PHENIX twinning maps as an example we have, in the manual - By default, data is detwinned using algebraic techniques, unless the twin fraction is above 45%, in which case detwinning is performed using proportionality of twin related Icalc values. Detwinning using the proportionality option, results in maps that are more biased towards the model, resulting in seemingly cleaner, but in the end less informative maps. The 2mFo-dFc map coefficients can be chosen to have sigmaA weighting (two_m_dtfo_d_fc) or not (two_dtfo_fc). IN both cases, the map coefficients correspond to the 'untwinned' data. A difference map can be constructed using either sigmaA weighted detwinned data (m_dtfo_d_fc), a sigmaA weighted gradient map (m_gradient) or a plain gradient map (gradient). The default is m_dtfo_d_fc but can be changed to gradient or m_gradient if desired. For the high twin fraction which you have (near 50%). my view is that 2Fo-Fc type maps are not optimal for this as they don't take account of the increased bias resulting from the extra degrees of freedom (i.e. splitting the intensity between the two reflections based on Icalc). For the reflections related by twinning higher order coefficients (e.g. 3Fo-2Fc or perhaps 4Fo-3Fc) would give noiser but less biased maps. Fibre diffraction folk do similar things when their Bessel function terms overlap. Cheers Colin From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Peter Chan Sent: 27 October 2010 02:00 To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] Help with model bias in merihedral twin Hello All, Not long ago I posted for some help with my twinned dataset at 1.95 A, and have confirmed the twinning of P6(5) into P6(5)22. Molecular replacement was successful and the twin refinement in Refmac yieled R/Rfree of 21%/26%, with a twin fraction of 0.46. Although the electron density map looks good, I am not sure if I should have too much confidence in it because I was not able to obtain 'strong electron densities' from omitted sections of the model in a refinement. I don't know if this is an indicator for bias introduced somewhere. I would like to ask what may be some procedures I can try for checking and removing these biases, and a few additional related questions. As suggested to me previously, I have generated a total omit map with sfcheck in ccp4i, using the refined pdb and unrefined data in P6(5). The .map file look a little worse in quality (is this because of the twinning?) but is still reasonable, with a few breaks in the main chain and side chains. Interestingly, when I do a real space refinement against the total omit map, I get slightly better Rfree at the earlier rounds of Refmac which diverges into the numbers above. Why is this the case? Cycle R fact R free 0 0.2301 0.2523 1 0.2205 0.2534 2 0.2164 0.2545 3 0.2140 0.2554 4 0.2123 0.2559 5 0.2117 0.2570 6 0.2116 0.2575 7 0.2112 0.2582 8 0.2112 0.2584 9 0.2109 0.2587 10 0.2106 0.2597 Secondly, I read that I should make sure the Free R flags should be consistent throughout the twin-related indices. What may be the adverse outcome if this isn't enforced? Is Refmac aware of this in a twin-refinement? If not, which tool could I use for this? I would very much appreciate any comments and suggestions. Best, Peter Chan -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt
Re: [ccp4bb] Bug in c_truncate?
Dear Crystallographers, Thank you all for the emails. Below are some details of the procedures I performed leading up to the problem. The reflection file is my own data, processed in XDS and then flagging FreeR's in XPREP in thin resolution shells. I am using CCP4i version 6.1.2. I tried looking for known/resolved issues/updates in version 6.1.3 but could not find any so I assumed it is the same version of f2mtz/ctruncate/uniqueify. I used the GUI version of F2MTZ, with the settings below: - import file in SHELX format - keep existing FreeR flags - fortran format (3F4.0,2F8.3,F4.0) - added data label I other integer // FreeRflag The hkl file, in SHELX format, output by XPREP look something like this: -26 -3 1 777.48 39.19 26 -3 -1 800.83 36.31 -26 3 -1 782.67 37.97 27 -3 1 45.722 25.711 -1 -27 3 1 -14.20 31.69 -1 Notice the test set is flagged -1 and the working set is not flagged at all. This actually lead to another error message in f2mtz about missing FreeR flags. From my understanding, the SHELX flagging convention is 1 for working and -1 for test. So I manually tagged the working set with 1 using vi: -26 -3 1 777.48 39.19 1 26 -3 -1 800.83 36.31 1 -26 3 -1 782.67 37.97 1 27 -3 1 45.722 25.711 -1 -27 3 1 -14.20 31.69 -1 This is the file which gives me the error message: Problem with FREE column in input file. All flags apparently identical. Check input file.. Apparently, import to mtz works ok when I use old-truncate instead of c-truncate. Best, Peter
Re: [ccp4bb] Bug in c_truncate?
Hello Tim, Thank you for the suggestion. I have now tagged the working set as 1 and test set as 0. Unfortunately, it still gives the same error about all Rfree being the same, and only in c-truncate but not old-truncate. Perhaps I should install 6.1.3 and see if the problem still persist. Best, Peter Date: Thu, 28 Oct 2010 16:29:31 +0200 From: t...@shelx.uni-ac.gwdg.de Subject: Re: [ccp4bb] Bug in c_truncate? To: CCP4BB@JISCMAIL.AC.UK Hello Peter, I faintly rememeber a similar kind of problem, and think that if you replace -1 with 0, the problem should go away. It seemed that -1 is not an allowed flag for (some) ccp4 programs. Please let us know if this resolves the issue. Tim On Thu, Oct 28, 2010 at 10:21:20AM -0400, Peter Chan wrote: Dear Crystallographers, Thank you all for the emails. Below are some details of the procedures I performed leading up to the problem. The reflection file is my own data, processed in XDS and then flagging FreeR's in XPREP in thin resolution shells. I am using CCP4i version 6.1.2. I tried looking for known/resolved issues/updates in version 6.1.3 but could not find any so I assumed it is the same version of f2mtz/ctruncate/uniqueify. I used the GUI version of F2MTZ, with the settings below: - import file in SHELX format - keep existing FreeR flags - fortran format (3F4.0,2F8.3,F4.0) - added data label I other integer // FreeRflag The hkl file, in SHELX format, output by XPREP look something like this: -26 -3 1 777.48 39.19 26 -3 -1 800.83 36.31 -26 3 -1 782.67 37.97 27 -3 1 45.722 25.711 -1 -27 3 1 -14.20 31.69 -1 Notice the test set is flagged -1 and the working set is not flagged at all. This actually lead to another error message in f2mtz about missing FreeR flags. From my understanding, the SHELX flagging convention is 1 for working and -1 for test. So I manually tagged the working set with 1 using vi: -26 -3 1 777.48 39.19 1 26 -3 -1 800.83 36.31 1 -26 3 -1 782.67 37.97 1 27 -3 1 45.722 25.711 -1 -27 3 1 -14.20 31.69 -1 This is the file which gives me the error message: Problem with FREE column in input file. All flags apparently identical. Check input file.. Apparently, import to mtz works ok when I use old-truncate instead of c-truncate. Best, Peter -- -- Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen phone: +49 (0)551 39 22149 GPG Key ID = A46BEE1A
[ccp4bb] Bug in c_truncate?
Hello, I've been struggling with F2MTZ and importing my hkl file into mtz by 'keeping existing freeR data'. I keep getting the error Problem with FREE column in input file. All flags apparently identical. Check input file. At the end of the day, it appears that this only happens in ctruncate and not in the old_truncate instead of ctruncate. Has anyone experienced a similar problem? Peter
[ccp4bb] Help with model bias in merihedral twin
Hello All, Not long ago I posted for some help with my twinned dataset at 1.95 A, and have confirmed the twinning of P6(5) into P6(5)22. Molecular replacement was successful and the twin refinement in Refmac yieled R/Rfree of 21%/26%, with a twin fraction of 0.46. Although the electron density map looks good, I am not sure if I should have too much confidence in it because I was not able to obtain 'strong electron densities' from omitted sections of the model in a refinement. I don't know if this is an indicator for bias introduced somewhere. I would like to ask what may be some procedures I can try for checking and removing these biases, and a few additional related questions. As suggested to me previously, I have generated a total omit map with sfcheck in ccp4i, using the refined pdb and unrefined data in P6(5). The .map file look a little worse in quality (is this because of the twinning?) but is still reasonable, with a few breaks in the main chain and side chains. Interestingly, when I do a real space refinement against the total omit map, I get slightly better Rfree at the earlier rounds of Refmac which diverges into the numbers above. Why is this the case? Cycle R fact R free 0 0.2301 0.2523 1 0.2205 0.2534 2 0.2164 0.2545 3 0.2140 0.2554 4 0.2123 0.2559 5 0.2117 0.2570 6 0.2116 0.2575 7 0.2112 0.2582 8 0.2112 0.2584 9 0.2109 0.2587 10 0.2106 0.2597 Secondly, I read that I should make sure the Free R flags should be consistent throughout the twin-related indices. What may be the adverse outcome if this isn't enforced? Is Refmac aware of this in a twin-refinement? If not, which tool could I use for this? I would very much appreciate any comments and suggestions. Best, Peter Chan
[ccp4bb] Twin - Data reduction and refinement in Refmac
Hello All, I am a graduate student working on my first merohedrally twinned data set. Like a few, I am a bit intimidated by it. After some trial and error with the help of some online resources and ccp4bb posts, I seem to have solved the structure. However, I am still unsure about some of the steps taken. Background: My dataset was processed to 1.95 A in XDS, the apparent space group is P622 (96 A, 96 A, 92 A, 90, 90, 120). Various tests indicate that I have a twinned dataset. The Rsym of the data when processed in a lower symmetry space group (i.e. P6, P321 and P312) suggest that the real space group may be P6 because its Rsym is lower by ~1-2%. The screw axis could not be unambiguously identified from systematic absences. Molecular replacement by Phaser returned a solution in P6(5) with 2 molecules in the asymmetric unit. This was refined in Refmac with the twin option to R Rfree of 22% and 25%. The twin fractions are 47% and 53%. My questions and concerns: - First and foremost, is there a chance that I may have processed the data in the wrong space group (or wrongly deduced the data in the right space group)? - Should the diffraction data be merged or unmerged during the twin refinement in Refmac? The current dataset is fully merged (repeated measurements, Friedel pairs symmetry related reflections). Would there be an improvement in the twin refinement if some of them are kept unmerged? - Should the twin refinement be performed on the intensities or structure factor amplitudes? I have tried both (using the same set of Rfree flags): With intensities, the R/Rfree are 22%/25% and twin fractions are 47%/53%. With amplitudes, the R/Rfree are 25%/29% and twin fractions are 44.6%/55.4%. The resulting electron density maps are not significantly different, however. I don't understand why the statistics vary so significantly. - During the model building, the electron density map appears to be 'weak'. Rebuilding some surface loops (by first deleting them, refining the omit structure, and remodeling into the difference map) which initially has some 2Fo-Fc density becomes tricky because there is not much density left in the refined omit structure. Was the initial densities purely a result of model bias or is this related to the twinning of the crystal? Could this also be because Refmac outputs a differently weighed 2Fo-Fc map (if I recall correctly) during twin refinement? I would be very grateful for any help, comments and suggestions. Best, Peter Chan
Re: [ccp4bb] Twin - Data reduction and refinement in Refmac
Hello Garib, Thank you for the reply helpful insight. I ran the refinement of structure factor amplitudes without the TWIN command, and obtained much higher R and Rfree (32% and 36%). Also, in the process, I found out that I made a mistake earlier in that the amplitudes were refined as intensities. To summarize the R and Rfree of the refinements: Structure factors, no twin: 32%, 36% Structure factors, twin: 21.5%, 25.0% SF, twin, refined as intensities: 25%, 29% -- wrong setting Intensities, twin: 22.4%, 25.4% These results fit into the general rule that you mentioned, and I believe I will proceed with the twinned refinement of structure factor amplitudes. As you suggested, I also submitted the data+model to Zanuda on the server (see below), and it appears that the real space group is P6(5). Best, Peter readability test passed (Refmac_5.5.0070) resolution1.947 spacegroupP 65 cell 96.530 96.530 91.930 90.00 90.00 120.00 Step 1. R-factors for the starting model. Transformation into a supergroup. current time:Oct 13 22:21 BST expected end of job (rough estimate):Oct 13 22:52 BST - | Subgroup | Spacegroup | R.m.s.d. | Refinement in tested group | | || from the || | Ref|| starting | Rigid | Restrained | | || model, A |--|-| | || |R |R | R-free | |--||--|--|--|--| |4 | P 65 | 0.0005 |--| 0.2005 | 0.2230 | |4 | P 65 | 0.0005 |--|--|--| ^ Step 2. Refinements in subgroups. There are 4 subgroups to test. current time:Oct 13 22:32 BST expected end of job: Oct 13 23:04 BST ^ |4 | P 65 | 0.0005 |--|--|--| - | 1 | P 1| 0.0711 | 0.2937 | 0.1949 | 0.2292 | | 2 | P 1 21 1 | 0.0631 | 0.3217 | 0.1971 | 0.2305 | | 3 | P 32 | 0.0629 | 0.3088 | 0.1938 | 0.2290 | | 4 | P 65 | 0.0655 | 0.3321 | 0.1976 | 0.2316 | - |3 | P 32 | 0.0629 | 0.3088 | 0.1938 | 0.2290 | ^ Step 3. Refinement of the best model. Candidate symmetry elements are added one by one. current time:Oct 13 22:43 BST expected end of job: Oct 13 23:06 BST ^ |3 | P 32 | 0.0629 | 0.3088 | 0.1938 | 0.2290 | - | 1 | P 1| 0.0714 | 0.2949 | 0.1952 | 0.2293 | | 2 | P 1 21 1 | 0.0587 |--| 0.1950 | 0.2306 | | 4 | P 65 | 0.0596 |--| 0.1961 | 0.2315 | | 16 | P 65 2 2 | 1.6311 |--| 0.4261 | 0.4499 | - |4 | P 65 | 0.0596 |--| 0.1961 | 0.2315 | - R-factor in the original subgroup is (almost) the best. The original spacegroup assignment seems to be correct. end of job: Oct 13 23:02 BST Date: Wed, 13 Oct 2010 21:51:57 +0100 From: ga...@ysbl.york.ac.uk Subject: Re: [ccp4bb] Twin - Data reduction and refinement in Refmac To: CCP4BB@JISCMAIL.AC.UK As a general rule intensity based refinement gives higher R-factor especially when intensities are weak. Truncate smoothes out data and Rfactors become lower (it is not necessary that model becomes better) In your case it may happen that your space group is higher. To check that you can do simple refinement and submit your data+model to Zanuda on the server: www.ysbl.york.ac.uk/YSBLPrograms/index.jsp It may be able correct your space group and give higer space group if it is the case. What are Rfactors without twin refinement? If Rfactors with and without twin refinement are not very different then using twin would not make much sense. regardsGarib On 13 Oct 2010, at 16:01, Peter Chan wrote:Hello
Re: [ccp4bb] Twin - Data reduction and refinement in Refmac
Hello Fred, Thank you for the response. I have made a mistake in the twin refinement settings (see the other email) and the best R Rfree values I obtained were from the twin refinement of structure factor amplitudes, which is about 1% less than the twin refinement of intensities. I have not used Bhat's omit maps before. I will give it a shot and see how it may improve my model building. Best, Peter Date: Wed, 13 Oct 2010 17:35:09 +0200 From: frederic.velli...@ibs.fr To: pc...@hotmail.com Subject: Re: [ccp4bb] Twin - Data reduction and refinement in Refmac Peter Chan wrote: Hello All, I am a graduate student working on my first merohedrally twinned data set. Like a few, I am a bit intimidated by it. After some trial and error with the help of some online resources and ccp4bb posts, I seem to have solved the structure. However, I am still unsure about some of the steps taken. Background: My dataset was processed to 1.95 A in XDS, the apparent space group is P622 (96 A, 96 A, 92 A, 90, 90, 120). Various tests indicate that I have a twinned dataset. The Rsym of the data when processed in a lower symmetry space group (i.e. P6, P321 and P312) suggest that the real space group may be P6 because its Rsym is lower by ~1-2%. The screw axis could not be unambiguously identified from systematic absences. Molecular replacement by Phaser returned a solution in P6(5) with 2 molecules in the asymmetric unit. This was refined in Refmac with the twin option to R Rfree of 22% and 25%. The twin fractions are 47% and 53%. Usually the R and Rfree are slightly higher with twin refinement than with untwinned data; these figures look satisfactory to me. My questions and concerns: - First and foremost, is there a chance that I may have processed the data in the wrong space group (or wrongly deduced the data in the right space group)? - Should the diffraction data be merged or unmerged during the twin refinement in Refmac? The current dataset is fully merged (repeated measurements, Friedel pairs symmetry related reflections). Would there be an improvement in the twin refinement if some of them are kept unmerged? - Should the twin refinement be performed on the intensities or structure factor amplitudes? I have tried both (using the same set of Rfree flags): With intensities, the R/Rfree are 22%/25% and twin fractions are 47%/53%. With amplitudes, the R/Rfree are 25%/29% and twin fractions are 44.6%/55.4%. The resulting electron density maps are not significantly different, however. I don't understand why the statistics vary so significantly. I would use the refinement that gives the lower R / Rfree (no questions asked). - During the model building, the electron density map appears to be 'weak'. Rebuilding some surface loops (by first deleting them, refining the omit structure, and remodeling into the difference map) which initially has some 2Fo-Fc density becomes tricky because there is not much density left in the refined omit structure. Was the initial densities purely a result of model bias or is this related to the twinning of the crystal? Could this also be because Refmac outputs a differently weighed 2Fo-Fc map (if I recall correctly) during twin refinement? Have you tried Bhat's Omit maps as well? Possible to compute using either sfcheck or omit (the latter is not in ccp4bb). I would be very grateful for any help, comments and suggestions. Best, Peter Chan
Re: [ccp4bb] Twin - Data reduction and refinement in Refmac
I see. Thank you for the reassuring and helpful pointers. Best, Peter Subject: Re: [ccp4bb] Twin - Data reduction and refinement in Refmac From: ga...@ysbl.york.ac.uk Date: Wed, 13 Oct 2010 23:55:56 +0100 CC: CCP4BB@JISCMAIL.AC.UK To: pc...@hotmail.com It seems that evidence is convincing: twin is present. All evidences indicate that space group is P6(5) and twin is present. Theoretically that is what you would expect at the end of refinement if twin is present: Huge drop in Rfactor and marginal improvement if any in electron density. RegardsGarib On 13 Oct 2010, at 23:41, Peter Chan wrote:Hello Garib, Thank you for the reply helpful insight. I ran the refinement of structure factor amplitudes without the TWIN command, and obtained much higher R and Rfree (32% and 36%). Also, in the process, I found out that I made a mistake earlier in that the amplitudes were refined as intensities. To summarize the R and Rfree of the refinements: Structure factors, no twin: 32%, 36% Structure factors, twin: 21.5%, 25.0% SF, twin, refined as intensities: 25%, 29% -- wrong setting Intensities, twin: 22.4%, 25.4% These results fit into the general rule that you mentioned, and I believe I will proceed with the twinned refinement of structure factor amplitudes. As you suggested, I also submitted the data+model to Zanuda on the server (see below), and it appears that the real space group is P6(5). Best, Peter readability test passed (Refmac_5.5.0070) resolution1.947 spacegroupP 65 cell 96.530 96.530 91.930 90.00 90.00 120.00 Step 1. R-factors for the starting model. Transformation into a supergroup. current time:Oct 13 22:21 BST expected end of job (rough estimate):Oct 13 22:52 BST - | Subgroup | Spacegroup | R.m.s.d. | Refinement in tested group | | || from the || | Ref|| starting | Rigid | Restrained | | || model, A |--|-| | || |R |R | R-free | |--||--|--|--|--| |4 | P 65 | 0.0005 |--| 0.2005 | 0.2230 | |4 | P 65 | 0.0005 |--|--|--| ^ Step 2. Refinements in subgroups. There are 4 subgroups to test. current time:Oct 13 22:32 BST expected end of job: Oct 13 23:04 BST ^ |4 | P 65 | 0.0005 |--|--|--| - | 1 | P 1| 0.0711 | 0.2937 | 0.1949 | 0.2292 | | 2 | P 1 21 1 | 0.0631 | 0.3217 | 0.1971 | 0.2305 | | 3 | P 32 | 0.0629 | 0.3088 | 0.1938 | 0.2290 | | 4 | P 65 | 0.0655 | 0.3321 | 0.1976 | 0.2316 | - |3 | P 32 | 0.0629 | 0.3088 | 0.1938 | 0.2290 | ^ Step 3. Refinement of the best model. Candidate symmetry elements are added one by one. current time:Oct 13 22:43 BST expected end of job: Oct 13 23:06 BST ^ |3 | P 32 | 0.0629 | 0.3088 | 0.1938 | 0.2290 | - | 1 | P 1| 0.0714 | 0.2949 | 0.1952 | 0.2293 | | 2 | P 1 21 1 | 0.0587 |--| 0.1950 | 0.2306 | | 4 | P 65 | 0.0596 |--| 0.1961 | 0.2315 | | 16 | P 65 2 2 | 1.6311 |--| 0.4261 | 0.4499 | - |4 | P 65 | 0.0596 |--| 0.1961 | 0.2315 | - R-factor in the original subgroup is (almost) the best. The original spacegroup assignment seems to be correct. end of job: Oct 13 23:02 BST Date: Wed, 13 Oct 2010 21:51:57 +0100 From: ga...@ysbl.york.ac.uk Subject: Re: [ccp4bb] Twin - Data reduction and refinement in Refmac To: CCP4BB@JISCMAIL.AC.UK As a general rule intensity based refinement gives higher R-factor especially when intensities are weak
Re: [ccp4bb] Refinement of covalent ligand in Refmac5
I believe you could try treating this Asp residue as an unnatural amino acid (FAD-Asp), and refine your structure with it. Peter Date: Thu, 10 Sep 2009 15:27:58 +0100 From: kpodzelin...@gmail.com Subject: [ccp4bb] Refinement of covalent ligand in Refmac5 To: CCP4BB@JISCMAIL.AC.UK Hello! I have an FAD cofactor that appears to be covalently bound to the Asp side chain (~1.6 A away). I was told that I need to refine the structure after indicating the covalent linkage in the pdb. If I add a line in the pdb LINK and then refine in Refmac5, FAD gets all messed up and shifted out of its density and R factors go up by ~5%. Any suggestions on how to do this refinement would be greatly appreciated! Kateryna _ Click less, chat more: Messenger on MSN.ca http://go.microsoft.com/?linkid=9677404
Re: [ccp4bb] Problem with Coot reading monomer library file.
Dear Mark, It also appears to me that the formatting of the cif matters. In my case for some reason, I can't get Coot 0.5/0.6 to read the cif file written by Refmac/Sketcher of CCP4i 6.1.1. I've compared the cif file from PRODRG and CCP4i for the same monomer, and found that that the column positions for certain entries are different. I've edited CCP4i's cif file to match the column positions of PRODRG's cif file, and I can get Coot to read it properly and let me do real space refinement. Still, I feel that there may be some other things that I've overlooked because this is quite unexpected... Regards, Peter Date: Mon, 31 Aug 2009 01:17:39 +0200 From: mark.vanra...@usc.es To: pc...@hotmail.com CC: paul.ems...@bioch.ox.ac.uk Subject: Re: [ccp4bb] Problem with Coot reading monomer library file. Peter, Paul, a couple of months ago I had a similar problem - older versions of, in this case, Refmac, working with a cif file and a new version not. It turned out newer Refmacs are more picky about the types of returns at the end of each line in the file. I had been editing the file with MacOSX textedit and somehow the resulting file contained the wrong kind of returns (hard or soft, I can't remember exactly), and not all info from the cif file was actually read into Refmac. It took me several days and help of Garib Murshudov, the main Refmac author, to figure this out so, Peter, only just over 10 hours was not bad! Paul, apologies for the above description, probable a programming/computer expert like you would have formulated it a lot better... Peter, could it be that your Coot 0.1 is somehow also coupled to an older, more tolerant, Refmac (perhaps you did this test on another computer?) and your Coot 0.6 uses a newer Refmac version? Mark Quoting Peter Chan pc...@hotmail.com: Dear Eric, Thank you very much for your suggestion. It worked. Dear Paul, Thank you for your kind offer with the help (and for writing such a wonderful program + providing users with support!). I will compare the cif files and see if I can pick out the differences... Sincerely, Peter Hi Peter, Did you try making a cif using the Dundee Prodrg server? http://davapc1.bioch.dundee.ac.uk/prodrg/ Eric -- Eric Ortlund, Ph.D.Assistant ProfessorDepartment of BiochemistryEmory University School of Medicine1510 Clifton Road, NE, Room G235Atlanta, GA 30322Tel 404-727-5014 Fax 404-727-2738eric.ortl...@emory.edu Date: Sat, 29 Aug 2009 07:02:12 +0100 From: paul.ems...@bioch.ox.ac.uk To: pc...@hotmail.com Subject: Re: [ccp4bb] Problem with Coot reading monomer library file. Peter Chan wrote: Dear Crystallographers, I've been spending 10 hours trying (googling, manually editting cif files based on templates in Coot's library, asking around, rtfm and reading this bbs) to figure out why Coot the geometric restraints wouldn't load. I can think of no reason why 0.1 would work and 0.6 would not. If you want me to investigate, please send the PDB and cif dictionary. Regards, Paul. _ Stay in the loop and chat with friends, right from your inbox! http://go.microsoft.com/?linkid=9671354 _ New! Get to Messenger faster: Sign-in here now! http://go.microsoft.com/?linkid=9677407
Re: [ccp4bb] Problem with Coot reading monomer library file.
Dear Eric, Thank you very much for your suggestion. It worked. Dear Paul, Thank you for your kind offer with the help (and for writing such a wonderful program + providing users with support!). I will compare the cif files and see if I can pick out the differences... Sincerely, Peter Hi Peter, Did you try making a cif using the Dundee Prodrg server? http://davapc1.bioch.dundee.ac.uk/prodrg/ Eric -- Eric Ortlund, Ph.D.Assistant ProfessorDepartment of BiochemistryEmory University School of Medicine1510 Clifton Road, NE, Room G235Atlanta, GA 30322Tel 404-727-5014 Fax 404-727-2738eric.ortl...@emory.edu Date: Sat, 29 Aug 2009 07:02:12 +0100 From: paul.ems...@bioch.ox.ac.uk To: pc...@hotmail.com Subject: Re: [ccp4bb] Problem with Coot reading monomer library file. Peter Chan wrote: Dear Crystallographers, I've been spending 10 hours trying (googling, manually editting cif files based on templates in Coot's library, asking around, rtfm and reading this bbs) to figure out why Coot the geometric restraints wouldn't load. I can think of no reason why 0.1 would work and 0.6 would not. If you want me to investigate, please send the PDB and cif dictionary. Regards, Paul. _ Stay in the loop and chat with friends, right from your inbox! http://go.microsoft.com/?linkid=9671354
[ccp4bb] Problem with Coot reading monomer library file.
Dear Crystallographers, I've been spending 10 hours trying (googling, manually editting cif files based on templates in Coot's library, asking around, rtfm and reading this bbs) to figure out why Coot the geometric restraints wouldn't load. The molecule I have is difluoroacetate (and some analogs). I drew it in sketcher and tried regularized it using both the refmac from sketcher as well as the 'normal' refmac. From what I can tell, Coot can read this cif file without errors, but when it keeps telling me that it doesn't have the library descriptions when I try to do real space refinement. My system and programs: -Windows Vista 32 bit Home -Coot 0.5 as well as 0.6 -CCP4i 6.1.1 Out of desperation, I also tested this on Coot v0.1 which has worked for me before... and I was surprised that I can do real space refinement without problem. Could there be some settings that I've missed? Any insights would be greatly appreciated. Peter _ Stay in the loop and chat with friends, right from your inbox! http://go.microsoft.com/?linkid=9671354
