Search results for "look through"

Re: [phenixbb] Table 1 successor in 3D?

by Gerard Bricogne

Dear John and Loes, Thank you for reiterating on this BB your point about depositing raw diffraction images. I will never disagree with any promotion of that deposition, or praise of its benefits, given that I was one of the earliest proponents and most persistently vociferous defenders of the idea, long before it gained general acceptance (see Acta D65, 2009 176-185). There has never been any statement on our part that the analysis done by STARANISO disposes of the need to store the original images and to revisit them regularly with improved processing and/or troubleshooting software. At any given stage in this evolution, however, (re)processing results will need to be displayed, and it is with the matter of what information about data quality is conveyed (or not) by various modes of presentation of such results that Bernhard's argument and (part of) our work on STARANISO are concerned. Furthermore we have made available the PDBpeep server at http://staraniso.globalphasing.org/cgi-bin/PDBpeep.cgi that takes as input a 4-character PDB entry code and generates figures from the deposited *merged amplitudes* associated with that entry. The numbers coming out of a PDBpeep run may well have questionable quantitative value (this is pointed out in the home page for that server) but the 3D WebGL picture it produces has informative value independently from that. Take a look, for instance, at 4zc9, 5f6m or 6c79: it is quite plain that these high-resolution datasets have significant systematic incompleteness issues, a conclusion that would not necessarily jump out of a Table 1 page, even after reprocessing the original raw images, without that 3D display. The truly pertinent point about this work in relation to keeping raw images is that the STARANISO display very often suggests that the merged data have been subjected to too drastic a resolution cut-off, and that it would therefore be worth going back to the raw images and to let autoPROC+STARANISO apply a more judicious cut-off. Sometimes, however, as in the example given in Bernhard's paper, significant data fail to be recorded because the detector was positioned too far from the crystal, in which case the raw images would only confirm that infelicity and would provide no means of remediating it. With best wishes, Gerard. -- On Wed, Jun 06, 2018 at 09:35:38AM +0100, John R Helliwell wrote: > Dear Colleagues > Given that this message is now also placed on Phenixbb, we reiterate our > key point that deposition of raw diffraction images offers flexibility to > readers of our science results for their reuse and at no cost to the user. > As with all fields our underpinning data should be FAIR (Findable, > Accessible, Interoperable and Reusable). Possibilities for free storage of > data are Zenodo, SBGrid and proteindiffraction.org (IRRMC). > With respect to graphic displays of anisotropy of data Gerard's three > figures are very informative, we agree. > Best wishes > > Loes and John > > Kroon-Batenburg et al (2017) IUCrJ and Helliwell et al (2017) IUCrJ > > On Tue, Jun 5, 2018 at 4:49 PM, Gerard Bricogne <gb10(a)globalphasing.com> > wrote: > > > Dear phenixbb subscribers, > > > > I sent the message below to the CCP4BB and phenixbb at the same > > time last Friday. It went straight through to the CCP4BB subscribers > > but was caught by the phenixbb Mailman because its size exceeded 40K. > > > > Nigel, as moderator of this list, did his best to rescue it, but > > all his attempts failed. He therefore asked me to resubmit it, now > > that he has increased the upper size limit. > > > > Apologies to those of you who are also CCP4BB subscribers, who > > will already have received this message and the follow-up discussion > > it has given rise to. > > > > > > With best wishes, > > > > Gerard. > > > > ----- Forwarded message from Gerard Bricogne <gb10> ----- > > > > Date: Fri, 1 Jun 2018 17:30:48 +0100 > > From: Gerard Bricogne <gb10> > > Subject: Table 1 successor in 3D? > > To: CCP4BB(a)JISCMAIL.AC.UK, phenixbb(a)phenix-online.org > > > > Dear all, > > > > Bernhard Rupp has just published a "Perspective" article in > > Structure, accessible in electronic form at > > > > https://www.cell.com/structure/fulltext/S0969-2126(18)30138-2 > > > > in which part of his general argument revolves around an example > > (given as Figure 1) that he produced by means of the STARANISO server > > at > > http://staraniso.globalphasing.org/ . > > > > The complete results of his submission to the server have been saved > > and may be accessed at > > > > http://staraniso.globalphasing.org/Gallery/Perspective01.html > > > > and it is to these results that I would like to add some annotations > > and comments. To help with this, I invite the reader to connect to > > this URL, type "+" a couple of times to make the dots bigger, and > > press/toggle "h" whenever detailed information on the display, or > > selection of some elements, or the thresholds used for colour coding > > the displays, needs to be consulted. > > > > The main comment is that the WebGL interactive 3D display does > > give information that makes visible characteristics that could hardly > > be inferred from the very condensed information given in Table 1, and > > the annotations will be in the form of a walk through the main > > elements of this display. > > > > For instance the left-most graphical object (a static view of > > which is attached as "Redundancy.png") shows the 3D distribution of > > the redundancy (or multiplicity) of measurements. The view chosen for > > the attached picture shows a strong non-uniformity in this redundancy, > > with the region dominated by cyan/magenta/white having about twice the > > redundancy (in the 6/7/8 range) of that which prevails in the region > > dominated by green/yellow (in the 3/5 range). Clear concentric gashes > > in both regions, with decreased redundancy, show the effects of the > > inter-module gaps on the Pilatus 2M detector of the MASSIF-1 beamline. > > The blue spherical cap along the a* axis corresponds to HKLs for which > > no measurement is available: it is clearly created by the detector > > being too far from the crystal. > > > > The second (central) graphical object, of which a view is given > > in Figure 1 of Bernhard's article and another in the attached picture > > "Local_I_over_sigI.png") shows vividly the blue cap of measurements > > that were missed but would probably have been significant (had they > > been measured) cutting into the green region, where the local average > > of I/sig(I) ranges between 16 and 29! If the detector had been placed > > closer, significant data extending to perhaps 3.0A resolution would > > arguably have been measured from this sample. > > > > The right-most graphical object (of which a static view is > > attached as "Debye-Waller.png") depicts the distribution of the > > anisotropic Debye-Waller factor (an anisotropic generalisation of the > > Wilson B) of the dataset, giving yet another visual hint that good > > data were truncated by the edges of a detector placed too far. > > > > Apologies for such a long "STARANISO 101" tutorial but Bernhard's > > invitation to lift our eyes from the terse numbers in Table 1 towards > > 3D illustrations of data quality criteria was irresistible ;-) . His > > viewpoint also agrees with one of the main purposes of our STARANISO > > developments (beyond the analysis and remediation of anisotropy, about > > which one can - and probably will - argue endlessly) namely contribute > > to facilitating a more direct and vivid perception by users of the > > quality of their data (or lack of it) and to nurturing evidence-based > > motivation to make whatever extra effort it takes to improve that > > quality. In this case, the undeniable evidence of non-uniformity of > > redundancy and of a detector placed too far would give immediate > > practical guidance towards doing a better experiment, while statistics > > in Table 1 for the same dataset would probably not ... . > > > > Thank you Bernhard! > > > > > > With best wishes, > > > > Gerard, > > for and on behalf of the STARANISO developers > > > > > > ----- End forwarded message ----- > > > > _______________________________________________ > > phenixbb mailing list > > phenixbb(a)phenix-online.org > > http://phenix-online.org/mailman/listinfo/phenixbb > > Unsubscribe: phenixbb-leave(a)phenix-online.org > > > > > > -- > Professor John R Helliwell DSc

7 years

Re: [phenixbb] Discrepancy between Phenix GUI and command line for MR

by Xavier Brazzolotto

