Search results for "look through"

Re: [phenixbb] Statistics from 'Scalepack' log file and 'Xtriage' log file

by Nathaniel Echols

On Tue, Feb 14, 2012 at 9:27 AM, Zhang yu <phenixzyfish(a)gmail.com> wrote: > The 'anomalous' signal is not useful to me. It is automatically outputted by > HKL2000 if I use the "auto-correction" option. When "Xtriage" analyze data > and output completeness, how does it handle anomalous signal? As far as I know, Xtriage will treat F+ and F- as separate reflections (at least for the completeness analysis), and the number of expected reflections will be doubled if the data are anomalous. > Why I get such big different completeness from .sca and .mtz (converted from > the .sca) files? Is that because .sca contains incomplete anomalous while > .mtz is non-anomalous? Yes. > This dataset is with very high mosaicity. Imosflm reject two many > reflections during scaling, but HKL2000 kept most of them and outputted > acceptable statistics. I don't know why the resulting .sca file is still > with severe incompleteness. My best guess is that you have overlap problems - I think this is a common result of high mosaicity. I don't know what the best way to handle data like this is, unfortunately; hopefully someone with more knowledge of HKL2000 (or other integration software) can chime in. I'd recommend trying XDS too (you can run it through Xia2 which may be easier). Regardless, I still think this looks like a bug in HKL2000, since I can't see how those statistics correspond to the actual data file. -Nat

13 years, 11 months

[cctbxbb] Post-PHENIX changes

by Graeme.Winter＠Diamond.ac.uk

Morning All, I see from http://phenix-online.org/ That PHENIX 1.14 has been released Now, I see at https://github.com/cctbx/cctbx_project/pulls we have a few fairly hefty pull requests parked as “hold for phenix release” - I would certainly not suggest merging all these in one go however probably we should give some thought to stepping through some of them, deciding which ones we should look at first and starting to merge things? I for one would like Nick’s allocator code to come back into play (so we can make use of it for DIALS) Thoughts / opinions? For info: PHENIX folks did you tag the version which was released in PHENIX 1.14 to allow a release branch for .1 etc. releases? Many thanks Graeme -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

7 years, 4 months

Re: [cctbxbb] mtz2map gridding

by Pavel Afonine

Hi Elliot, I will have a look at phenix.mtz2map. Meanwhile you can use the attached script that exemplifies how you can do this having a great flexibility choosing map gridding! To run this example: phenix.fetch_pdb 1yjp phenix.python run3.py Let me know if you have any questions. Pavel On 2/21/19 11:01, Elliot Nelson wrote: > > Hi All, > > > I've been trying to use Phenix.mtz2map to sample maps to a particular > array size with the "gridding" option, but found that this seems to > have no effect on the output of the program. I was wondering whether > there were some restrictions to the integers that are permitted or > otherwise what might be the cause of this behaviour. Having hunted > through the code it seems to just set n_real in the crystal gridding, > which is then fed into an fft - possibly the latter ignores n_reals > that aren't sensible? > > > Any idea? > > > Thanks, Conor > > > on behalf of Conor Wild: conor.wild(a)oriel.ox.ac.uk > > > Elliot > > > DPhil Student, Systems Approaches to Biomedical Science > <http://www.sabsidc.ox.ac.uk/> > Protein Crystallography <http://www.thesgc.org/groupprofile/9489>, > Structural Genomics Consortium, NDM, University of Oxford > Oxford Protein Informatics Group <http://opig.stats.ox.ac.uk/>, > Department of Statistics, University of Oxford >

6 years, 11 months

[phenixbb] questions

by Jianghai Zhu

Hi, Got some questions in using phenix.refine. 1) Can phenix.refine use the ligand library generated by refmac5? 2) How do I use elbow to generate the ligand library when I have more than one kind of ligands? When I used --residue=xxx more than once, elbow will only generated library for the last ligand. If I use elbow multiple times to generate multiple libraries, how do I read the libraries in? Should I combine them to one file? 3) When I ran phenix.refine, I found the following message in the log. Number of residues, atoms: 32, 418 Unusual residues: {'NAG': 22, 'MAN': 10} Classifications: {'undetermined': 32} Link IDs: {None: 31} Unresolved non-hydrogen bonds: 32 Unresolved non-hydrogen angles: 64 Unresolved non-hydrogen dihedrals: 22 Unresolved non-hydrogen chiralities: 32 Number of residues, atoms: 18, 28 Unusual residues: {'GOL': 2, ' MG': 2, ' CA': 14} Classifications: {'undetermined': 18} Link IDs: {None: 17} I already gave the cif library for NAG. Looks like nothing happened. How come phenix.refine doesn't recognize Glycerol, Mg, and Ca? 4) The refinement (TLS + ML + B individual) went through, I got reasonable R, Rfree, rmsdBOND, rmsdANGLE. But the B factors are pretty low. The B factor of the backbone is much lower than the side chain, some have numbers like 4. Some metal atoms also have B factors around 4. What did I do wrong? Thanks. Jianghai

