Jianghai, the "fundamental" problem is that phenix.refine and Molprobity use different definitions for X-H distances. phenix.refine uses CCP4 Monomer Library as a source of geometry restraints, and Monomer Library uses "shorter" (X-ray) distances for X-H (but not for all entries, see below). phenix.reduce and Molprobity both use "longer" X-H distances. Unfortunately this is not the end of inconsistencies since the Monomer Library uses "shorter" X-H distances for amino-acids and "longer" X-H distances for everything else (as far as I know). For refinement against X-ray data it is good to use "shorter" distances (as SHELXL does), and for refinement against neutron data it is good to use "longer" ones. What's good for validation (Molprobity, etc) - I do not know. But what I do know for sure is that things should be consistent, at least within one program (PHENIX). Currently this is not the case, sorry. It is a part of our plans to address this problem. All the best! Pavel. On 10/29/10 2:01 PM, Jianghai Zhu wrote:
Hi all,
If I use the riding H atoms come out of phenix.refine in molprobity, it gives me a decent clash score. But if I strip the H atoms and let molprobity to add H atoms, I get a much worse clash score. I saw the manual of phenix recommends the first method. So what is the cause of the difference here? I know long time ago that phenix and molprobity used different bond length to add the riding H atoms. I don't know what the situation is now. Does phenix.refine refine the riding H atom positions?
Thanks.
-- Jianghai
_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb