[cctbxbb] mmtbx/examples/simulate_experimental_data.py

[Pavel Afonine]

Hi Elliot,

> I have used phenix.fmodel to generate structure factors (Fcalc) from 
> given atomic model in merged.pdb file. As previously suggested I am 
> using the type=real flag to populate the Fobs with these Fcalc values:
>
>
> phenix.fmodel data_column_label="F,SIGF" merged.pdb free.mtz type=real
>

flag 'type=real' converts complex value Fcalc to real values.

> In the merged.pdb file I set the isotropic B-factor (through u_iso) to 
> a known value (i.e. b=40), and occupancy of the involved ligand/ground 
> state. i.e Occupancy of ligand/ bound state atoms (0.05) and ground 
> state atoms (0.95), all with B Factor =40.
>
>
> Does phenix.fmodel generate its mtz regarding the B factor of 
> individual atoms?
>

To calculate Fcalc you need:
- coordinates;
- ADP (B-factors);
- occupancies;
- atom scattering type (element and charge if available).

(Figure 1 on page 37 here: 
http://phenix-online.org/newsletter/CCN_2015_07.pdf)

that is all information from ATOM record of your PDB file is used 
(except unnecessary decorators, such as chain and atom labels).

> To give context to this question:
>
>
> I then use these Fcalc values to test a brute force search of 
> occupancy and b_factor values. I am searching through 
> Fcalc(1)-Fcalc(2) maps, where Fcalc(1) is the Fcalc generated by 
> phenix.fmodel. Fcalc(2) is generated from the same pdb file, but with 
> occupancy and u_iso of atoms in the ligand/ground state varied (occ 
> 0.05 to 0.95, u_iso 0.2 to 1.2). After this search, I look at the mean 
> over points near bound/ground state of |Fcalc(1)-Fcalc(2)|.
>
>
> My test should be able to uniquely identify the occupancy and B factor 
> values supplied in the merged.pdb file. I can recapitulate the 
> expected occupancy, however I cannot recapitulate this supplied B factor.
>

Since you have all controlled numerical setup, as usual in such cases 
try to simplify the task by varying one parameter at a time. For 
example, make sure occupancy search works (given fixed B), then make 
sure B search works (given fixed q), then vary both and there is no 
reason that should then not work.

Of course there are plenty of details involved here that make this easy 
or tricky, such as what optimization target you use: real or reciprocal 
space? If real space, do you make sure to scale maps by volume (absolute 
scale) and not by rms? What's size of region where you compute 'mean 
over grid points'? etc etc etc etc.

Can't comment more without having more technical details..

Good luck,
Pavel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phenix-online.org/pipermail/cctbxbb/attachments/20180510/14453fc2/attachment-0001.htm>