Hi Randy Many thanks for your feedback and explanations. I’ll check the nightly or wait until the next stable. I’ve seen an RC1 recently, meaning the next stable should come soon. Best, Xavier > Le 4 juil. 2023 à 17:37, Randy John Read <rjr27(a)cam.ac.uk> a écrit : > > Hi, > > Thanks for sending the log files! > > The jobs turn out not actually to be identical. The GUI automatically chose to use the intensity data (which is what we prefer for use in Phaser) whereas your job run from a script is using amplitude data. The issue I alluded to earlier occurs only for intensity data, because the analysis of those data involves applying different equations, which use a special function (tgamma from the Boost library). For some reason I don’t understand, when the Intel version of the tgamma algorithm is computed using the Rosetta functionality to run it on an ARM processor, it’s much much slower than other calculations. > > Just last week (right after I finally got an M2 MacBook Pro), we tracked this down and replaced the calls to Boost tgamma with alternative code, and that problem should exist any more. You can use it already in Phenix by getting a recent nightly build, and I’ve asked the CCP4 people to compile a new version of Phaser and release it as an update to CCP4 as well. > > Best wishes, > > Randy > >> On 4 Jul 2023, at 12:05, Xavier Brazzolotto <xbrazzolotto(a)gmail.com <mailto:[email protected]>> wrote: >> >> For information >> >> Apple M2 running Ventura 13.4.1 with 64 Go memory >> Phenix 1.20.1-4487 (Intel one). >> >> I’ve run MR of the same dataset (2.15A - I422) with the same model both with the command line and through the GUI. >> >> Command line (phenix.phaser) : 48 secs. >> GUI (Phaser-MR simple one component interface): 18 mins ! >> >> In copy the two log files if this helps >> >> >> >>> Le 4 juil. 2023 à 12:54, Luca Jovine <luca.jovine(a)ki.se <mailto:[email protected]>> a écrit : >>> >>> Hi Xavier and Randy, I'm also experiencing the same on a M2 Mac! >>> -Luca >>> >>> -----Original Message----- >>> From: <phenixbb-bounces(a)phenix-online.org <mailto:[email protected]> <mailto:[email protected]>> on behalf of Xavier Brazzolotto <xbrazzolotto(a)gmail.com <mailto:[email protected]> <mailto:[email protected]>> >>> Date: Tuesday, 4 July 2023 at 12:38 >>> To: Randy John Read <rjr27(a)cam.ac.uk <mailto:[email protected]> <mailto:[email protected]>> >>> Cc: PHENIX user mailing list <phenixbb(a)phenix-online.org <mailto:[email protected]> <mailto:[email protected]>> >>> Subject: Re: [phenixbb] Discrepancy between Phenix GUI and command line for MR >>> >>> >>> Hi Randy, >>> >>> >>> Indeed I’m running Phenix on a brand new M2 Mac. >>> I will benchmark the two processes (GUI vs command line) and post them here. >>> >>> >>>> Le 4 juil. 2023 à 12:32, Randy John Read <rjr27(a)cam.ac.uk <mailto:[email protected]> <mailto:[email protected]>> a écrit : >>>> >>>> Hi Xavier, >>>> >>>> We haven’t noticed that, or at least any effect is small enough not to stand out. There shouldn’t be a lot of overhead in communicating with the GUI (i.e. updating the terse log output and the graphs) but if there is we should look into it and see if we can do something about it. >>>> >>>> Could you tell me how much longer (say, in percentage terms) a job takes when you run it through the GUI compared to running the same job outside the GUI on the same computer? Also, it’s possible the architecture matters so could you say which type of computer and operating system you’re using? If it’s a Mac, is it one with an Intel processor or an ARM (M1 or M2) processor? (By the way, we finally managed to track down and fix an issue that cause Phaser to run really slowly on an M1 or M2 Mac when using the version compiled for Intel, once I got my hands on a new Mac.) >>>> >>>> Best wishes, >>>> >>>> Randy >>>> >>>>> On 4 Jul 2023, at 10:44, Xavier Brazzolotto <xbrazzolotto(a)gmail.com <mailto:[email protected]> <mailto:[email protected]>> wrote: >>>>> >>>>> Dear Phenix users >>>>> >>>>> I’ve noticed that molecular replacement was clearly slower while running from the GUI compared to using the command line (phenix.phaser). >>>>> >>>>> Did you also observe such behavior? >>>>> >>>>> Best >>>>> Xavier >>>>> _______________________________________________ >>>>> phenixbb mailing list >>>>> phenixbb(a)phenix-online.org <mailto:[email protected]> <mailto:[email protected]> >>>>> http://phenix-online.org/mailman/listinfo/phenixbb <http://phenix-online.org/mailman/listinfo/phenixbb> >>>>> Unsubscribe: phenixbb-leave(a)phenix-online.org <mailto:[email protected]> <mailto:[email protected]> >>>> >>>> >>>> ----- >>>> Randy J. Read >>>> Department of Haematology, University of Cambridge >>>> Cambridge Institute for Medical Research Tel: +44 1223 336500 >>>> The Keith Peters Building >>>> Hills Road E-mail: rjr27(a)cam.ac.uk <mailto:[email protected]> <mailto:[email protected]> >>>> Cambridge CB2 0XY, U.K. www-structmed.cimr.cam.ac.uk <http://www-structmed.cimr.cam.ac.uk/> >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> phenixbb mailing list >>> phenixbb(a)phenix-online.org <mailto:[email protected]> <mailto:[email protected]> >>> http://phenix-online.org/mailman/listinfo/phenixbb <http://phenix-online.org/mailman/listinfo/phenixbb> >>> Unsubscribe: phenixbb-leave(a)phenix-online.org <mailto:[email protected]> <mailto:[email protected]> >>> >>> >>> >>> När du skickar e-post till Karolinska Institutet (KI) innebär detta att KI kommer att behandla dina personuppgifter. Här finns information om hur KI behandlar personuppgifter<https://ki.se/medarbetare/integritetsskyddspolicy>. >>> >>> >>> Sending email to Karolinska Institutet (KI) will result in KI processing your personal data. You can read more about KI’s processing of personal data here<https://ki.se/en/staff/data-protection-policy>. >> >> <command_line_PHASER.log><GUI_phaser.log> > > ----- > Randy J. Read > Department of Haematology, University of Cambridge > Cambridge Institute for Medical Research Tel: +44 1223 336500 > The Keith Peters Building > Hills Road E-mail: rjr27(a)cam.ac.uk <mailto:[email protected]> > Cambridge CB2 0XY, U.K. www-structmed.cimr.cam.ac.uk <http://www-structmed.cimr.cam.ac.uk/>

1 year, 11 months

Re: [phenixbb] Validation of structure with modified residue

by Nigel Moriarty

Xavier I'm happy to take a closer look. Send me the two entities (SER and ligand) along with the restraints and I will try to help. Cheers Nigel --- Nigel W. Moriarty Building 33R0349, Molecular Biophysics and Integrated Bioimaging Lawrence Berkeley National Laboratory Berkeley, CA 94720-8235 Phone : 510-486-5709 Email : NWMoriarty(a)LBL.gov Fax : 510-486-5909 Web : CCI.LBL.gov ORCID : orcid.org/0000-0001-8857-9464 On Thu, Apr 21, 2022 at 8:32 AM Xavier Brazzolotto <xbrazzolotto(a)gmail.com> wrote: > I recall now how I used to add the glycans before the Carbohydrate Module > in Coot. > I have to make the cif file with the putative O atom of SER OG and remove > it before making the bond. > I will try that, it will certainly correct my geometry issue but I am > still not sure for the final file and validation. > > Fingers crossed... > > Le 21 avr. 2022 à 17:09, Xavier Brazzolotto <xbrazzolotto(a)gmail.com> a > écrit : > > After some careful inspection. > The geometry on the C atom of the ligand is weird, I don’t get something > close to tetrahedral (or similar). > Probably some angles are missing or I did something wrong with the ligand > cif file. > Not fixed yet > > Le 21 avr. 2022 à 13:39, Xavier Brazzolotto <xbrazzolotto(a)gmail.com> a > écrit : > > I’ve re-processed the structure separating the SER residue from the ligand > part. Now I have independent ligand. > In the « Custom Geometry Restraints » I’ve defined the bond between OG > and the carbon atom of the ligand and I’ve defined the angles (I’ve used > the values from the previously determined eLBOW run off the SER-bound > ligand complex), saved the restraints and launched the refinement. At a > first look it was processed correctly and the final cif file has now the > whole protein in Chain A. > > I’ve used prepare PDB deposition using the FASTA sequence of the protein > (wonder if I have to provide the ligand CIF file and add more options) and > ran phenix.get_pdb_validation : the report looks ok for protein and some > other basic ligands (sugars, buffer, glycerol, etc...) but the ligand of > interest was not processed (EDS FAILED...). In the PDB file, all these > extra ligands are also in Chain A, with water in chain B. > > If I try the validation through the website (PDBe@EBI) with both cif > files from the Refine or the Prepare_PDB_Deposition process, both seem to > crash the server as it takes forever without Finalizing... > > I wonder if I am missing something… Maybe declaration of removal of atoms > : HG bound to OG in SER or/and removal of one H from the carbon of the > ligand involved in the bond ? > > Xavier > > Le 21 avr. 2022 à 08:06, Xavier Brazzolotto <xbrazzolotto(a)gmail.com> a > écrit : > > Thank you for your feedback. > > @Paul, I’ve run the « Prepare model for deposition » with the option > modified residue (SLG). Not sure it will change if I change the name as it > is already the PDB database, but I will give it another try. > > I think that I will have to describe only the ligand and add some > parameters restricting distance and angles between the OG of SER and the > ligand, I think this is right way. > @ Nigel, is that what you mean with « details » ? If you have any other « > tips/tricks » they are welcome. > > Best > Xavier > > Le 21 avr. 2022 à 02:47, Nigel Moriarty <nwmoriarty(a)lbl.gov> a écrit : > > Xavier > > Paul's point is very valid because the "Prepare for Deposition" step is > what generates the sequence (which is the crucial point here) for > deposition. However, because you have "created" a new amino acid, there > will still be issues as highlighted by Pavel. It is a corner case. > > One small addition point is that SLG is already taken in the PDB Ligand > list. There are tools in Phenix to find an used code. > > Can you re-engineer it with SER+ligand? This will solve the problem using > the current Phenix version. I can help with the details if needed. > > Cheers > > Nigel > > --- > Nigel W. Moriarty > Building 33R0349, Molecular Biophysics and Integrated Bioimaging > Lawrence Berkeley National Laboratory > Berkeley, CA 94720-8235 > Phone : 510-486-5709 Email : NWMoriarty(a)LBL.gov <NWMoriarty(a)LBL.gov> > Fax : 510-486-5909 Web : CCI.LBL.gov <http://cci.lbl.gov/> > ORCID : orcid.org/0000-0001-8857-9464 > > > On Wed, Apr 20, 2022 at 5:02 PM Paul Adams <pdadams(a)lbl.gov> wrote: > >> >> Please also remember that you need to run “Prepare model for PDB >> deposition” (in the GUI under "PDB Deposition") on the mmCIF file you get >> from phenix.refine. This provides important information that is required >> for the deposition at the PDB. >> >> On Apr 20, 2022, at 1:58 PM, Xavier Brazzolotto <xbrazzolotto(a)gmail.com> >> wrote: >> >> Dear Phenix users, >> >> I don’t know if my problem is related to Phenix but for information I’m >> running Phenix 1.20.1-4487 under MacOS 12.3.1. >> >> I’ve finalized a structure where a ligand covalently modified the protein. >> >> I’ve generated the modified residue (named SLG for serine modified by >> ligand). For this I’ve generated the molecules in SMILES and used eLBOW to >> generate the restraints. Then I’ve modified the cif file defining the >> molecule as a L-peptide and replacing the atom names of the Serine part >> (CA, CB, OG, C, O, N, and OXT) >> In coot (from CCP4 : 0.9.6 EL), I’ve used the modified cif file and it >> allowed merging of the modified residue into the polypeptide chain as >> expected and further refinements went without any issue in Phenix >> (providing the modified cif file of course). Everything seems well >> interpreted. So far so good. >> >> However, now I would like to validate the structure and both Phenix >> validation tool and the PDB web server do not accept the final cif file. >> >> Checking this file I’ve noticed that the protein seems split into 3 >> pieces (chain A, first residue up to the one before the modified residue; >> chain B the modified residue by itself described as HETATM and chain C the >> rest of the polypeptide up to the C-ter). >> The PDB file presents only one chain A for the whole protein with the >> modified residue... >> >> I don’t know if this is an issue with Phenix generating this final cif >> file in this specific case or if I need to modify this final file by hand ? >> >> Any help is welcome. >> Thanks >> >> Xavier >> >> >> >> _______________________________________________ >> phenixbb mailing list >> phenixbb(a)phenix-online.org >> http://phenix-online.org/mailman/listinfo/phenixbb >> Unsubscribe: phenixbb-leave(a)phenix-online.org >> >> >> -- >> Paul Adams (he/him/his) >> Associate Laboratory Director for Biosciences, LBL ( >> https://biosciences.lbl.gov/leadership/) >> Principal Investigator, Computational Crystallography Initiative, LBL ( >> https://cci.lbl.gov) >> Vice President for Technology, the Joint BioEnergy Institute ( >> http://www.jbei.org) >> Principal Investigator, ALS-ENABLE, Advanced Light Source ( >> https://als-enable.lbl.gov) >> Division Deputy for Biosciences, Advanced Light Source ( >> https://als.lbl.gov) >> Laboratory Research Manager, ENIGMA Science Focus Area ( >> http://enigma.lbl.gov) >> Adjunct Professor, Department of Bioengineering, UC Berkeley ( >> http://bioeng.berkeley.edu) >> Member of the Graduate Group in Comparative Biochemistry, UC Berkeley ( >> http://compbiochem.berkeley.edu) >> >> Building 33, Room 250 >> Building 978, Room 4126 >> Building 977, Room 268 >> Tel: 1-510-486-4225 >> http://cci.lbl.gov/paul >> ORCID: 0000-0001-9333-8219 >> >> Lawrence Berkeley Laboratory >> 1 Cyclotron Road >> BLDG 33R0345 >> Berkeley, CA 94720, USA. >> >> Executive Assistant: Michael Espinosa [ MEEspinosa(a)lbl.gov ] [ >> 1-510-333-6788 ] >> Phenix Consortium: Ashley Dawn [ AshleyDawn(a)lbl.gov ][ 1-510-486-5455 ] >> >> -- >> >> _______________________________________________ >> phenixbb mailing list >> phenixbb(a)phenix-online.org >> http://phenix-online.org/mailman/listinfo/phenixbb >> Unsubscribe: phenixbb-leave(a)phenix-online.org > > > > > _______________________________________________ > phenixbb mailing list > phenixbb(a)phenix-online.org > http://phenix-online.org/mailman/listinfo/phenixbb > Unsubscribe: phenixbb-leave(a)phenix-online.org > > >

3 years, 2 months

Re: [phenixbb] Autosol: MIRAS

by Gabor Bunkoczi

Dear AK, if you just need the Se positions, you can run Phaser MR-SAD (available from the GUI) using your partial model as a starting point, together with the Se-Met data. Dependending on the model quality (and the model does not have to be very good), it may be able to locate the Se-sites. BW, Gabor On Sep 6 2012, ash.k(a)aol.com wrote: > Satisfactory map means: I am expecting a coiled coil or helix bundle type > of assembly and I could see some densities appropriate for helices. There > are proper solvent channels and continuous stretches of densities. > > More to add about data on this: the data is anisotropic and the longer > 'c' axis and alignment of helical density along c axis support this. This > also makes me think that perhaps map is sensible. > > Few rounds of model building, refinement and DM has been successful to > assign around 10 polyala helices and their distribution looks sensible > from packing point of view. Now the problem is to assign the side chain. > I was hoping to make use of Se locations for this. R and Rfree are still > random, in the range of 50%. I am not sure, but it could be perhaps > because most of the scattering material is still unassigned. > > > > > > >-----Original Message----- >From: Francis E Reyes <Francis.Reyes(a)colorado.edu> >To: PHENIX user mailing list <phenixbb(a)phenix-online.org> >Cc: phenixbb <phenixbb(a)phenix-online.org> >Sent: Thu, Sep 6, 2012 8:07 am >Subject: Re: [phenixbb] Autosol: MIRAS > > > This one is solvable, but with extreme difficulty. I recently completed a > structure solution with experimental phases starting at 5.0 A using phase > information from multiple derivatives. > > >How would you describe a somewhat satisfactory map? > > >F > >On Sep 5, 2012, at 7:08 PM, ash.k(a)aol.com wrote: > > > > > > > >Hi Shya, > > I did wavelength scan, got a good signal for Se and used appropriate > wavelengths for data collection and also used experimental f' and f'' > values for phasing. I think the reasons SAD or MAD for SeMet data is not > working are (i) low resolution: 3.7 for SeMet (Anomalous data is up to > 4.8A) (ii) I should have mentioned this earlier: 3 out of 6 Se are very > close to N-terminus, possible they are disordered. Unit cell is also some > what big..100, 120 and 320A; F222 space group. > >AK > > > >-----Original Message----- >From: Shya Biswas <shyabiswas(a)gmail.com> >To: PHENIX user mailing list <phenixbb(a)phenix-online.org> >Sent: Thu, Sep 6, 2012 7:29 am >Subject: Re: [phenixbb] Autosol: MIRAS > > >Hi AK, >Did you do a wavelength scan when you collected the SE dataset you >need to put the values of f' and f'' from your wavelength scan in >order to locate the heavy atom sites, 6 methionine should be enough to >phase your molecule. >Shya > >On Wed, Sep 5, 2012 at 9:25 PM, <ash.k(a)aol.com> wrote: >> Hi all, >> >> I am trying to solve a structure through experimental phasing using >> AUTOSOL. I have a couple of heavy atom derivative datasets (Hg, La, Eu, >> Cd) and also a SeMet data. Unfortunately all the datasets are of low >> resolution (3.7-4.2A) and there are possibly 4-8 molecules in the asu. >> MIR, SAD and MAD alone did not give any convincing solution. >> >> However, MIRAS, with a combination of few heavy atom datasets and the >> anomalous data from SeMet crystals, gave a somewhat satisfactory map. >> But the heavy atom site picked by AUTOSOL list only one of the heavy >> atoms i.e. Lanthanum. In another set of run, the solution of which was >> not convincing, the heavy atom substructure had only Hg. There are 6 Met >> out of 200 residues in one molecule and mass spec results show that Se >> incorporation is 100%. >> >> Now, my doubt is that why does the heavy atom substructure contain only >> La and how can I get the substructure involving Se from this solution >> (or the datasets used)? Se location is going to help me a lot for >> finding a starting point to assign side chains. >> >> Any suggestion would be greatly appreciated. >> >> Thanks >> AK >> >> _______________________________________________ >> 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 > > > > >_______________________________________________ >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 > > > -- ################################################## Dr Gabor Bunkoczi Cambridge Institute for Medical Research Wellcome Trust/MRC Building Addenbrooke's Hospital Hills Road Cambridge CB2 0XY ##################################################

