Nathan Were those examples you computed earlier SA omit? That example looked a lot better than what I usually get. Do you have any pseudomerohedral cases? FR On Feb 17, 2010, at 4:56 PM, Nathaniel Echols wrote:

My understanding is that this is considered bad practice, unless simulated annealing is added in to remove leftover phase bias. It would be better to simply take the last refined model before any ligand was added and use that - but an SA omit map would also be acceptable. (Experimental density, if you have it, would be even better.)

--------------------------------------------- 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 Kelly, step-by-step: 1) Take your current best model and remove the ligand. 2) Run phenix.refine as following: phenix.refine model.pdb data.mtz ligands.cif simulated_annealing=true twin_law="-h,-k-l" This will create the desired maps. Alternatively to SA omit map, you can compute Averaged Kick omit map (see below). Pavel. PS: *Kick maps:* "(...) An average kick map (AK map) is computed as following (Gunc(ar et al., 2000; Turk, 2007; Praz(nikar et al., 2009): a large ensemble of structures (several hundreds) is created where the coordinates of each structure from the ensemble are all randomly shaken. The shake amount (rmsd distortion introduced to coordinates) varies from 0 to 1.0 Å. Then for each structure a map is computed ((mFobs-DFmodel)exp(i?model) or (2mFobs-DFmodel)exp(i?model) or any other map, for example a ligand-omit map). Finally, all maps are averaged out to produce one averaged kick map. An AK map is expected to have less or no bias, less noise, enhance existing signal and potentially can clear up some initially bad densities. (...)" On 2/18/10 9:55 AM, Kelly Daughtry wrote:

Thanks everyone for the fast responses!

Ok, so I have tried all of the suggestions.

1) Generate a refinement..eff file which includes the twin law.

When I run from the gui, I do not believe that phenix is actually including the twin law. It is not shown as being read in the log file (but the log file show that the refinement.eff was an input). And the maps look the same as without the twin law. So, either I am doing something wrong, or it is not reading the twin law.

From the command line: phenix.autobuild twin_law="-k,-h,-l" data.mtz model.pdb omit.eff (generated from omit_map autobuild.eff)

ERROR: AssertionError: Sorry, unknown file or keyword: twin_law=-k -h -l Possibilities... (use 'phenix.autobuild --help all' to get full help): rebuild_in_place.rebuild_chain_list=-k -h -l omit.omit_chain_list=-k -h -l model_building.consider_main_chain_list=-k -h -l

So it seems it doesn't know where to include the twin law.

Including this in autobuild.eff:

twinning { twin_law = -h,k,-l } (I also tried variations on location of lines and within the refinement parameters and such)

AssertionError:

Sorry, unrecognized variable: twin_law = -h,k,-l

NOTE: this could just be in the wrong scope. Here is the scope found: autobuild.twinning.twin_law (input line 28)

I looked into the autobuild log file created when I ran the omit_map without including a twin law, and I do not see any place where that is taken into account.

2) Omiting ligand and generating difference map (either in phenix.refine or in create maps utility) The maps are great, but I really want a SA omit map.

As Nathaniel Echols pointed out, it seems like bad practice. I am unsure how the entire community feels on the issue, but I have been taught that a SA omit map gives you validation of your model (especially in the case of a lignad).

So, what else can I try? Or what am I doing wrong?

Kelly ******************************************************* Kelly Daughtry PhD Candidate Department of Physiology and Biophysics Boston University School of Medicine 590 Commonwealth Ave R 390 Boston MA, 02215 (P) 617-358-5548 *******************************************************

On Thu, Feb 18, 2010 at 8:57 AM, Francis E Reyes wrote:

...

Nathan

Were those examples you computed earlier SA omit? That example looked a lot better than what I usually get. Do you have any pseudomerohedral cases?

FR

On Feb 17, 2010, at 4:56 PM, Nathaniel Echols wrote:

...

My understanding is that this is considered bad practice, unless simulated annealing is added in to remove leftover phase bias. It would be better to simply take the last refined model before any ligand was added and use that - but an SA omit map would also be acceptable. (Experimental density, if you have it, would be even better.)

--------------------------------------------- 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://phenix-online.org/mailman/listinfo/phenixbb

_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb

On Feb 18, 2010, at 5:57 AM, Francis E Reyes wrote:

Were those examples you computed earlier SA omit? That example looked a lot better than what I usually get. Do you have any pseudomerohedral cases?

No, I was too impatient to wait for simulated annealing, but I started it up when I got here this morning - you're right, it's much much worse than the non-SA map, and much worse than anything I've seen from the same procedure run on a non-twinned structure. http://cci.lbl.gov/~nat/img/phenix/omit_detwinned_sa.png I'm not sure why this is - I double-checked the logs, and phenix.refine was definitely using the twin law, and the R-factors were what I'd expect (R-free around 22%, versus 35% if no twin law is used). I am running it again without the twin law for comparison. (We probably have a pseudomerohedral structure somewhere in our local "structure library" - hopefully someone else can tell me where to look.) Nat ------------------- Nathaniel Echols Lawrence Berkeley Lab 510-486-5136 [email protected]

