Search results for "look through"

Re: [phenixbb] alternatives to RMSD

by Pavel Afonine

Hi Patrick, RMSD is a poor measure in this case as it does not account for B-factors, occupancies, alternative conformations and so on information a crystal structure model may make available. Macromolecules are not a bunch of points in space. While I'm sure more thorough methods exist, I would vote for the simplest, most direct and obvious one. You can calculate electron density map using a Gaussian approximation from model A and B (yes, electron density map - not a Fourier image of it!). That will naturally account for all: B-factors, occupancies, other disorder. Then you can calculate a map similarity measure, such as map correlation, for instance. After all, why use a cannon to kill a fly?! If you are interested to follow this route I can explain the details. All the best, Pavel > Hi Phenix users, > > I am not a crystallographer but I though you guys might be a good > place to ask this question. > > I have 2 super secondary structures, A and B and they consist of > Helix-turn-Strand > > Due to the turn the two structures have a poor RMSD because the two > flanking fragments of Helix and Strand are far from each other but > when I superimpose the two fragments individually(helixA with helix B > and standA with strandB in Pymol they align very well). > > Now, is there a way to express this instead of using the RMSD? > When the two structures align well the RMSD is very good but a slight > movement and the RMSD is awful. > But looking at the two structures I can see they follow the same path > through space. > > Thank you, > Patrick

10 years, 11 months

Re: [phenixbb] GUI parameter files

by Leonid Sazanov

Hi, I downloaded dev-1005 version and in Graphics window there is no Sec.Str.? Thanks, Leo >>>>> It's messy - click "Graphics" on the toolbar, then "Sec. Str." on the toolbar of the graphics window, which will open the editor for these restraints. I will make this more accessible ASAP, and I'll add a menu option to simply wipe out the current definitions. Dr. Leonid A. Sazanov Research group leader Medical Research Council Mitochondrial Biology Unit Wellcome Trust / MRC Building Hills Road Cambridge CB2 0XY WEB: www.mrc-mbu.cam.ac.uk Tel: +44-1223-252910 Fax: +44-1223-252915 On 15/03/2012 19:29, Leonid Sazanov wrote: > Hi, I have a following problem in dev-874 version: > > If I restore a previous job in refine GUI, to run it with modified > settings, and include a new parameter file .eff with definitinon of > secondary structure restrains, these new restrains are combined with > previously used restrains. > How do i get rid of previous restrains? Older file is not visible in > inputs, but its settings are still used. > And in general, how can one be sure which parameters are used at the > start of each refine run? > If older settings loaded from .eff or .param file are not visible, the > only way is to look through new .eff file, which takes a lot of time. > Has this been solved in latest builds perhaps? > Thank you, > Leo >

13 years, 3 months

Re: [cctbxbb] differing build and install directories?

by Ralf W. Grosse-Kunstleve

Hi Bill, Sorry that I dropped the ball on this question before. Erik outlines the best way of creating a portable cctbx bundle, but in this case there may be a simpler alternative: - simply cp -r the installation into the final destination - re-run python .../libtbx/configure.py mmtbx in the new build directory location. This will update all full paths. Note though that this simple approach will preserve all intermediate files created by the build procedure (i.e. all the .o files and some auto-generated C++ files). But please try this out first. If it does what you want we can think about ways of getting rid of the unwanted files. > The other issue is that I need to hard-code in the DYLIB path I hope that we don't have to do this, although I'd be willing to modify the central SConscript to optionally support hard-coded paths if there really is no alternative. > instead > of relying on an environment variable, which I am not allowed to set. All cctbx commands on PATH go through "dispatchers". To see how it works, look at any of the auto-generated scripts in the "bin" subdirectory of the build directory. The dispatchers are basically all the same; only the last few lines differ. Each dispatcher updates PYTHONPATH and DYLD_LIBRARY_PATH "just in time" to finally start the target command. I.e. there are no permanent settings in the environment. You just have to add the "bin" directory to PATH if you don't want to type the full path name to each command all the time (which will also work). Is this going to work for you? Cheers, Ralf

19 years, 9 months

Re: [phenixbb] autobuild 'hires_file'

by Thomas C. Terwilliger