12 years, 9 months

[phenixbb] Call for targets for CASP12 - Critical Assessment of Protein Structure Prediction

by Torsten Schwede

Dear colleagues, The CASP experiment is looking for prediction targets: Novel folds, membrane proteins, protein complexes and multimers, comparative modeling targets. As many of you know, the CASP community experiments have been running once every two years since 1994, collecting information on soon to be solved structures from the experimental community, and passing on sequence data to the structure modeling community so that blind predictions of structure can be collected and assessed. Over that period CASP has seen enormous progress in the quality of modeled structures, but many problems remain, and further testing of prediction methods is imperative for advancing the field. CASP organizers collect target information for a three month season every two years, and in that period we can acquire around 100 targets, sufficient to evaluate the state of the art for most types of modeling. For those of you who have not provided targets to CASP before, the procedure is simple - there is a web page for submitting targets, and a very experienced staff to deal with any queries. We don't need the structure in advance of its release by the PDB, and if we are notified early enough (a minimum of three weeks before release, more is better) there need be no delay in structure release. We need all sorts of targets and in general everything that has low coverage by the templates (<70% of the sequence length) and relatively low sequence identity to the best template (<50% ) will be appreciated. In particular, we are interested in: 1. Novel folds and membrane protein targets. Last round we observed some interesting methods developments for contact prediction and ab initio modeling, and it is important to be able to decisively evaluate their effectiveness this CASP again. 2. Protein complexes and multimers. Since the last edition of CASP, the assessment of structure prediction methods has stronger emphasis on evaluating the accuracy of quaternary structure prediction. Both oligomeric targets and complexes are of interest for the experiment. 3. A diversity of comparative modeling targets. Cases where there is fairly high sequence identity (30-50%) between the target structure and an available template are valuable for testing the degree to which model accuracy can approach that of experiment, particularly in functionally critical regions. Cases with lower sequence identity to template, right down to undetectable, are valuable for testing the ability of the methods to detect remote homologs, to overcome challenging alignment difficulties, to make use of multiple templates, and to build regions of the structure not obviously available from a template. The time table is similar to previous CASPs: The prediction season opens at the beginning of May, and will run until the end of July. We are releasing targets continuously throughout that period, as evenly spaced as possible, aiming for about 100 targets altogether. Each target will be available for prediction for a period of three weeks. For cases where longer periods are possible, these targets may be used to test refinement and data-assisted methods. It is of course important that there not be any kind of public release of the experimental structure (including things like pictures on web pages or abstracts) until after the predictions for that target are closed. As many of you know, it's fairly simple, with just two things to bear in mind. First, because of the timing framework, there needs to be at least a month between the submission date and any release of the structure. Second, we ideally need the experimental co-ordinates by the beginning of August and definitely by the end of August, so that the predictions can be assessed. At that point, they can be kept confidential if necessary, though we would like to provide them to predictors of your structure at the beginning of November at the latest, so that can see how well they have done. Participants would also usually like to be able to show slides and discuss their predictions at the meeting at the beginning of December. So, if you are currently working on an interesting protein structure suitable as prediction target for CASP , we would be most grateful if you would inform us via the target entry page: http://www.predictioncenter.org/casp12/targets_submission.cgi After CASP prediction season is over we usually publish a paper on the experimentalists' insights into the most interesting targets (see below). 2015: Some of the most interesting CASP11 targets through the eyes of their authors. Kryshtafovych A, Moult J, Baslé A, Burgin A, Craig TK, Edwards RA, Fass D, Hartmann MD, Korycinski M, Lewis RJ, Lorimer D, Lupas AN, Newman J, Peat TS, Piepenbrink KH, Prahlad J, van Raaij MJ, Rohwer F, Segall AM, Seguritan V, Sundberg EJ, Singh AK, Wilson MA, Schwede T. Proteins. 2015 Oct 16. doi: 10.1002/prot.24942. [Epub ahead of print]. PMID: 26473983. 2014: Challenging the state of the art in protein structure prediction: Highlights of experimental target structures for the 10th Critical Assessment of Techniques for Protein Structure Prediction Experiment CASP10. Kryshtafovych A, Moult J, Bales P, Bazan JF, Biasini M, Burgin A, Chen C, Cochran FV, Craig TK, Das R, Fass D, Garcia-Doval C, Herzberg O, Lorimer D, Luecke H, Ma X, Nelson DC, van Raaij MJ, Rohwer F, Segall A, Seguritan V, Zeth K, Schwede T. Proteins. 2014 Feb;82 Suppl 2:26-42. doi: 10.1002/prot.24489. Erratum in: Proteins. 2015 Jun;83(6):1198. PMID: 24318984. 2011: Target highlights in CASP9: Experimental target structures for the critical assessment of techniques for protein structure prediction. Kryshtafovych A, Moult J, Bartual SG, Bazan JF, Berman H, Casteel DE, Christodoulou E, Everett JK, Hausmann J, Heidebrecht T, Hills T, Hui R, Hunt JF, Seetharaman J, Joachimiak A, Kennedy MA, Kim C, Lingel A, Michalska K, Montelione GT, Otero JM, Perrakis A, Pizarro JC, van Raaij MJ, Ramelot TA, Rousseau F, Tong L, Wernimont AK, Young J, Schwede T. Proteins. 2011;79 Suppl 10:6-20. doi: 10.1002/prot.23196. Epub 2011 Oct 21. PMID: 22020785. Thanks, CASP organizing committee: John Moult, University of Maryland, USA Krzysztof Fidelis, University of California, Davis, USA Andriy Kryshtafovych, University of California, Davis, USA Torsten Schwede, University of Basel, Switzerland Anna Tramontano, University of Rome, Italy Get in touch: casp(a)predictioncenter.org<mailto:[email protected]> More information: http://www.predictioncenter.org/casp12/index.cgi Submit a target: http://www.predictioncenter.org/casp12/targets_submission.cgi

9 years, 2 months

Re: [phenixbb] Phaser output and error messages

by Randy Read

