Various problems with phenix.refine
Here are a few problems I have found using phenix.refine 1.4: If NCS restraint selection in the .def file have newline characters, the REMARK 3 formatting is messed up. It should probably replace all white-space regions with a single space. When NCS restraints contain a residue with alternate conformations, that residue gets excluded from all equivalences, even if the selections contain ALTID to avoid the redundant atoms. If the .def file has a syntax error, phenix.refine dies with an error that the file format is not recognized. Why not print syntax errors? The optimize_wxc and optimize_wxu features are useful, but it is difficult to use the result to define an improved fixed scale on subsequent rounds, without having to optimize every time. It is not obvious whether the scale written in the log represents the new wxc_scale, or if it is a multiplier versus the current wxc_scale. The log also truncates to 2 decimal places. In my case, I only get one significant digit from scale=0.05. I propose that the optimizations write something like "Optimal wxc_scale = 0.533". The input data is written as "refine_data.mtz", not using the serial number, and there seems to be no flag to disable writing it. That means I have to force overwrite to run iterations in the same directory. If each run is in its own directory, the serial number is not very useful for filenames. So, the output MTZ should have the serial number, and you might also consider an option to disable the serial number when separate directories are used. Thanks, Joe Krahn
With regard to optimize_wxc and optimize_wxu I asked the same question a while ago. Here's Pavel's response. On Aug 7, 2009, at 1:26 PM, Pavel Afonine wrote:
HI Francis,
currently these values are not preserved - they are re-determined at each macro-cycle.
The reason for this is that they can be very different from run to run, however I think I will make it possible to preserve them in the .def file - it's on my list now, so will be available in the future.
The fact that the values that you picked up from "scale" did not work may well reflect what I said above: the values may change (sometimes) significantly between the macro-cycles.
Pavel.
On 8/7/09 8:56 AM, Francis E Reyes wrote:
Hi all
I went through the time to optimize_wxc and optimize_wxu to help pull out some density for ligands (i.e. all sequence assigned residues are built). However, it would be nice if the resulting .def was updated with the optimized wxc and wxu. Where are those values? I didn't think for wxc it was scale=XX in the following lines..
r_work= 0.2167 r_free= 0.2525 bonds= 0.003 angles= 0.70 scale= 7.00 r_work= 0.2097 r_free= 0.2502 bonds= 0.004 angles= 0.96 scale= 8.00 ... etc
Refining with the scale= value that phenix ultimately chose didn't work form me (resulted in awful geometry and high r/rfree).
Thanks
FR
--------------------------------------------- Francis Reyes M.Sc. 215 UCB University of Colorado at Boulder
gpg --keyserver pgp.mit.edu --recv-keys 67BA8D5D
8AE2 F2F4 90F7 9640 28BC 686F 78FD 6669 67BA 8D5D
_______________________________________________ phenixbb mailing list [email protected] http://www.phenix-online.org/mailman/listinfo/phenixbb
_______________________________________________ phenixbb mailing list [email protected] http://www.phenix-online.org/mailman/listinfo/phenixbb
--------------------------------------------- Francis Reyes M.Sc. 215 UCB University of Colorado at Boulder gpg --keyserver pgp.mit.edu --recv-keys 67BA8D5D 8AE2 F2F4 90F7 9640 28BC 686F 78FD 6669 67BA 8D5D On Sep 23, 2009, at 1:04 PM, Joe Krahn wrote:
The optimize_wxc and optimize_wxu features are useful, but it is difficult to use the result to define an improved fixed scale on subsequent rounds, without having to optimize every time. It is not obvious whether the scale written in the log represents the new wxc_scale, or if it is a multiplier versus the current wxc_scale. The log also truncates to 2 decimal places. In my case, I only get one significant digit from scale=0.05. I propose that the optimizations write something like "Optimal wxc_scale = 0.533".
--------------------------------------------- Francis Reyes M.Sc. 215 UCB University of Colorado at Boulder gpg --keyserver pgp.mit.edu --recv-keys 67BA8D5D 8AE2 F2F4 90F7 9640 28BC 686F 78FD 6669 67BA 8D5D
Hi Joe, thanks for the feedback!
If NCS restraint selection in the .def file have newline characters, the REMARK 3 formatting is messed up. It should probably replace all white-space regions with a single space.
Could you please send me an example of such .def and PDB file with bad REMARK 3 records?
When NCS restraints contain a residue with alternate conformations, that residue gets excluded from all equivalences, even if the selections contain ALTID to avoid the redundant atoms.
I'm not sure about this one, I hope Ralf will clarify this. I presume the NCS selection machinery excludes residues in alternative conformations automatically (as it for example does for H atoms)... Ralf, is this true?
If the .def file has a syntax error, phenix.refine dies with an error that the file format is not recognized. Why not print syntax errors?
This one for Ralf too...
The optimize_wxc and optimize_wxu features are useful, but it is difficult to use the result to define an improved fixed scale on subsequent rounds, without having to optimize every time. It is not obvious whether the scale written in the log represents the new wxc_scale, or if it is a multiplier versus the current wxc_scale. The log also truncates to 2 decimal places. In my case, I only get one significant digit from scale=0.05. I propose that the optimizations write something like "Optimal wxc_scale = 0.533".
This is a frequent question that I replied many times. The optimal weight that comes out of "optimize_wxc=true" (or "optimize_wxu=true") may significantly vary (or may not, it depends...) between macro-cycles or between phenix.refine runs. This is why the optimal weight value found at particular macro-cycle is not preserved. I can add an option so it gets preserved in .def file if a user specifically asks for this (adding it to my to-do list). I will change the output to the .log file to make this clear.
The input data is written as "refine_data.mtz", not using the serial number,
If I correctly understood the question... This file is created when you run phenix.refine with 1) multiple files (for example, one file contains Fobs, and the other one contains free-R flags), or 2) non-MTZ file, or 3) your inputs do not contain free-R flags and you asked phenix.refine to create them. If you start with one MTZ file that contains free-R flags, then *_data.mtz is not created. Since this is a one-time operation, the serial number is not appended. Thanks! Pavel.
Pavel Afonine wrote:
The optimize_wxc and optimize_wxu features are useful, but it is difficult to use the result to define an improved fixed scale on subsequent rounds, without having to optimize every time. It is not obvious whether the scale written in the log represents the new wxc_scale, or if it is a multiplier versus the current wxc_scale. The log also truncates to 2 decimal places. In my case, I only get one significant digit from scale=0.05. I propose that the optimizations write something like "Optimal wxc_scale = 0.533".
This is a frequent question that I replied many times. The optimal weight that comes out of "optimize_wxc=true" (or "optimize_wxu=true") may significantly vary (or may not, it depends...) between macro-cycles or between phenix.refine runs. This is why the optimal weight value found at particular macro-cycle is not preserved. I can add an option so it gets preserved in .def file if a user specifically asks for this (adding it to my to-do list). I will change the output to the .log file to make this clear.
OK, I am asking to add it to the .def file. Even if the optimized scale is just written in the log, that would be very helpful. The documentation suggests that optimization is slow and is better to use only for later stages of refinement. At earlier stages of refinement, an optimized wxc_scale is almost certainly better than the hard-wired default, even if it is not optimized for every run. It makes a lot of sense to do an optimization intermittantly during the build process, so you can get an improved scale versus the default, with much less overhead than a full optimization every time. I thought that the reason PHENIX has both wxc and wxc_scale is because wxc is more variable and can be updated quickly, while wxc_scale varies much less. Even if wxc_scale can vary a lot, it would be nice to actually see the optimized value so you can tell whether that is actually the case for a given structure. Thanks Joe Krahn
If the .def file has a syntax error, phenix.refine dies with an error that the file format is not recognized. Why not print syntax errors?
It is a side-effect of automatically recognizing all file formats. We give up only after trying each and every possible reader. If nothing works, we don't have a mechanism to score what the file is most likely and then produce the format-specific error. Solving that problem is harder than it may seem at first sight. You can get the syntax error via iotbx.phil your.def Ralf
Ralf W. Grosse-Kunstleve wrote:
If the .def file has a syntax error, phenix.refine dies with an error that the file format is not recognized. Why not print syntax errors?
It is a side-effect of automatically recognizing all file formats. We give up only after trying each and every possible reader. If nothing works, we don't have a mechanism to score what the file is most likely and then produce the format-specific error. Solving that problem is harder than it may seem at first sight. You can get the syntax error via
iotbx.phil your.def
Ralf
OK, I understand the difficulty with the "try all input filters" method. Here is one way that may work without too much difficulty. Allow the file-input procedures to return a diagnostic text if it thinks the file is a match, but has errors. If they all fail, but only one file-reader returns a message, print it. A simple short-term solution might be to print a suggestion based on just the filename extension, such as your suggestion above. For example, *.mtz files could suggest running "mtzdmp file.mtz". Tanks, Joe
participants (4)
-
Francis E Reyes -
Joe Krahn -
Pavel Afonine -
Ralf W. Grosse-Kunstleve