Hi Brian, The problem is in that version of phenix. I'm sorry about that! Can you possibly update to the current version...if that doesn't fix it then please let me know! > i have phenix 2007_08_18_1856, (and i think latest cci apps). > > i have a jumble of questions, i'll try step by step: > > [1 A] in phenix.autobuild, e.g. a SAD dataset, does the flag > 'hires_file=w1.sca' (help says "Merge in hires data"), mean that phases > will be extended to a high resolution limit as found in w1.sca? (vide > infra) Yes, that is correct. > > [1 B] can the labels be the same as the 'other' data (the documentation > suggests this)? The labels are figured out and used totally independent of the other data (labels for hires are input_hires_labels as you mention below) > > i have tried a few things like : > > phenix.autobuild data=resolve.mtz hires_file=high_resolution.mtz > input_hires_labels='FPnat SIGFPnat' seq_file=seq.txt > > ... and i see > > Cell: [99.810997009277344, 99.810997009277344, 140.37300109863281, 90.0, > 90.0, 90.0] > New resolution: 2.20520367253 > High-res file input labels: ['FPnat', 'SIGFPnat'] > > ... which is good, but the job promptly fails with this cryptic (to me) > error message: > > ************************************************************ > Failed to carry out AutoBuild_datafile_info_inputs: > 'all_input_hires_labels' > ************************************************************ > > ... (google:all_input_hires_labels and looking through docs quick didn't > find it) > Yes, that's an error in autobuild, not your error. -Tom T

17 years, 7 months

[phenixbb] Autosol Feedback and questions

by Partha Chakrabarti

Happy new year everybody, I had quite a bit of difficulty with a SAD dataset which also showed Sulphur. Previously I had tried SHELEX to find sites, MLPHARE to refine, AddSOLVE to find more , and both SOLVE and PHASER to solve but it did not get to a point where I could do manual building. Autosol worked beautifully, the input files were scalepack merged data, ha.pdb (from addsolve step), and the sequence. PHASER to solve and TEXTAL & RESOLVE with through build option. This actually leave me with some confusions / questions: 1. When I compare the other "solutions", they look like the right one, just not good enough. Where exactly is the autosol making a difference? Is it the ability of of TEXTAL to build something more meaningful when the solution is not good or number of iterations? 2. How does PHASER know the different anomalous atoms? Does is use a different scaling factor for SE and S? 3. I see that phenix.refine has been used in the internal runs, I have used phenix.refine earlier. But after playing with the side chains in Coot, when I tried to use the modified pdb file and resolve.mtz, it complained about the good old Free_R flag. However, it ran directly in Refmac. Is it a known problem or maybe I did something stupid? I could do a dry run and change the read mtz and not cns if that would solve the problem. 4. Lastly, is it possible to use multiple processors to run the job? Best regards, Partha -- MRC National Institute for Medical Research Division of Molecular Structure The Ridgeway, NW7 1AA, UK Email: pchakra(a)nimr.mrc.ac.uk Phone: + 44 208 816 2515

17 years, 6 months

Re: [phenixbb] rotamers

by Ed Pozharski

Pavel, > - what you mean by "no density", Lack of confidence in placement of the side chain. Everyone would have somewhat different take on it, but the question is more about what to do, not how to decide if the side chain is disordered. > Therefore this raises another item for your questionnaire: There is "other" option, feel free to use it > refine group > occupancy for these atoms (one occupancy per all atoms in question - the > occupancy typically will refine to something less than 0.5 or so). This raises an entirely different question regarding reliability of occupancy refinement in general due to its correlation with the B-factors. Another can of worms. > This trick with smearing out an atom by B-factor may only work for > isolated (single) atoms such as waters because they are not bonded to > anything through restraints. Certainly, presence of restraints makes the B-factor increase less steep. I just looked at an instance of a disordered arginine (no density above 1 sigma for any side chain atoms), and B-factors jump from 30 at the backbone to 90 at the tip of the side chain. This would reduce the density level ~5x, which is probably quite sufficient for blending it into the solvent. There could be a bit of a problem in the middle, where B-factors are inflated/deflated, but it does take care of density reduction. Things like atom-specific restraints and modified restraint target may be of some help, but the effect on the final model may be too small to validate the effort. -- "I'd jump in myself, if I weren't so good at whistling." Julian, King of Lemurs

14 years, 3 months

Re: [phenixbb] red blobs (Andrea Smith)

by Andrea Smith