Hi, I think a number of these questions could be answered by looking carefully through the whole logfile and seeing what it tells you about what is happening in each step of the calculation. As well, the primary literature should be considered to be part of what documents a program. 1. Phaser uses likelihood to solve structures by molecular replacement, so the best solution is the one with the highest log- likelihood-gain (LLG). One of the ways we talk about this is to consider molecular replacement as testing a series of hypotheses about how the molecule is oriented and how it is positioned, and likelihood measures how consistent the data are with each of these hypotheses. The one with the highest LLG is the one that is supported most strongly by the data. On the point of "tuning" parameters, I'm not sure what you mean. In a particular case, you should know what you put into your crystallization drop, and you will usually have some expectation about the stoichiometry of any complexes, so you usually have a good idea of the possible content of the asymmetric unit and the sequence identity of the models (thus giving you a rough idea of the expected RMS error). You may have to test different choices for the number of copies, if different numbers are consistent with the range of solvent contents observed in crystals, but you can do better than a generic assumption of, say, 50% solvent. The sequence identity <-> RMS error relationship is only approximate, but once the structure is solved then refinement programs like phenix.refine will do a better job of estimating the impact of errors in the coordinates. However, if you only see negative LLG values in a search, then (as the documentation says) you should revise the estimated RMS error upwards, because the model is clearly worse than you would expect from the sequence identity. 2. Given that the potential solutions in the .sol file are sorted by LLG, I'm not sure where the idea would come from that they could be given in the order they were found. You can follow the solutions in the logfile and see this. The whole computation has to finish before it is known which is the best solution. We have heuristics to stop Phaser spending too much time looking down blind alleys and, as we improve our understanding of how to recognize a correct solution from noise, we will improve these heuristics. So we're already doing as well as we know how to stop when the solution is found. The ten-minute timeout is not a good idea. A Phaser molecular replacement run comes after weeks to years of protein expression, crystallization and data collection, and before days to months of rebuilding, refinement and interpretation, so if it takes 30 minutes, two hours or even a day to find a solution, then it doesn't seem too long to wait. 3. To help people, in cases where (say) the computer crashes in the middle of a long run, we've made Phaser write out intermediate .sol, .pdb and .mtz files, so that (in principle) you could pick up from the middle, or you could examine an intermediate solution, say with 2 of 3 components placed. If you stop it in the middle, then you will get files from, say, after the translation search but before the packing check, or after the packing check but before the rigid-body refinement. The results won't be as good, and you may well miss something better that would have been found later. 4. If Phaser reports that there is no scattering in a model, it means that you have supplied an empty PDB file, or one where all the occupancies are equal to zero, or one containing only HETATM records and no ATOM records. If this happens in other circumstances, then it would be a bug and we would appreciate seeing the offending PDB file. I hope that helps. Regards, Randy Read On 15 Nov 2009, at 13:13, Ian Stokes-Rees wrote: > I'm having some discussion with a colleague about phaser output (we're > using Phaser 2.1.4). We haven't been able to find any documentation > which can clarify our situation, and I'm hoping someone on the list > can > help answer these questions. I should mention that I am relatively > new > to Phaser. > > > > 1. PHASER.sol files: Which "SOLU SET" does Phaser consider to be the > best? The first or the last? Or the one with the highest LLG, > wherever > that may be? In our experience of running Phaser over several MTZ > files > with a range of models the best Phaser solution has always been the > first, and this has had the highest LLG. > > Note: this is with "untuned" Phaser settings for identity, solvent > fraction, or number of search models in ASU -- our goal is to do a > first > run with "generic" settings for these over a larger set of models, > then > (from TFZ and LLG scores) select a subset for which we will tune > Phaser > parameters and PDB search model variations. > > > > 2. If we are right that the first "SOLU SET" entry is indicative of > the > potential for the search model to form a good MR candidate, then is it > the case that the first entry is the first Phaser solution that is > computed? Or is the PHASER.sol file a sorted list output at the end > of > the run? From my reading of the documentation it is output in order > of > computation, and *for our purposes* (if my first statement in this > question is correct) Phaser can stop after it outputs this first > solution. Is there some way to tell Phaser to stop after the first > solution is output? > > I realize that this doesn't sound like it makes sense (how could > Phaser > know to pick the best solution first, and even if it could, why > would it > ever continue past this point), however I ask because we have put a 10 > minute timeout into our Phaser runs and we have many situations > where we > get a timeout but PHASER.sol has already been generated and the best > LLG > solutions are output first. It leaves me wondering why it didn't just > stop on its own after outputting the first result instead of being > aborted by our (external) timeout that terminates the process? > > > > 3. PHASER.sol files: For single domain search models, we usually get > output of the form: > > SOLU SET RFZ=4.5 TFZ=5.2 PAK=0 LLG=14 LLG=14 > SOLU 6DIM ENSE model1 EULER 242.049 45.040 326.088 FRAC -0.09425 > 0.50268 0.42575 > > however we see three variations: > > i) No LLG: > > SOLU SET RFZ=3.1 TFZ=5.0 PAK=0 > SOLU 6DIM ENSE model2 EULER 59.983 69.335 319.701 FRAC -1.17131 > -0.70030 0.23150 > > ii) One LLG: > > SOLU SET RFZ=3.7 TFZ=4.6 PAK=0 LLG=25 > SOLU 6DIM ENSE model3 EULER 293.943 128.068 332.147 FRAC 0.06273 > 0.13175 0.25054 > > iii) Two LLG entries, but with different values: > > SOLU SET RFZ=3.8 TFZ=4.1 PAK=0 LLG=21 LLG=20 > SOLU 6DIM ENSE model4 EULER 278.058 129.347 33.292 FRAC 0.28446 > 0.29011 -0.07986 > > > > 4. Occasionally we get an error that we don't understand: > > FATAL RUNTIME ERROR: No scattering in pdbfile model1.pdb > > What does this mean? Is there a problem with the PDB file? We can't > see anything obvious in the ones which produce this error. > > Thanks, > > Ian > > -- > Ian Stokes-Rees, Research Associate > SBGrid, Harvard Medical School > http://sbgrid.org > > _______________________________________________ > phenixbb mailing list > phenixbb(a)phenix-online.org > http://www.phenix-online.org/mailman/listinfo/phenixbb ------ Randy J. Read Department of Haematology, University of Cambridge Cambridge Institute for Medical Research Tel: + 44 1223 336500 Wellcome Trust/MRC Building Fax: + 44 1223 336827 Hills Road E-mail: rjr27(a)cam.ac.uk Cambridge CB2 0XY, U.K. www- structmed.cimr.cam.ac.uk

15 years, 7 months

Re: [phenixbb] Geometry Restraints - Anisotropic truncation

by Pavel Afonine

Hi Kendall, I just did this quick test: calculated R-factors using original and anisotropy-corrected Mike Sawaya's data (*) Original: r_work : 0.3026 r_free : 0.3591 number of reflections: 26944 Truncated: r_work : 0.2640 r_free : 0.3178 number of reflections: 18176 The difference in R-factors is not too surprising given how many reflections was removed (about 33%). Pavel (*) Note, the data available in PDB is anisotropy corrected. The original data set was kindly provided to me by the author. On 5/2/12 5:25 AM, Kendall Nettles wrote: > I didnt think the structure was publishable with Rfree of 33% because I was expecting the reviewers to complain. > > We have tested a number of data sets on the UCLA server and it usually doesn't make much difference. I wouldn't expect truncation alone to change Rfree by 5%, and it usually doesn't. The two times I have seen dramatic impacts on the maps ( and Rfree ), the highly anisotrophic sets showed strong waves of difference density as well, which was fixed by throwing out the noise. We have moved to using loose data cutoffs for most structures, but I do think anisotropic truncation can be helpful in rare cases. > > Kendall > > On May 1, 2012, at 3:07 PM, "Dale Tronrud"<det102(a)uoxray.uoregon.edu> wrote: > >> While philosophically I see no difference between a spherical resolution >> cutoff and an elliptical one, a drop in the free R can't be the justification >> for the switch. A model cannot be made more "publishable" simply by discarding >> data. >> >> We have a whole bunch of empirical guides for judging the quality of this >> and that in our field. We determine the resolution limit of a data set (and >> imposing a "limit" is another empirical choice made) based on Rmrg, or Rmes, >> or Rpim getting too big or I/sigI getting too small and there is no agreement >> on how "too big/small" is too "too big/small". >> >> We then have other empirical guides for judging the quality of the models >> we produce (e.g. Rwork, Rfree, rmsds of various sorts). Most people seem to >> recognize that the these criteria need to be applied differently for different >> resolutions. A lower resolution model is allowed a higher Rfree, for example. >> >> Isn't is also true that a model refined to data with a cutoff of I/sigI of >> 1 would be expected to have a free R higher than a model refined to data with >> a cutoff of 2? Surely we cannot say that the decrease in free R that results >> from changing the cutoff criteria from 1 to 2 reflects an improved model. It >> is the same model after all. >> >> Sometimes this shifting application of empirical criteria enhances the >> adoption of new technology. Certainly the TLS parametrization of atomic >> motion has been widely accepted because it results in lower working and free >> Rs. I've seen it knock 3 to 5 percent off, and while that certainly means >> that the model fits the data better, I'm not sure that the quality of the >> hydrogen bond distances, van der Waals distances, or maps are any better. >> The latter details are what I really look for in a model. >> >> On the other hand, there has been good evidence through the years that >> there is useful information in the data beyond an I/sigI of 2 or an >> Rmeas> 100% but getting people to use this data has been a hard slog. The >> reason for this reluctance is that the R values of the resulting models >> are higher. Of course they are higher! That does not mean the models >> are of poorer quality, only that data with lower signal/noise has been >> used that was discarded in the models you used to develop your "gut feeling" >> for the meaning of R. >> >> When you change your criteria for selecting data you have to discard >> your old notions about the acceptable values of empirical quality measures. >> You either have to normalize your measure, as Phil Jeffrey recommends, by >> ensuring that you calculate your R's with the same reflections, or by >> making objective measures of map quality. >> >> Dale Tronrud >> >> P.S. It is entirely possible that refining a model to a very optimistic >> resolution cutoff and calculating the map to a lower resolution might be >> better than throwing out the data altogether. >> >> On 5/1/2012 10:34 AM, Kendall Nettles wrote: >>> I have seen dramatic improvements in maps and behavior during refinement following use of the UCLA anisotropy server in two different cases. For one of them the Rfree went from 33% to 28%. I don't think it would have been publishable otherwise. >>> Kendall >>> >>> On May 1, 2012, at 11:10 AM, Bryan Lepore wrote: >>> >>>> On Mon, Apr 30, 2012 at 4:22 AM, Phil Evans<pre(a)mrc-lmb.cam.ac.uk> wrote: >>>>> Are anisotropic cutoff desirable? >>>> is there a peer-reviewed publication - perhaps from Acta >>>> Crystallographica - which describes precisely why scaling or >>>> refinement programs are inadequate to ameliorate the problem of >>>> anisotropy, and argues why the method applied in Strong, et. al. 2006 >>>> satisfies this need? >>>> >>>> -Bryan

