gridding of maps & coot
Hi, in making ccp4 formatted binary files readable by coot there are two *determine_gridding methods on the c++ side of cctbx ; *http://cctbx.sourceforge.net/current/c_plus_plus/namespacecctbx_1_1maptbx.ht... 1) template<typename IndexValueType>af::tiny< IndexValueType, 3 > determine_gridding (uctbx::unit_cell const &unit_cell, double d_min, double resolution_factor, af::tiny< IndexValueType, 3 > const &mandatory_factors=detail::one_one_one, IndexValueType max_prime=5, bool assert_shannon_sampling=true); 2) template<typename IndexValueType>af::tiny< IndexValueType, 3 > determine_gridding (uctbx::unit_cell const &unit_cell, double d_min, double resolution_factor, sgtbx::search_symmetry_flags const &symmetry_flags, sgtbx::space_group_type const &space_group_type, af::tiny< IndexValueType, 3 > const &mandatory_factors=detail::one_one_one, IndexValueType max_prime=5, bool assert_shannon_sampling=true); From the python side these get called within http://cctbx.sourceforge.net/current/python/cctbx.maptbx.html#crystal_griddi... __init__(self, unit_cell, d_min=None, resolution_factor=None, step=None, symmetry_flags=None, space_group_info=None, mandatory_factors=None, max_prime=5, assert_shannon_sampling=True, pre_determined_n_real=None); In phenix code it appears that only resolution_factor is ever set and internally then only the first determine_gridding method ever gets called. For numerous space groups these grid dimensions aren't compatible with symmetry operations and if symmetry operations are added to the ccp4 binary file coot has issues with asu (asymmetric unit) fitting to the grid. http://www.ccp4.ac.uk/html/maplib.html If the symmetry operator equations are skipped then coot will read as if the map is P 1 and not know the space group and asu's. symmetry_flags would have to be set to something non-None to call the second method. And if the second determine_gridding method(which is spacegroup aware) would be used, the grid dimensions are compatible with symmetry operators and coot reads and works with the asu's (and my own custom code is also happy). For all the maps produced from phenix.refine runs I've examined they have a space group number between 1 and 230, no symmetry operators included and grid dimensions from the first determine_gridding method. Now there are a number of space groups which have different axes chosen. For example 155 can be R=Rhombohedral http://img.chem.ucl.ac.uk/sgp/large/155az1.htm or H=Hexagonal http://img.chem.ucl.ac.uk/sgp/large/155bz1.htm axes. The symmetry operators identify which one or some systems prepend a number on the space group number such as 155 -> 1155. But coot (0.7 or 0.8.1) doesn't respond to that; only to the symmetry operators I suppose because the symmetry operators are the most trustworthy. The functionality is already in cctbx. Is there a reason the second determine_gridding method(spacegroup aware) is not used by phenix? And a reason symmetry operator equations are not added to the output ccp4 binary files? How should a ccp4 binary know the R or H axes of the space group? (according to its format http://www.ccp4.ac.uk/html/maplib.html) -Roger
On 17/03/15 18:22, Roger Martin wrote:
and if symmetry operations are added to the ccp4 binary file coot has issues with asu (asymmetric unit) fitting to the grid
The nature of the issues that Coot has with ASU fitting to the grid is not clear to me. Is the problem here that Coot (and CCP4's) ASU is inconsistent with that of cctbx (for a given spacegroup)? Paul.
On 03/17/2015 08:15 PM, Paul Emsley wrote:
On 17/03/15 18:22, Roger Martin wrote:
and if symmetry operations are added to the ccp4 binary file coot has issues with asu (asymmetric unit) fitting to the grid
The nature of the issues that Coot has with ASU fitting to the grid is not clear to me. It is the combination of grid dimensions from the determine_gridding(in cctbx and not spacegroup aware) and the symmetry operators. I haven't looked at coot's code but the behavior indicates it wants to avoid interpolations.
if the grid dimension isn't fitting an integer number of ASU' in x or y or z. The second determine_gridding(in cctbx and spacegroup aware) works. But phenix does not use it because it doesn't set the symmetry_flags in its initialization of http://cctbx.sourceforge.net/current/python/cctbx.maptbx.html#crystal_griddi...
Is the problem here that Coot (and CCP4's) ASU is inconsistent with that of cctbx (for a given spacegroup)?
Paul.
_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb Unsubscribe: [email protected]
Hi All, I am working on a dataset diffracted to ~2.8 A and the highest template identity is about 12%. I am trying MR_Rosetta following the online manual with the following command, hhr file and fragment files are prepared as online manual suggested. phenix.mr_rosetta seq_file=../seq.dat data=../in.mtz hhr_files=../xxx-align.hhr read_hhpred.number_of_models=1 read_hhpred.number_of_models_to_skip=0 already_placed=False fragment_files=../aat000_03_05.200_v1_3 fragment_files=../aat000_09_05.200_v1_3 rescore_mr.relax=False ncs_copies=2 use_all_plausible_sg=True nproc=8 group_run_command=sh resolution=4.5 place_model.mr_resolution=4.5 rosetta_modeling.map_resolution=4.5 run_prerefine=true number_of_prerefine_models=1000 >& log this run ends up with the error message like this, Trying to adjust the PDB sequence from alignment file: ---------------------------------------------------------------------------------KMNSKELSLKGLCLR--DDGPGIIIVVGNEKSCKFYENLVMK-------------------DMHNNSISKTWEGYLQDCKFKGWFMKVCNDQDSLLRTLGQ------------ to match the actual PDB sequence: KMNSKELSLKGLCLRIRDDGPGIIIVVGNEKSCKFYENLVMKDMHNNSISKTWEGYLQDCKFKGWFMKVCNDQDSLLRTLGQ New alignment line 4 for PDB: 0 ---------------------------------------------------------------------------------KMNSKELSLKGLCLR--DDGPGIIIVVGNEKSCKFYENLVMK-------------------DMHNNSISKTWEGYLQDCKFKGWFMKVCNDQDSLLRTLGQ------------ Sorry: Sorry, please supply an alignment file for this job. mr_rosetta cannot automatically generate alignments where there are deletions required from the PDB file This only happens when I set ncs_copies=2. If i change ncs_copies=1, no such error. When I looked at the output file with ncs_copies=2, I find a MR solution with very high TFZ (~16) and high LLG (>500). So I re-run with ncs_copies=2 with the mr_rosetta_params.eff file in the first run, the program ends at the same point. But the MR solutions all have low TFZ (~5) and small LLG (<60). Here are my two questions, 1) Why does the program stop if i set ncs_copies=2 but not ncs_copies=1? 2) Why the re-run on same data with same parameters give different result? Thanks in advance for helping me on these problems. Regards, Fengyun
Hi Fenyung, 1. I'm not sure why the error message asking you to supply a sequence alignment didn't come up if you set ncs_copies=1; if you send me the input files I can check to see why not. I suspect that supplying a sequence alignment is the right thing to do in any case. 2. When you run Phaser with a given set of parameters you should expect to get the same answer each time. However when you run mr_rosetta with "prerefine=true" you are generating starting models with Rosetta, which uses a random seed that changes every time. Consequently it is not surprising that you would get different results. I hope that this helps! All the best, Tom T ________________________________________ From: [email protected] [[email protected]] on behalf of Ni, Fengyun [[email protected]] Sent: Wednesday, March 18, 2015 11:02 AM To: [email protected] Subject: [phenixbb] A question on MR_Rosetta Hi All, I am working on a dataset diffracted to ~2.8 A and the highest template identity is about 12%. I am trying MR_Rosetta following the online manual with the following command, hhr file and fragment files are prepared as online manual suggested. phenix.mr_rosetta seq_file=../seq.dat data=../in.mtz hhr_files=../xxx-align.hhr read_hhpred.number_of_models=1 read_hhpred.number_of_models_to_skip=0 already_placed=False fragment_files=../aat000_03_05.200_v1_3 fragment_files=../aat000_09_05.200_v1_3 rescore_mr.relax=False ncs_copies=2 use_all_plausible_sg=True nproc=8 group_run_command=sh resolution=4.5 place_model.mr_resolution=4.5 rosetta_modeling.map_resolution=4.5 run_prerefine=true number_of_prerefine_models=1000 >& log this run ends up with the error message like this, Trying to adjust the PDB sequence from alignment file: ---------------------------------------------------------------------------------KMNSKELSLKGLCLR--DDGPGIIIVVGNEKSCKFYENLVMK-------------------DMHNNSISKTWEGYLQDCKFKGWFMKVCNDQDSLLRTLGQ------------ to match the actual PDB sequence: KMNSKELSLKGLCLRIRDDGPGIIIVVGNEKSCKFYENLVMKDMHNNSISKTWEGYLQDCKFKGWFMKVCNDQDSLLRTLGQ New alignment line 4 for PDB: 0 ---------------------------------------------------------------------------------KMNSKELSLKGLCLR--DDGPGIIIVVGNEKSCKFYENLVMK-------------------DMHNNSISKTWEGYLQDCKFKGWFMKVCNDQDSLLRTLGQ------------ Sorry: Sorry, please supply an alignment file for this job. mr_rosetta cannot automatically generate alignments where there are deletions required from the PDB file This only happens when I set ncs_copies=2. If i change ncs_copies=1, no such error. When I looked at the output file with ncs_copies=2, I find a MR solution with very high TFZ (~16) and high LLG (>500). So I re-run with ncs_copies=2 with the mr_rosetta_params.eff file in the first run, the program ends at the same point. But the MR solutions all have low TFZ (~5) and small LLG (<60). Here are my two questions, 1) Why does the program stop if i set ncs_copies=2 but not ncs_copies=1? 2) Why the re-run on same data with same parameters give different result? Thanks in advance for helping me on these problems. Regards, Fengyun _______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb Unsubscribe: [email protected]
participants (4)
-
Ni, Fengyun -
Paul Emsley -
Roger Martin -
Terwilliger, Thomas Charles