Hi, I went through the paper quickly during the day thinking I will have a thorough look at home only to realize I don't have acces to it. >From the quick look it seemed that my biological background will not be enough to understand all of it, but I remember that it said at the end that the mosaic model is implemented in phenix. However, I don't know where. I went through the parameters in GUI and didn't find anything that seemed to fit the description. Could you please explain what setting I need to use in the refinement? Thank you, best, Andrea On Friday, March 15, 2024 16:16 CET, Pavel Afonine <pafonine(a)lbl.gov> wrote: Hi All, The explanation of the reason for these blobs and the solution is both detailed in depth in this paper: https://onlinelibrary.wiley.com/doi/abs/10.1002/pro.4909 Quick facts are: - These blobs are artifacts of bulk-solvent modeling. - You can efficiently deal with them in Phenix. - In some cases (which I witnessed myself), it is important to deal with them for map improvements elsewhere (for example, in regions of interest, such as ligands). Let me know if you have any questions! All the best, Pavel On 3/15/24 07:39, Mitchell D. Miller wrote: > Hi Andrea, > > You can also put a few zero occupancy atoms in the negative > density to force phenix.refine to exclude the region > from the bulk solvent mask. > > (You may also need to set > refinement.mask.ignore_zero_occupancy_atoms = False > so that the zero occupancy atoms are included in the mask) > > Regards, > Mitch > > > > Quoting Kay Diederichs <kay.diederichs(a)uni-konstanz.de>: > >> Hi Andrea, >> >> hmm, did phenix.refine actually use optimize_mask=true ? >> >> If you compare the logfiles of phenix.refine (for the default run >> with opimize_mask=false, and the new run with optimize_mask=true) >> side-by-side with xxdiff or vimdiff (yes this needs to be run from a >> command-line) then there should be a difference. >> >> Making peace with the red blobs is somewhat unsatisfactory from a >> technical viewpoint, but probably not relevant from a biological one. >> >> I'd guess that the authors of >> https://journals.iucr.org/a/issues/2024/02/00/pl5035/index.html would >> be interested to look at your case ... >> >> Best wishes, >> Kay >> >> >> Am 15.03.24 um 08:27 schrieb Andrea Smith: >>> Hi Kay, >>> >>> I tried the mask optimization and there is no change in how the >>> final map looks like. >>> >>> Should I just make peace with it? >>> >>> Best, >>> Andrea >>> >>> On Thursday, March 14, 2024 23:11 CET, Kay Diederichs >>> <kay.diederichs(a)uni-konstanz.de> wrote: >>>> Hi Andrea, >>>> >>>> in your case, phenix.refine seems to fill bulk solvent into volumes >>>> that >>>> are not actually filled by solvent. >>>> It might help to optimize the mask, see >>>> https://phenix-online.org/documentation/reference/refinement.html#bulk-solv… >>>> >>>> "6. Mask parameters". >>>> >>>> Best, >>>> Kay >>>> -- >>>> Kay Diederichs http://strucbio.biologie.uni-konstanz.de >>>> email: Kay.Diederichs(a)uni-konstanz.de Tel +49 7531 88 4049 >>>> Fachbereich Biologie, Universität Konstanz, Box M647, D-78457 Konstanz >>>> >>>> This e-mail is digitally signed. If your e-mail client does not >>>> have the >>>> necessary capabilities, just ignore the attached signature >>>> "smime.p7s". >>>> _______________________________________________ >>>> phenixbb mailing list >>>> phenixbb(a)phenix-online.org >>>> http://phenix-online.org/mailman/listinfo/phenixbb >>>> Unsubscribe: phenixbb-leave(a)phenix-online.org >> >> -- >> Kay Diederichs http://strucbio.biologie.uni-konstanz.de >> email: Kay.Diederichs(a)uni-konstanz.de Tel +49 7531 88 4049 >> Fachbereich Biologie, Universität Konstanz, Box M647, D-78457 Konstanz >> >> This e-mail is digitally signed. If your e-mail client does not have the >> necessary capabilities, just ignore the attached signature "smime.p7s". > > > > > _______________________________________________ > phenixbb mailing list > phenixbb(a)phenix-online.org > http://phenix-online.org/mailman/listinfo/phenixbb > Unsubscribe: phenixbb-leave(a)phenix-online.org