13 years, 2 months

Re: [cctbxbb] some thoughts on cctbx and pip

by Luc Bourhis

It should be noted that conda solves the problem of setting environment variables such as LIBTBX_BUILD, by putting a script to source in CONDA_PREFIX/etc/conda/activate.d (and deactivate.d). So again, that makes conda the better choice. > On 23 Aug 2019, at 02:21, Luc Bourhis <luc_j_bourhis(a)mac.com> wrote: > > Hi, > > Even if we managed to ship our the boost dynamic libraries with pip, it would still not be pip-like, as we would still need our python wrappers to set LIBTBX_BUILD and LD_LIBRARY_PATH. Normal pip packages work with the standard python exe. LD_LIBRARY_PATH, we could get around that by changing the way we compile, using -Wl,-R, which is the runtime equivalent of build time -L. That’s a significant change that would need to be tested. But there is no way around setting LIBTBX_BUILD right now. Leaving that to the user is horrible. Perhaps there is a way to hack libtbx/env_config.py so that we can hardwire LIBTBX_BUILD in there when pip installs? > > Best wishes, > > Luc > > >> On 16 Aug 2019, at 22:47, Luc Bourhis <luc_j_bourhis(a)mac.com <mailto:[email protected]>> wrote: >> >> Hi, >> >> I did look into that many years ago, and even toyed with building a pip installer. What stopped me is the exact conclusion you reached too: the user would not have the pip experience he expects. You are right that it is a lot of effort but is it worth it? Considering that remark, I don’t think so. Now, Conda was created specifically to go beyond pip pure-python-only support. Since cctbx has garnered support for Conda, the best avenue imho is to go the extra length to have a package on Anaconda.org <http://anaconda.org/>, and then to advertise it hard to every potential user out there. >> >> Best wishes, >> >> Luc >> >> >>> On 16 Aug 2019, at 21:45, Aaron Brewster <asbrewster(a)lbl.gov <mailto:[email protected]>> wrote: >>> >>> Hi, to avoid clouding Dorothee's documentation email thread, which I think is a highly useful enterprise, here's some thoughts about putting cctbx into pip. Pip doesn't install non-python dependencies well. I don't think boost is available as a package on pip (at least the package version we use). wxPython4 isn't portable through pip (https://wiki.wxpython.org/How%20to%20install%20wxPython#Installing_wxPython… <https://wiki.wxpython.org/How%20to%20install%20wxPython#Installing_wxPython…>). MPI libraries are system dependent. If cctbx were a pure python package, pip would be fine, but cctbx is not. >>> >>> All that said, we could build a manylinux1 version of cctbx and upload it to PyPi (I'm just learning about this). For a pip package to be portable (which is a requirement for cctbx), it needs to conform to PEP513, the manylinux1 standard (https://www.python.org/dev/peps/pep-0513/ <https://www.python.org/dev/peps/pep-0513/>). For example, numpy is built according to this standard (see https://pypi.org/project/numpy/#files <https://pypi.org/project/numpy/#files>, where you'll see the manylinux1 wheel). Note, the manylinux1 standard is built with Centos 5.11 which we no longer support. >>> >>> There is also a manylinux2010 standard, which is based on Centos 6 (https://www.python.org/dev/peps/pep-0571/ <https://www.python.org/dev/peps/pep-0571/>). This is likely a more attainable target (note though by default C++11 is not supported on Centos 6). >>> >>> If we built a manylinuxX version of cctbx and uploaded it to PyPi, the user would need all the non-python dependencies. There's no way to specify these in pip. For example, cctbx requires boost 1.63 or better. The user will need to have it in a place their python can find it, or we could package it ourselves and supply it, similar to how the pip h5py package now comes with an hd5f library, or how the pip numpy package includes an openblas library. We'd have to do the same for any packages we depend on that aren't on pip using the manylinux standards, such as wxPython4. >>> >>> Further, we need to think about how dials and other cctbx-based packages interact. If pip install cctbx is set up, how does pip install dials work, such that any dials shared libraries can find the cctbx libraries? Can shared libraries from one pip package link against libraries in another pip package? Would each package need to supply its own boost? Possibly this is well understood in the pip field, but not by me :) >>> >>> Finally, there's the option of providing a source pip package. This would require the full compiler toolchain for any given platform (macOS, linux, windows). These are likely available for developers, but not for general users. >>> >>> Anyway, these are some of the obstacles. Not saying it isn't possible, it's just a lot of effort. >>> >>> Thanks, >>> -Aaron >>> >>> _______________________________________________ >>> cctbxbb mailing list >>> cctbxbb(a)phenix-online.org <mailto:[email protected]> >>> http://phenix-online.org/mailman/listinfo/cctbxbb <http://phenix-online.org/mailman/listinfo/cctbxbb> >> >> _______________________________________________ >> cctbxbb mailing list >> cctbxbb(a)phenix-online.org <mailto:[email protected]> >> http://phenix-online.org/mailman/listinfo/cctbxbb >

5 years, 10 months

Re: [cctbxbb] bootstrap.py build on Ubuntu

by David Waterman