19 years, 1 month

Re: [phenixbb] Gap between R and Rfree

by Phil Jeffrey

More information would be very helpful for giving detailed suggestions, however: 0. Use Molprobity or the Validation tools in Coot to look at your structure and see what errors you can fix. 1. What is your geometry like ? Try reducing wxc_scale (try wxc_scale=0.5) and see what happens. 2. What is the variation of B-factors across bonds ? Try reducing wxu_scale - perhaps wxu_scale=0.5 or less. 2a. phenix.refine is autocratic about wxu_scale if you're using TLS so setting it yourself does not help. 3. Since R-free of 0.298 is a little high for a 2.5 Angstrom structure, you should carefully check your model. Perhaps you have a high proportion of disordered structure, which can cause this. If you feel that your model is correct, you could explore using TLS on your model. Potential TLS groups can be found using the TLSMD server at: http://skuld.bmsc.washington.edu/~tlsmd/ although the results should always be filtered through a common-sense definition of domain/group boundaries (e.g. don't break in the middle of helices unless there's a good reason to). Phil Jeffrey Princeton Young-Jin Cho wrote: > Hi everyone, > I recently got a diffraction data and am trying to refine it. The question is whatever I did the gap between R and Rfree stay far away: .2140/.2982 around 2.5 A resolution. (water added and isotropic(individual_adp) and so on). > Although I am redoing with many different approaches, if anyone can give me any comments or suggestions, it would be helpful. > > Thanks in advance, > > Young-Jin

15 years, 11 months

Re: [cctbxbb] mmtbx/examples/simulate_experimental_data.py

by 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

7 years, 9 months

Re: [cctbxbb] using scatterer flags?

by Richard Gildea

Are the same scatterers contributing to f_calc for every calculation, or will the scatterers that are contributing vary from calculation to calculation? In the case of the former it might be simplest to create a new copy of the xray_structure with only those scatterers. It looks the "use" flag isn't actually respected in the structure factor or gradient calculations as far as I can tell. If you feel you need something like this rather than creating new copies of the xray_structure with only the scatterers you need or alternatively setting the occupancy to zero, then this is probably something we can add into the code. There is some code in cctbx/xray/scatterer_flags.h for flags_set_grad_*() that will set a selection of gradients all at once in C++, but I don't see an equivalent for set_use_*(). I suspect that the overhead of looping through the scatterers to set flags in Python would be small compared to the cost of calculating the structure factors in the first place. Cheers, Richard On 15 April 2013 10:40, Jan Marten Simons <marten(a)xtal.rwth-aachen.de>wrote: > Am Montag 15 April 2013 18:33:00 schrieb Jan Marten Simons: > > Hi, > > > > while working on a really fast way to calculate the structure factors of > a > > few millions of different modifications of a structure with only the > > selected scatterers contributing to f_calc .... > > [...] > > > (I think building a larger structure and working with > > selections might be faster than creating lots of different structures > > containing only the desired scatterers, but I might be wrong on this.) > > I've found "flags" might be what I'm looking for. So if I could set the > "use" > flag for all scatterers at once and if it was taken into consideration > during > structure factor calculation then I think it would most likely be the > fastest > way to enable or disable the contribution of individual scatterers to the > structure factors. Am I right on this and how would I best interface with > the > flags mechanism (from python)? > > Cheers, > > Jan > _______________________________________________ > cctbxbb mailing list > cctbxbb(a)phenix-online.org > http://phenix-online.org/mailman/listinfo/cctbxbb >

12 years, 9 months

Re: [phenixbb] Discrepancy between R-factors from phenix.refine vs phenix Generate "Table 1"

by Pavel Afonine