1 year, 3 months

Re: [phenixbb] Fw: Strange behaviour of phenix.maps fill_missing_f_obs

by Tristan Croll

Hi Pavel, That does look promising! I'll switch my code over to use that approach instead, and have a play with it. However, I do believe there is a bug in the "kick map" option that may be causing problems for some. Best regards, Tristan ________________________________ From: Pavel Afonine <pafonine(a)lbl.gov> Sent: Friday, 6 February 2015 11:34 AM To: Tristan Croll; phenixbb(a)phenix-online.org Subject: Re: [phenixbb] Fw: Strange behaviour of phenix.maps fill_missing_f_obs Hi Tristan, in recent Phenix versions we replaced "kick map" option with a generalized (and more sophisticated) concept that we call FEM - Feature Enhanced Map. The paper is scheduled to appear in Acta D: http://journals.iucr.org/d/services/readerservices.html Meanwhile you can read through the set of pages that explain the concept and show examples: http://www.phenix-online.org/presentations/fem_06MAY2014.pdf Let me know if you have questions! Pavel On 2/5/15 1:12 AM, Tristan Croll wrote: My previous email was hung up in moderation due to my attaching a jpeg that tripped the size limit. In any case, I've done a bit more testing and the problem doesn't actually originate in the fill_missing_f_obs, but in the kicked map algorithm. If, as per the attached parameter file, I have a kicked map in the to-do list, every map past that point is garbled (the kicked map itself appears fine). Set kicked to False, and all maps come out looking normal. I should also note that the sharpening_b_factor parameter seems inverted from the normal convention: a negative value gives smoothing rather than sharpening. Cheers, Tristan ________________________________ From: Tristan Croll Sent: Thursday, 5 February 2015 3:47 PM To: phenixbb(a)phenix-online.org<mailto:[email protected]> Subject: Strange behaviour of phenix.maps fill_missing_f_obs Hi, I'm working on a package that makes scripted calls to phenix.refine to generate a series of ccp4 formatted maps, and have run into an odd problem. Using the attached parameter file I get a series of perfectly normal-looking maps, except in the case of the filled 2mFo-DFc map (test-3_2mFo-DFc_fill.ccp4 - the second-last map generated). This comes out as a series of disconnected blobs (it looks rather like a mFo-DFc map, but it doesn't match the actual mFo-DFc map). When I take the resulting .mtz file and generate the filled map in Coot (with or without omission of Rfree flags), on the other hand, it seems to come out fine. There are no error messages in the log, but I suspect the default method to fill in the missing F_obs may be returning only the missing F_obs? I've attached a small example image. Red wireframe is the 2mFo-DFc unfilled map at 1 sigma; green translucent is the 2mFo-DFc filled map at 1 sigma; yellow is the mFo-DFc map at 2 sigma. The test structure I'm using is nothing special: 3WSY, picked more-or-less at random off the protein data bank. Phenix version is 1.9.1692, installed in Fedora 21. Have I done something wrong that I'm just not seeing, or is there a bug here? Thanks, Tristan _______________________________________________ phenixbb mailing list phenixbb(a)phenix-online.org<mailto:[email protected]> http://phenix-online.org/mailman/listinfo/phenixbb

10 years, 4 months

Re: [cctbxbb] First svn commit

by Graeme.Winter＠diamond.ac.uk

+1 If I want to make sense of a function the first thing I do is look at the keyword arguments: if I see "not telling" it does not make the code more usable to me. Of course if the doc strings define exactly what keywords to pass in and what they should do then fair enough: I have not looked closely enough at these examples to comment on the details. Unlijke Pavel I would not necessarily write my own though :o) Best wishes, Graeme On 18 Apr 2013, at 07:10, Pavel Afonine wrote: > When I look at a function and do not understand what it does given it's name and list of arguments I look no more and write my own. Always. This is because my believe that if the author of that function did not bother to make the interface clear it says something about quality of the job as a whole (to me at least), and I don't have time to take chances or waste it reading more. > > Pavel > > On 4/17/13 11:02 PM, Nathaniel Echols wrote: >> On Wed, Apr 17, 2013 at 10:19 PM, Richard Gildea <rgildea(a)gmail.com> wrote: >>> Also, I would prefer the function arguments to be spelled out explicitly >>> without using *args and **kwds, so that I can figure out what arguments it >>> takes without having to read through the function source code to figure out >>> that internally you are calling self.as_miller_arrays(), and then have to go >>> and look up the function arguments for that. >> My preference is actually the opposite (I do the same thing quite a >> bit in my code), because otherwise there is no guarantee that keyword >> arguments added to add_miller_arrays will also be usable with >> add_miller_arrays_map. Using *args, **kwds makes the APIs explicitly >> the same. (That said, I'm increasing favoring using **kwds alone in >> these circumstances.) >> >>> My IDE (WingIDE) shows me the >>> function signature in its source assistant and also provides code completion >>> for function arguments and keywords. However these won't be of much use when >>> functions only list *args and **kwds. >> <insert generic snarky vi advocacy here> >> >> -Nat >> _______________________________________________ >> cctbxbb mailing list >> cctbxbb(a)phenix-online.org >> http://phenix-online.org/mailman/listinfo/cctbxbb > > _______________________________________________ > cctbxbb mailing list > cctbxbb(a)phenix-online.org > http://phenix-online.org/mailman/listinfo/cctbxbb -- 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

12 years, 2 months

Re: [phenixbb] Need help in refining my twinned P6322(apparent) dataset

by Phil Jeffrey

John, The test here would be "which maps looks better" and if there isn't any obvious interpretable difference density for a missing/modified part of the structure you might generate some by leaving out a well-ordered element of the structure prior to the first pass through refinement in each of your P321 and P63 cases. Personally I would rebuild both P321 and P63 structures at the same time, and see if any meaningful differences manifest. That having been said, I want to raise the unfortunate possibility that you're really in P3 and doubly twinned. As far as I know phenix.refine does not handle that so it's difficult to test for. However I did have one case that appeared to fit within that scheme (also in trigonal). If you didn't generate your Free R flags within Phenix itself (which typically handles this correctly), you need to make sure that they obey point group 622 symmetry even in lower symmetry trials, to minimize R-free biasing due to NCS and twinning. Phil Jeffrey Princeton On 3/15/11 2:55 AM, John Pak wrote: > Hey Phenix community, > > Here are the details of my current situation - any assistance in the > matter would be greatly appreciated as I've been struggling mightily for > the past month trying to get this structure refined (to no avail). > > Details: > > -3.0 angstrom dataset from a membrane protein crystal > -reduced in a P3 Bravis lattice using HKL2000 > -Pointless and Xtriage suggest P622 symmetry > -Solved structure via MR - ran Phaser in all P622 based space groups, > found 1 convincing solution in P6322 (LLG ~110) which makes biological > sense (1 monomer in ASU that lies on the screw axis to recapitulate the > biological trimer) > -31% sequence identical search molecule > -no pseudotranslation (via Xtriage) > > Xtriage suggests that the P6322 dataset is nearly perfectly twinned > (twin fraction = 0.49). Mindful of the fact that there are no twin > operators for P6322, I'm thinking that the true space group is P321, > P312 or P63 and I've tried a number of things listed below: > > 1. Refined in P6322 (simulated annealing+individual B). Missing side > chains and incorrectly modelled loops apparent in maps. Start R=0.49, > Rfree=0.5. Refinement stalls at R=0.41, Rfree=0.45 after building. > > 2. Ran Phaser in P312 (using unrefined model) - no solution. > > 3. Ran Phaser in P321 (using unrefined model). One nice solution (LLG > ~220) - lattice looks very similar to P6322 crystal packing. Twin > refinement in phenix using operator suggested by Xtriage (simulated > annealing + individual B) results in R=0.38, Rfree=0.41 (no rebuilding > performed). > > 4. Ran Phaser in P63 (using unrefined model). Three solutions (LLGs all > ~210) - solution #3 looks very similar to P6322 crystal packing. Twin > refinement in phenix using operator suggested by Xtriage of solution #3 > gives R=0.37, Rfree=0.40 (no rebuilding performed). Solutions #1 and #2 > do not give packing arrangements that look like the P6322 solution. Twin > refinement of Sol 1 and 2 give higher R factors. > > So I'm at a loss as to which space group my crystal truly belongs to, > and where I should be focusing my refinement. The maps all look similar > before and after DM. > > Thanks for any assistance or recommendations that you might have!

14 years, 3 months

Search results for query "look through"