Hey Billy, Thanks. I'm travelling at the moment, but once I'm back I'll give that a go. Cheers David On Tue, 14 Jun 2016, 17:34 Billy Poon, <bkpoon(a)lbl.gov> wrote: > Hi David, > > Actually, it looks like the lib64z1-dev package provides libz.so in > /usr/lib64, so installing that package should fix your issue. It's a bit > odd that the lib64z1 package does not provide that file. > > -- > Billy K. Poon > Research Scientist, Molecular Biophysics and Integrated Bioimaging > Lawrence Berkeley National Laboratory > 1 Cyclotron Road, M/S 33R0345 > Berkeley, CA 94720 > Tel: (510) 486-5709 > Fax: (510) 486-5909 > Web: https://phenix-online.org > > On Mon, Jun 13, 2016 at 1:53 PM, Billy Poon <bkpoon(a)lbl.gov> wrote: > >> Hi David, >> >> I don't have a fix yet, but here is a workaround. It seems like setup.py >> is looking for libz.so instead of libz.so.1, so you can fix the issue by >> making a symbolic link for libz.so in /usr/lib64. >> >> sudo ln -s /usr/lib64/libz.so.1 /usr/lib64/libz.so >> >> This requires root access, so that's why it's just a workaround. >> >> -- >> Billy K. Poon >> Research Scientist, Molecular Biophysics and Integrated Bioimaging >> Lawrence Berkeley National Laboratory >> 1 Cyclotron Road, M/S 33R0345 >> Berkeley, CA 94720 >> Tel: (510) 486-5709 >> Fax: (510) 486-5909 >> Web: https://phenix-online.org >> >> On Sat, Jun 11, 2016 at 5:05 PM, Billy Poon <bkpoon(a)lbl.gov> wrote: >> >>> Hi David, >>> >>> Sorry it look so long! Setting up all the virtual machines was a time >>> sink and getting things to work on 32-bit CentOS 5 and Ubuntu 12.04 was a >>> little tricky. >>> >>> It looks like Ubuntu 16.04 moved its libraries around. I used apt-get to >>> install libz-dev and lib64z1 (the 64-bit library). There is a libz.so.1 >>> file in /lib/x86_64-linux-gnu and in /usr/lib64. >>> >>> I have not gotten it to work yet, but I'm pretty sure this is the issue. >>> I'll have to double-check 12.04 and 14.04. >>> >>> As for Pillow, I did test it a few months ago, but I remember there >>> being API changes that will need to fixed. >>> >>> -- >>> Billy K. Poon >>> Research Scientist, Molecular Biophysics and Integrated Bioimaging >>> Lawrence Berkeley National Laboratory >>> 1 Cyclotron Road, M/S 33R0345 >>> Berkeley, CA 94720 >>> Tel: (510) 486-5709 >>> Fax: (510) 486-5909 >>> Web: https://phenix-online.org >>> >>> On Sat, Jun 11, 2016 at 2:04 AM, David Waterman <dgwaterman(a)gmail.com> >>> wrote: >>> >>>> Hi Billy, >>>> >>>> I'm replying on this old thread because I have finally got round to >>>> trying a bootstrap build for DIALS out again on Ubuntu, having waited for >>>> updates to the dependencies and updating the OS to 16.04. >>>> >>>> The good news is, the build ran through fine. This is the first time >>>> I've had a bootstrap build complete without error on Ubuntu, so thanks to >>>> you and the others who have worked on improving the build in the last few >>>> months! >>>> >>>> The bad news is I'm getting two failures in the DIALS tests: >>>> >>>> dials/test/command_line/tst_export_bitmaps.py >>>> dials_regression/test.py >>>> >>>> Both are from PIL >>>> >>>> File >>>> "/home/fcx32934/dials_test_build/base/lib/python2.7/site-packages/PIL/Image.py", >>>> line 401, in _getencoder >>>> raise IOError("encoder %s not available" % encoder_name) >>>> IOError: encoder zip not available >>>> >>>> Indeed, from base_tmp/imaging_install_log it looks like PIL is not >>>> configured properly >>>> >>>> -------------------------------------------------------------------- >>>> PIL 1.1.7 SETUP SUMMARY >>>> -------------------------------------------------------------------- >>>> version 1.1.7 >>>> platform linux2 2.7.8 (default_cci, Jun 10 2016, 16:04:32) >>>> [GCC 5.3.1 20160413] >>>> -------------------------------------------------------------------- >>>> *** TKINTER support not available >>>> *** JPEG support not available >>>> *** ZLIB (PNG/ZIP) support not available >>>> *** FREETYPE2 support not available >>>> *** LITTLECMS support not available >>>> -------------------------------------------------------------------- >>>> >>>> Any ideas? I have zlib headers but perhaps PIL can't find them. >>>> >>>> On a related note, the free version of PIL has not been updated for >>>> years. The replacement Pillow has started to diverge. I first noticed this >>>> when Ubuntu 16.04 gave me Pillow 3.1.2 and my cctbx build with the system >>>> python produced failures because it no longer supports certain deprecated >>>> methods from PIL. I worked around that in r24587, but these things are a >>>> losing battle. Is it time to switch cctbx over to Pillow instead of PIL? >>>> >>>> Cheers >>>> >>>> -- David >>>> >>>> On 7 January 2016 at 18:12, Billy Poon <bkpoon(a)lbl.gov> wrote: >>>> >>>>> Hi all, >>>>> >>>>> Since wxPython was updated to 3.0.2, I have been thinking about >>>>> updating the other GUI-related packages to more recent versions. I would >>>>> probably update to the latest, stable version that does not involve major >>>>> changes to the API so that backwards compatibility is preserved. Let me >>>>> know if that would be helpful and I can prioritize the migration and >>>>> testing. >>>>> >>>>> -- >>>>> Billy K. Poon >>>>> Research Scientist, Molecular Biophysics and Integrated Bioimaging >>>>> Lawrence Berkeley National Laboratory >>>>> 1 Cyclotron Road, M/S 33R0345 >>>>> Berkeley, CA 94720 >>>>> Tel: (510) 486-5709 >>>>> Fax: (510) 486-5909 >>>>> Web: https://phenix-online.org >>>>> >>>>> On Thu, Jan 7, 2016 at 9:30 AM, Nicholas Sauter <nksauter(a)lbl.gov> >>>>> wrote: >>>>> >>>>>> David, >>>>>> >>>>>> I notice that the Pango version, 1.16.1, was released in 2007, so >>>>>> perhaps it is no surprise that the latest Ubuntu does not support it. >>>>>> Maybe this calls for stepping forward the Pango version until you find one >>>>>> that works. I see that the latest stable release is 1.39. >>>>>> >>>>>> This would be valuable information for us..Billy Poon in the Phenix >>>>>> group is supporting the Phenix GUI, so it might be advisable for him to >>>>>> update the Pango version in the base installer. >>>>>> >>>>>> Nick >>>>>> >>>>>> Nicholas K. Sauter, Ph. D. >>>>>> Computer Staff Scientist, Molecular Biophysics and Integrated >>>>>> Bioimaging Division >>>>>> Lawrence Berkeley National Laboratory >>>>>> 1 Cyclotron Rd., Bldg. 33R0345 >>>>>> Berkeley, CA 94720 >>>>>> (510) 486-5713 >>>>>> >>>>>> On Thu, Jan 7, 2016 at 8:54 AM, David Waterman <dgwaterman(a)gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Hi again >>>>>>> >>>>>>> Another data point: I just tried this on a different Ubuntu machine, >>>>>>> this time running 14.04. In this case pango installed just fine. In fact >>>>>>> all other packages installed too and the machine is now compiling cctbx. >>>>>>> >>>>>>> I might have enough for comparison between the potentially working >>>>>>> 14.04 and failed 15.04 builds to figure out what is wrong in the second >>>>>>> case. >>>>>>> >>>>>>> Cheers >>>>>>> >>>>>>> -- David >>>>>>> >>>>>>> On 7 January 2016 at 09:56, David Waterman <dgwaterman(a)gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi folks >>>>>>>> >>>>>>>> I recently tried building cctbx+dials on Ubuntu 15.04 following the >>>>>>>> instructions here: >>>>>>>> http://dials.github.io/documentation/installation_developer.html >>>>>>>> >>>>>>>> This failed during installation of pango-1.16.1. Looking >>>>>>>> at pango_install_log, I see the command that failed was as follows: >>>>>>>> >>>>>>>> gcc -DHAVE_CONFIG_H -I. -I. -I../.. >>>>>>>> -DSYSCONFDIR=\"/home/fcx32934/sw/dials_bootstrap_test/base/etc\" >>>>>>>> -DLIBDIR=\"/home/fcx32934/sw/dials_bootstrap_test/base/lib\" >>>>>>>> -DG_DISABLE_CAST_CHECKS -I../.. -DG_DISABLE_DEPRECATED >>>>>>>> -I/home/fcx32934/sw/dials_bootstrap_test/base/include >>>>>>>> -I/home/fcx32934/sw/dials_bootstrap_test/base/include/freetype2 -g -O2 >>>>>>>> -Wall -MT fribidi.lo -MD -MP -MF .deps/fribidi.Tpo -c fribidi.c -fPIC >>>>>>>> -DPIC -o .libs/fribidi.o >>>>>>>> In file included from fribidi.h:31:0, >>>>>>>> from fribidi.c:28: >>>>>>>> fribidi_config.h:1:18: fatal error: glib.h: No such file or >>>>>>>> directory >>>>>>>> >>>>>>>> The file glib.h appears to be in base/include/glib-2.0/, however >>>>>>>> this directory was not explicitly included in the command above, only its >>>>>>>> parent. This suggests a configuration failure in pango to me. Taking a look >>>>>>>> at base_tmp/pango-1.16.1/config.log, I see what look like the relevant >>>>>>>> lines: >>>>>>>> >>>>>>>> configure:22227: checking for GLIB >>>>>>>> configure:22235: $PKG_CONFIG --exists --print-errors "$GLIB_MODULES" >>>>>>>> configure:22238: $? = 0 >>>>>>>> configure:22253: $PKG_CONFIG --exists --print-errors "$GLIB_MODULES" >>>>>>>> configure:22256: $? = 0 >>>>>>>> configure:22304: result: yes >>>>>>>> >>>>>>>> but this doesn't tell me very much. Does anyone have any >>>>>>>> suggestions as to how I might proceed? >>>>>>>> >>>>>>>> Many thanks >>>>>>>> >>>>>>>> -- David >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> >> > _______________________________________________ > cctbxbb mailing list > cctbxbb(a)phenix-online.org > http://phenix-online.org/mailman/listinfo/cctbxbb >