Hi Francis, you can compute SA omit map in phenix.refine right now, regardless whether you have twinning or not. I wrote how you can do it in previous email - just two trivial steps! Pavel. On 2/18/10 11:18 AM, Francis E Reyes wrote:

...

No, I was too impatient to wait for simulated annealing, but I started it up when I got here this morning - you're right, it's much much worse than the non-SA map, and much worse than anything I've seen from the same procedure run on a non-twinned structure.

http://cci.lbl.gov/~nat/img/phenix/omit_detwinned_sa.png

Ah! I was losing sleep thinking I was the only one who had this issue.

Xtal refinement is dominated by three programs (correct me if I'm wrong). Refmac, phenix.refine, and cns. simulated annealing is handled by phenix.refine and cns, but twinning is handled (decently) by refmac and phenix.refine. Given this, phenix.refine seems to be the only solution when you have twinning and want to calculate an sa-omit (unless you decide to "grow a better crystal"). Therefore, fixing this for phenix would be much needed!

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://phenix-online.org/mailman/listinfo/phenixbb

OK, let's experiment. I'm taking a porin model and I know that the data is affected by twinning (porin.pdb and porin.mtz). 1) Let's run Xtriage to find out the twin law: phenix.xtriage porin.mtz and it gives me this: Statistics depending on twin laws ----------------------------------------------------------------------------------------------------------------- | Operator | type | R obs. | Britton alpha | H alpha | ML alpha | ----------------------------------------------------------------------------------------------------------------- | -2/3*h-1/3*k+2/3*l,-1/3*h-2/3*k-2/3*l,2/3*h-2/3*k+1/3*l | PM | 0.410 | 0.079 | 0.084 | 0.022 | | -h,1/3*h-1/3*k+2/3*l,2/3*h+4/3*k+1/3*l | PM | 0.419 | 0.070 | 0.069 | 0.022 | | -1/3*h+1/3*k-2/3*l,-k,-4/3*h-2/3*k+1/3*l | PM | 0.415 | 0.070 | 0.075 | 0.022 | | -h,2/3*h+1/3*k-2/3*l,-2/3*h-4/3*k-1/3*l | PM | 0.420 | 0.068 | 0.069 | 0.022 | | 1/3*h+2/3*k+2/3*l,-k,4/3*h+2/3*k-1/3*l | PM | 0.415 | 0.074 | 0.077 | 0.022 | | -1/3*h-2/3*k-2/3*l,-2/3*h-1/3*k+2/3*l,-2/3*h+2/3*k-1/3*l | PM | 0.413 | 0.078 | 0.079 | 0.022 | | h,-h-k,-l | M | 0.195 | 0.292 | 0.315 | 0.304 | ----------------------------------------------------------------------------------------------------------------- so I'm still puzzled which twin law to choose from the above list, so I run phenix.model_vs_data: phenix.model_vs_data porin.{mtz,pdb} > model_vs_data.log phenix.model_vs_data will score the possibilities: it internally runs Xtriage to get the twin law and then it computes the R-factors with and without considering twining and based on this it tells you what you have. Ok, phenix.model_vs_data outputs: (...) Data: twinned : h,-h-k,-l (...) and I take "h,-h-k,-l" as my twin_law. 2) Next, I' going to run two refinements - with and without considering twinning: phenix.refine porin.{pdb,mtz} output.prefix=twin twin_law="h,-h-k,-l" --overwrite and phenix.refine porin.{pdb,mtz} output.prefix=no_twin Obviously, considering twinning is a good idea: twin_001.pdb: Final: r_work = 0.1207 r_free = 0.157 no_twin_001.pdb: Final: r_work = 0.2038 r_free = 0.2475 3) Now let's play with SA omit maps. The file "porin.pdb" contains a ligand "C8E". I'm omitting the ligand from twin_001.pdb file (twin_001_NoLigand.pdb) and start SA refinement: phenix.refine porin.mtz twin_001_NoLigand.pdb output.prefix=twin_sa_omit twin_law="h,-h-k,-l" simulated_annealing=true --overwrite and the result is: twin_sa_omit_001.pdb: Final: r_work = 0.1224 r_free = 0.1650 which is slightly worse than twin_001.pdb: Final: r_work = 0.1207 r_free = 0.157 but is not surprising at all since: - By omitting the ligand we made the model worse. One should not expect the omit map look better than the regular map; - SA is good for correcting large errors. This is why it does very good at the beginning of refinement, but it rather harms when you run it with a good close-to-final structure. The maps twin_sa_omit_001_map_coeffs.mtz and twin_001_map_coeffs.mtz look almost identical, and the mFo-DFc omit map shows the ligand. From this I conclude that the program works as expected and does not contain obvious bugs. If you experience a problem with your particular structure, then I think it's case-specific. All the files mentioned above are located here: http://cci.lbl.gov/~afonine/twinning_experience/porin/ Let me know if you have any questions. Pavel.