Hi, just for completeness... Correctly selecting free-r flags is essential in case of twinning (phenix.refine does it by default). If flags were chosen without having that in mind then "R=0.24, Rfree=0.28" from your example may easily become "R=0.24, Rfree=0.34" once you switch to correctly generated flags. I've seen it more than once. Pavel On 5/31/13 12:15 PM, Jon Schuermann wrote: > Sorry if this is a little long, but I saw that more than one person > was having a similar problem. > > First, I agree with everything Nat has said, but I will explain a > little bit more. Twinning and/or pseudosymmetry can be a hairy issue > to deal with. In some cases, NCS can be a real pain. I have seen many > cases where just pseudosymmetry is present, but people assume it is > twinned as well. To be fair, it is very easy to come to that > conclusion, especially at the early stages. Let me just set the stage > with a hypothetical example... > > You collect a 2.5A dataset that processes well in P622 with an > Rsym=0.11 (overall). The intensity statistics look normal, which I > won't go into right now because it is complicated (even though Nat > eluded to it with the 'L-test'). You perform MR with a search model > that has 60% sequence identity and get a solution with 1 molecule in > the AU in P6522. The solvent content is 0.6. You run the solution > through rigid-body, followed by positional and B refinement with > simulated annealing. The resulting R=0.35, Rfree= 0.40. You look at > the maps and the density does not look good. You can see density for > most of the main-chain but almost all of the side-chain density is not > present. You go about trying to build in the density but the R/Rfree > do not drop much. What is your next step? Some would go to Se-Met or > heavy atom soaks to solve by SAD or MIR, but the results are the > same... Now What? Most people would say, its hexagonal where > merohedral twinning is possible so it must be twinned. You rescale the > data in P6, P312, P321, and even P3 (tetartohedral twinning) and the > Rsym is about the same in all the subgroups with P6 and P3 being the > lowest with Rsym=0.08. You perform MR in P65 and get a solution with 2 > molecules in the AU. To 'check' if it is twinned, you run refinement > twice from the same starting model; first, twin refinement specifying > the 'twin law' (from XTRIAGE), and second regular refinement and then > compare the results. You think the results speak for themselves... > with the twin refinement, the R=0.24, Rfree=0.28 with the twin > fraction refining to 0.49 (nearly perfect twinning). The maps look > great! The regular refinement (without specifying the 'twin law') > refines to R=0.30, R-free=0.32 and the maps look better than P6522, > but not as good as the maps from the twin refinement. You think, 'This > has to be twinned!' But here is the kicker, IT'S NOT TWINNED!!! How > could this be??? > > When you input the 'twin law' in refinement and the twin fraction > refines to >0.4, Phenix detwins using the proportionality rules. This > method uses the model in the detwinning process which WILL introduce > model bias in the maps, so they look great. Even if your model is NOT > correct, the maps will still look good, because of the model bias. For > this reason, you should calculate several 'omit maps' over different > regions of your structure and inspect them, or look at maps calculated > from refinement when you did NOT specify the 'twin law'. As for the > R-factor being lower, the calculated twin R-factor is usually lower > than the standard R-factor since the equations are NOT the same. So, a > drop in R-factor at this early stage is not necessarily conclusive > that your data is twinned. There are a couple of papers explaining > this (which Nat eluded to and I believe I reference below). > > I have seen many people get 'itchy finger' and try to use the twin > refinement too early. As Nat mentioned, you don't want to run it > unless you are at the end of model building and ready for deposition, > but the R-factor is still too high. Then it may be necessary to run > refinement with the 'twin law' included to see if the R-factor drops > 'significantly'. > > To summarize, if you suspect an issue with twinning and/or > pseudosymmetry since the maps don't look as good as they should for a > given resolution and the R-factor is too high, rescale/reprocess your > data in lower symmetry SG's and rerun MR. When you get a solution, > refine it WITHOUT specifying 'twin law' and look at the maps. > A)If they look much better than the solution in the higher > symmetry SG, continue your model building and refinement (WITHOUT > 'twin law') cycles in this lower symmetry SG until the model building > is complete and you would be ready to deposit the structure in the > PDB. If the R-factor is still too high, then run refinement including > the 'twin law' with the twin operator from Xtriage. If you see an > appreciable decrease in R-factor, then you probably have twinning. If > the R-factor dropped, but is still not low enough, then either your > model is still not completely correct or you have something else going > on as well (see end of B below). > B) If the maps still do not look any better than the higher > symmetry SG, try MR in another lower symmetry SG and repeat. I > sometimes go down to P1, if I have enough data. If the maps still look > bad (assuming you have a complete dataset and MR solution), then you > may not have a SG issue at all, but something else. I would look into > other issues including anisotropy, pseudo-translational symmetry, > order-disorder, missing molecules, etc. I will usually scroll through > the images to see if I see something obvious. Reprocess the data more > carefully looking for things like extra spots not predicted, or > predicted spots that aren't actually there, etc. > > Here are a few references to papers that explain some of these issues > more in depth with examples: > Acta Crystallogr. (2008), D64, 99-107. > Acta Crystallogr. (2012), D68, 1541-1548. > Acta Crystallogr. (2006), D62, 83-95. > > I hope this helps some people... > > Jon > > -- > Jonathan P. Schuermann, Ph. D. > Beamline Scientist, NE-CAT > Argonne National Laboratory, 436E > 9700 S. Cass Ave. > Argonne, IL 60439 > > Email:[email protected] > Tel: (630) 252-0682 > > > > > On 05/30/2013 09:26 AM, Nathaniel Echols wrote: >> On Thu, May 30, 2013 at 7:09 AM, Heather Condurso<condurso(a)bc.edu> wrote: >>> I have a similar issue. My data is nearly perfectly twinned so Xtriage usually fails to find any twin law. However when I solve the structure in the lower symmetry space group with twinning my maps look beautiful. In the higher symmetry space group, only 3 of the 6 monomers fit into nice looking density. I simply use generate table 1 and uncheck the box so it won't regenerate R factors. The discrepancy between the R-factors is however much more significant than 2%. From refine I get 18/22 and from table1 28/31. >> That's actually a little surprising that Xtriage wouldn't work - would >> you be willing to send us the data? Keep in mind that if you have >> perfect twinning and refine with the twin law, I think the maps will >> look beautiful pretty much by definition, because of the model bias. >> (Which doesn't mean that you did it wrong - the R-factors sound >> realistic - you just need to be very careful and make lots of omit >> maps.) >> >> It helps to have actual examples when warning against the dangers of >> twin refinement and model bias in general, so here's one (attached). >> This map isn't beautiful, but it matches the model very closely, >> including the complete lack of sidechains. Another Phenix user got >> this result by accident with a mostly-if-not-entirely incorrect MR >> solution - fortunately the combination of missing sidechain density >> and relatively high R-free (~40%) prompted him to email us. I suspect >> that if we searched the PDB we'd find an actual published example >> (especially considering how many spurious ligands have been found >> there). >> >> (Sorry to sound like a broken record here, but this keeps coming up in >> emails and workshops - perhaps we need better validation tools.) >> >> -Nat >> >> >> _______________________________________________ >> phenixbb mailing list >> phenixbb(a)phenix-online.org >> http://phenix-online.org/mailman/listinfo/phenixbb > > > > > _______________________________________________ > phenixbb mailing list > phenixbb(a)phenix-online.org > http://phenix-online.org/mailman/listinfo/phenixbb

12 years, 7 months

Re: [phenixbb] Phenix installation on macOS 14 Sonoma

by Klureza, Maggie

Hi all, Reviving this thread (or trying to, anyway - TBD if I can successfully reply to a thread begun before I'd joined the phenixbb list!), I recently updated my Mac OS to 14/Sonoma, and am now also having issues getting Phenix to work. As directed on the installers page <https://phenix-online.org/download/phenix/release/>, I downloaded the supplied fix <https://phenix-online.org/download/sonoma_fix.tar.gz>, extracted the tarball, and ran that code as `sudo Downloads/sonoma_fix/fix_wxpython.sh /Applications/phenix-1.19.2-4158`. This was the resulting output/error I got: Password: Removing old version of wxPython ================================ Downloads/sonoma_fix/fix_wxpython.sh: line 36: ./bin/conda.exe: No such file or directory Installing new version of wxPython ================================== Downloads/sonoma_fix/fix_wxpython.sh: line 42: ./bin/conda.exe: No such file or directory The wxPython package has been updated in /Applications/phenix-1.20.1-4487. Sure enough, when I went to my phenix installation and looked in conda_base/bin, there was no file named `conda.exe` present. This was true for both my prior installation (phenix-1.19.2-4158) and when I tried a newly downloaded version (phenix-1.20.1-4487). Can anyone tell me how I get that conda.exe file included with the Phenix download/how else I might be able to run Phenix with this OS? (I sent an email about this to help(a)phenix-online.org before thinking to hunt through the phenixbb archive, so apologies to whoever checks that email and is getting this message twice!) Many thanks, Maggie

2 years, 1 month

Re: [phenixbb] Problems placing second component in Phaser

by Gabor Bunkoczi

Hi Morten, this is weird. One way around is to manually superpose the mr_rosetta model onto the original in the full solution, and just do a refinement with Phaser (you can (kind of) do this automatically by running MRage with both models). Another idea is to decrease the rotation peak cutoff when finding the second molecule (PEAKS ROT CUTOFF keyword). BW, Gabor On Feb 18 2013, Morten Groftehauge wrote: >Hi guys, > >So I have a solution that covers some of target and I ran it through >phenix.mr_rosetta and I am actually kinda happy with the output from there. >However, while I can place both (NCS=2) with the original model I only seem >to be able to place one of the rosetta models, even with 'packing function' >set to 'all' or 'allow'. >Original model - >Refinement after placing component 1: LLG 175 >Refinement after placing component 2: LLG 620 >Rosetta model (packing 'all') - >Refinement after placing component 1: LLG 295 >Refinement after placing component 2: LLG 390 >Rosetta model (packing standard) - >Refinement after placing component 1: LLG 295 >Refinement after placing component 2: LLG 350 > >More notably there is little to no increase in TFZ with the placement of >the second component... > >There are more residues in the Rosetta model and I would expect more >clashes but this looks weird. > >Cheers, >Morten > >

12 years, 11 months

Search results for query "look through"