9 years

Re: [cctbxbb] use_internal_variance in iotbx.merging_statistics

by richard.gildea＠diamond.ac.uk

Dear Keitaro, I've made the change you suggested in merging_statistics.py - it looks like an oversight, which didn't affect xia2 since we are always calculating merging statistics given an scaled but unmerged mtz file, never an XDS or scalepack-format file. As to what defaults Phenix uses, that is better left to one of the Phenix developers to comment on. Cheers, Richard Dr Richard Gildea Data Analysis Scientist Tel: +441235 77 8078 Diamond Light Source Ltd. Diamond House Harwell Science & Innovation Campus Didcot Oxfordshire OX11 0DE ________________________________________ From: cctbxbb-bounces(a)phenix-online.org [cctbxbb-bounces(a)phenix-online.org] on behalf of Keitaro Yamashita [k.yamashita(a)spring8.or.jp] Sent: 01 November 2016 10:41 To: cctbx mailing list Subject: Re: [cctbxbb] use_internal_variance in iotbx.merging_statistics Dear Richard and everyone, Thanks for your reply. What kind of input do you give to iotbx.merging_statistics in xia2? For example, when XDS file is given, use_internal_variance=False is not passed to merge_equivalents() function. Please look at the lines of filter_intensities_by_sigma.__init__() in iotbx/merging_statistics.py. When sigma_filtering == "xds" or sigma_filtering == "scalepack", array_merged is recalculated using merge_equivalents() with default arguments. If nobody disagrees, I would like to commit the fix so that use_internal_variance variable is passed to all merge_equivalents() function calls. I am afraid that the behavior in the phenix-1.11 would be confusing. In phenix.table_one (mmtbx/command_line/table_one.py), use_internal_variance=False is default. This will be OK with the fix I suggested above. Can it also be default in phenix.merging_statistics, not to change the program behavior through phenix versions? Best regards, Keitaro 2016-11-01 18:21 GMT+09:00 <richard.gildea(a)diamond.ac.uk>: > Dear Keitaro, > > iotbx.merging_statistics does have the option to change the parameter use_internal_variance. In xia2 we use the defaults use_internal_variance=False, eliminate_sys_absent=False, n_bins=20, when calculating merging statistics which give comparable results to those calculate by Aimless: > > $ iotbx.merging_statistics > Usage: > phenix.merging_statistics [data_file] [options...] > > Calculate merging statistics for non-unique data, including R-merge, R-meas, > R-pim, and redundancy. Any format supported by Phenix is allowed, including > MTZ, unmerged Scalepack, or XDS/XSCALE (and possibly others). Data should > already be on a common scale, but with individual observations unmerged. > Diederichs K & Karplus PA (1997) Nature Structural Biology 4:269-275 > (with erratum in: Nat Struct Biol 1997 Jul;4(7):592) > Weiss MS (2001) J Appl Cryst 34:130-135. > Karplus PA & Diederichs K (2012) Science 336:1030-3. > > > Full parameters: > > file_name = None > labels = None > space_group = None > unit_cell = None > symmetry_file = None > high_resolution = None > low_resolution = None > n_bins = 10 > extend_d_max_min = False > anomalous = False > sigma_filtering = *auto xds scala scalepack > .help = "Determines how data are filtered by SigmaI and I/SigmaI. XDS" > "discards reflections whose intensity after merging is less than" > "-3*sigma, Scalepack uses the same cutoff before merging, and" > "SCALA does not do any filtering. Reflections with negative SigmaI" > "will always be discarded." > use_internal_variance = True > eliminate_sys_absent = True > debug = False > loggraph = False > estimate_cutoffs = False > job_title = None > .help = "Job title in PHENIX GUI, not used on command line" > > > Below is my email to Pavel and Billy when we discussed this issue by email a while back: > > The difference between use_internal_variance=True/False is explained in Luc's document here: > > libtbx.pdflatex $(libtbx.find_in_repositories cctbx/miller)/equivalent_reflection_merging.tex > > Essentially use_internal_variance=False uses only the unmerged sigmas to compute the merged sigmas, whereas use_internal_variance=True uses instead the spread of the unmerged intensities to compute the merged sigmas. Furthermore, use_internal_variance=True uses the largest of the variance coming from the spread of the intensities and that computed from the unmerged sigmas. As a result, use_internal_variance=True can only ever give lower I/sigI than use_internal_variance=False. The relevant code in the cctbx is here: > > https://sourceforge.net/p/cctbx/code/HEAD/tree/trunk/cctbx/miller/merge_equ… > > Aimless has a similar option for the SDCORRECTION keyword, if you set the option SAMPLESD, which I think is equivalent to use_internal_variance=True. The default behaviour of Aimless is equivalent to use_internal_variance=False: > > http://www.mrc-lmb.cam.ac.uk/harry/pre/aimless.html#sdcorrection > > "SAMPLESD is intended for very high multiplicity data such as XFEL serial data. The final SDs are estimated from the weighted population variance, assuming that the input sigma(I)^2 values are proportional to the true errors. This probably gives a more realistic estimate of the error in <I>. In this case refinement of the corrections is switched off unless explicitly requested." > > I think that the "external" variance is probably better if the sigmas from the scaling program are reliable, or for low multiplicity data. For high multiplicity data or if the sigmas from the scaling program are not reliable, then "internal" variance is probably better. > > Cheers, > > Richard > > Dr Richard Gildea > Data Analysis Scientist > Tel: +441235 77 8078 > > Diamond Light Source Ltd. > Diamond House > Harwell Science & Innovation Campus > Didcot > Oxfordshire > OX11 0DE > > ________________________________________ > From: cctbxbb-bounces(a)phenix-online.org [cctbxbb-bounces(a)phenix-online.org] on behalf of Keitaro Yamashita [k.yamashita(a)spring8.or.jp] > Sent: 01 November 2016 07:23 > To: cctbx mailing list > Subject: [cctbxbb] use_internal_variance in iotbx.merging_statistics > > Dear Phenix/CCTBX developers, > > iotbx/merging_statistics.py is used by phenix.merging_statistics, > phenix.table_one, and so on. By upgrading phenix from 1.10.1 to 1.11, > merging statistics-related codes were significantly changed. > > Previously, miller.array.merge_equivalents() was always called with > argument use_internal_variance=False, which is consistent with XDS, > Aimless and so on. Currently, use_internal_variance=True is default, > and cannot be changed by users (see below). > > These changes were made by @afonine and @rjgildea in rev. 22973 (Sep > 26, 2015) and 23961 (Mar 8, 2016). Could anyone explain why these > changes were introduced? > > https://sourceforge.net/p/cctbx/code/22973 > https://sourceforge.net/p/cctbx/code/23961 > > > My points are: > > - We actually cannot control use_internal_variance= parameter because > it is not passed to merge_equivalents() in class > filter_intensities_by_sigma. > > - In previous versions, if I gave XDS output to > phenix.merging_statistics, <I/sigma> values calculated in the same way > (as XDS does) were shown; but not in the current version. > > - For (for example) phenix.table_one users who expect this behavior, > it can give inconsistency. The statistics would not be consistent with > the data used in refinement. > > > cf. the related discussion in cctbxbb: > http://phenix-online.org/pipermail/cctbxbb/2012-October/000611.html > > > Best regards, > Keitaro > _______________________________________________ > 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 > > > _______________________________________________ > 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

8 years, 8 months

Search results for query "look through"