Search results for "look through"

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

by Luca Jovine

Thank you for the info Randy, I confirm that in the last available nightly build (1.21rc1-5015) the issue is clearly fixed, resulting in a >70-fold speed increase compared to Phaser-MR from 1.21rc1-5008. For two sample jobs using intensity data on a M2 MacBook Pro: 1.21rc1-5008: ------------------ Job 1: CPU Time: 0 days 0 hrs 37 mins 23.01 secs ( 2243.01 secs) Job 2: CPU Time: 0 days 0 hrs 31 mins 10.79 secs ( 1870.79 secs) 1.21rc1-5015: ------------------- Job 1: CPU Time: 0 days 0 hrs 0 mins 31.13 secs ( 31.13 secs) Job 2: CPU Time: 0 days 0 hrs 0 mins 25.44 secs ( 25.44 secs) ...thanks for the fix!! Luca -----Original Message----- From: Randy John Read <rjr27(a)cam.ac.uk <mailto:[email protected]>> Date: Tuesday, 4 July 2023 at 17:37 To: Xavier Brazzolotto <xbrazzolotto(a)gmail.com <mailto:[email protected]>> Cc: PHENIX user mailing list <phenixbb(a)phenix-online.org <mailto:[email protected]>>, Luca Jovine <luca.jovine(a)ki.se <mailto:[email protected]>> Subject: Re: [phenixbb] Discrepancy between Phenix GUI and command line for MR 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] <mailto:[email protected]>>> on behalf of Xavier Brazzolotto <xbrazzolotto(a)gmail.com <mailto:[email protected]> <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] <mailto:[email protected]>>> > > Cc: PHENIX user mailing list <phenixbb(a)phenix-online.org <mailto:[email protected]> <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] <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] <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] <mailto:[email protected]>> > >>> http://phenix-online.org/mailman/listinfo/phenixbb <http://phenix-online.org/mailman/listinfo/phenixbb> <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] <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] <mailto:[email protected]>> > >> Cambridge CB2 0XY, U.K. www-structmed.cimr.cam.ac.uk > >> > > > > > > > > > > _______________________________________________ > > phenixbb mailing list > > phenixbb(a)phenix-online.org <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> > > http://phenix-online.org/mailman/listinfo/phenixbb <http://phenix-online.org/mailman/listinfo/phenixbb> <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] <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> <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> <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

2 years, 7 months

Re: [cctbxbb] [Dials-support] DIALS source tarball

by Graeme.Winter＠diamond.ac.uk

Sadly this also does not fix anything :o( not sure why this was not flagged when I configured chem_data... libtbx.python "/Users/graeme/svn/cctbx/modules/cctbx_project/cctbx/regression/tst_geometry_restraints_2.py" [FAIL] Time: 6.44 Return code: 1 OKs: 0 Standard error: Traceback (most recent call last): File "/Users/graeme/svn/cctbx/modules/cctbx_project/cctbx/regression/tst_geometry_restraints_2.py", line 866, in <module> exercise_all(sys.argv[1:]) File "/Users/graeme/svn/cctbx/modules/cctbx_project/cctbx/regression/tst_geometry_restraints_2.py", line 862, in exercise_all exercise_na_restraints_output_to_geo(verbose=verbose) File "/Users/graeme/svn/cctbx/modules/cctbx_project/cctbx/regression/tst_geometry_restraints_2.py", line 818, in exercise_na_restraints_output_to_geo log=out2) File "/Users/graeme/svn/cctbx/modules/cctbx_project/mmtbx/monomer_library/pdb_interpretation.py", line 5274, in run nonbonded_distance_threshold=nonbonded_distance_threshold) File "/Users/graeme/svn/cctbx/modules/cctbx_project/mmtbx/monomer_library/pdb_interpretation.py", line 4952, in geometry_restraints_manager ss_manager.initialize(log=self.log) File "/Users/graeme/svn/cctbx/modules/cctbx_project/mmtbx/secondary_structure/__init__.py", line 280, in initialize self.find_automatically(log=log) File "/Users/graeme/svn/cctbx/modules/cctbx_project/mmtbx/secondary_structure/__init__.py", line 313, in find_automatically self.sec_str_from_pdb_file = self.find_sec_str(log=log) File "/Users/graeme/svn/cctbx/modules/cctbx_project/mmtbx/secondary_structure/__init__.py", line 369, in find_sec_str (records, stderr) = run_ksdssp_direct(pdb_str) File "/Users/graeme/svn/cctbx/modules/cctbx_project/mmtbx/secondary_structure/__init__.py", line 728, in run_ksdssp_direct exe_path = get_ksdssp_exe_path() File "/Users/graeme/svn/cctbx/modules/cctbx_project/mmtbx/secondary_structure/__init__.py", line 709, in get_ksdssp_exe_path raise RuntimeError("ksdssp module is not configured") RuntimeError: ksdssp module is not configured On 8 Apr 2015, at 11:02, <richard.gildea(a)diamond.ac.uk<mailto:[email protected]>> <richard.gildea(a)diamond.ac.uk<mailto:[email protected]>> wrote: $ du -h --max-depth=0 chem_data 1.6G chem_data Not sure we really want to include this in the dials builds, just to make one test happy, especially when we have no use for any of the monomer library functionality in dials. Cheers, Richard ________________________________ From: Graeme Winter [graeme.winter(a)gmail.com<mailto:[email protected]>] Sent: 08 April 2015 10:58 To: Gildea, Richard (DLSLtd,RAL,LSCI); Gerstel, Markus (DLSLtd,RAL,LSCI); asbrewster(a)lbl.gov<mailto:[email protected]>; cctbxbb(a)phenix-online.org<mailto:[email protected]> Cc: dials-support(a)lists.sourceforge.net<mailto:[email protected]> Subject: Re: [Dials-support] [cctbxbb] DIALS source tarball can we add this to the dials build through some kind of tarball download which does not need a cci account? Thanks graeme On Wed, Apr 8, 2015 at 10:52 AM <richard.gildea(a)diamond.ac.uk<mailto:[email protected]><mailto:[email protected]>> wrote: Hi Markus, I agree that it would be better if the tests would either work gracefully with CCP4 monomer library, or (possibly better?) only run if chem_data is available. In the latter case, a simple libtbx.env.has_module("chem_data") could be used in the test to check whether chem_data is available. As a workaround, we developers should be able to add the chem_data repository to our sources after which the tests should pick up the correct version of the monomer library: $ svn co svn+ssh://[email protected]/chem_data/trunk<http://[email protected]/chem_data/trunk> chem_data $ libtbx.configure chem_data Cheers, Richard ________________________________________ From: Gerstel, Markus (DLSLtd,RAL,LSCI) Sent: 08 April 2015 09:33 To: Gildea, Richard (DLSLtd,RAL,LSCI); asbrewster(a)lbl.gov<mailto:[email protected]><mailto:[email protected]>; cctbxbb(a)phenix-online.org<mailto:[email protected]><mailto:[email protected]> Cc: dials-support(a)lists.sourceforge.net<mailto:[email protected]><mailto:[email protected]> Subject: RE: [Dials-support] [cctbxbb] DIALS source tarball Hi Richard, I think you've found it. I have unset CLIBD_MON, and now the test skips cleanly. Of course this also means that users should not run cctbx tests on their machines... Is there no central 'mmtbx_skip_test_if_chem_data_db_missing' function, that just goes 'prints "Skip this test"; exit' if the library isn't present? Or a boolean _is_available() function if you prefer. Either would resolve this problem as well as the current untestability of mmtbx. -Markus -----Original Message----- From: Gildea, Richard (DLSLtd,RAL,LSCI) Sent: 08 April 2015 09:15 To: Gerstel, Markus (DLSLtd,RAL,LSCI); asbrewster(a)lbl.gov<mailto:[email protected]><mailto:[email protected]>; cctbxbb(a)phenix-online.org<mailto:[email protected]><mailto:[email protected]> Cc: dials-support(a)lists.sourceforge.net<mailto:[email protected]><mailto:[email protected]> Subject: RE: [Dials-support] [cctbxbb] DIALS source tarball Hi Markus, Presumably the test is looking for a monomer that is present in chem_data but not in the ccp4 monomer library? Could we unset the CLIBD_MON variable for the purposes of testing the dials installers? Cheers, Richard ________________________________________ From: Gerstel, Markus (DLSLtd,RAL,LSCI) Sent: 08 April 2015 09:07 To: Gildea, Richard (DLSLtd,RAL,LSCI); asbrewster(a)lbl.gov<mailto:[email protected]><mailto:[email protected]>; cctbxbb(a)phenix-online.org<mailto:[email protected]><mailto:[email protected]> Cc: dials-support(a)lists.sourceforge.net<mailto:[email protected]><mailto:[email protected]> Subject: RE: [Dials-support] [cctbxbb] DIALS source tarball Hi Richard, Aaron, This is correct, we do not currently run mmtbx tests at all, as up to 107 of them do not fail gracefully, ie. skip properly. The test in question works fine (ie: is skipped because CCP4 is not made available) on our cctbx test system, but breaks in our final dials installer tests (where CCP4 is made available). CLIBD_MON is set to the /lib/data/monomers folder in the shared DLS CCP4 6.5 update 1 installation. Best wishes, Markus -----Original Message----- From: richard.gildea(a)diamond.ac.uk<mailto:[email protected]><mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] Sent: 07 April 2015 21:36 To: asbrewster(a)lbl.gov<mailto:[email protected]><mailto:[email protected]>; cctbxbb(a)phenix-online.org<mailto:[email protected]><mailto:[email protected]> Cc: dials-support(a)lists.sourceforge.net<mailto:[email protected]><mailto:[email protected]> Subject: Re: [Dials-support] [cctbxbb] DIALS source tarball Hi Aaron, I'm not sure your fix as I understand it actually helps. The test that was failing was in the cctbx module, not mmtbx, and as far as I am aware we are running libtbx.run_tests_parallel module=cctbx module=dxtbx etc in our nightly builds (and that is what we as developers are running locally on our own development machines). If individual tests (particularly those in the more general modules such as cctbx, iotbx, etc.) rely on external dependencies (such as chem_data) being available, then the individual tests should test for presence of said dependencies and skip gracefully if not available. I have a feeling that we're not even including mmtbx in our nightly build tests (too many fail due to missing dependencies such as chem_data). Cheers, Richard ________________________________ From: Aaron Brewster [asbrewster(a)lbl.gov<mailto:[email protected]><mailto:[email protected]>] Sent: 07 April 2015 20:29 To: cctbx mailing list Cc: Waterman, David (STFC,RAL,SC); Gildea, Richard (DLSLtd,RAL,LSCI); Johan Hattne; <dials-support(a)lists.sourceforge.net<mailto:[email protected]><mailto:[email protected]>> Subject: Re: [cctbxbb] [Dials-support] DIALS source tarball Hi Markus, two points. First, you are correct that the dials builds are not passing tests related to the chem_data folder which includes monomer libraries. This is because chem_data is required by mmtbx but isn't included in the dials build. Partly because we're unsure if pieces of it are proprietary. In the meantime, I've worked with Nigel to change the cctbx_regression.test_nightly to look for the chem_data repository and skip the mmtbx tests if it's not present. mmtbx will still be tested nightly as part of the standalone cctbx and phenix packages. Because of this change, perhaps you could revert your recent changes to cctbx/regression/tst_geometry_restraints_2.py? It isn't necessary to check for chem_data in every sub test as it is tested for at the top level now. Second, the log you provided is not the one on buildbot. Your log indicates you have a CCP4 installation that includes a monomer library that is being picked up by the tests. Is one of the MMTBX_CCP4_MONOMER_LIB, or CLIBD_MON environment variables set on the system in question? Thanks, -Aaron On Tue, Apr 7, 2015 at 6:41 AM, <markus.gerstel(a)diamond.ac.uk<mailto:[email protected]><mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> wrote: Cc'ing cctbx folks David Waterman wrote: So maybe once we have a source tarball up at dials.diamond.ac.uk<http://dials.diamond.ac.uk><http://dials.diamond.ac.uk><http://dials.diamond.ac.uk> (..) Speaking of which: our DIALS builds are currently failing at the installer testing stage. This is due to cctbx/regression/tst_geometry_restraints_2.py failing deep in mmtbx territory. So far I could not figure out how to get this running properly. Call: libtbx.python tst_geometry_restraints_2.py Standard Output Skipping exercise_with_zeolite(): input file not available Skipping exercise_with_pdb(): chem_data directory not available Standard Error Traceback (most recent call last): File "/scratch/jenkins_slave/workspace/dials_test_installer/dials-dev/modules/cctbx_project/cctbx/regression/tst_geometry_restraints_2.py", line 866, in <module> exercise_all(sys.argv[1:]) File "/scratch/jenkins_slave/workspace/dials_test_installer/dials-dev/modules/cctbx_project/cctbx/regression/tst_geometry_restraints_2.py", line 862, in exercise_all exercise_na_restraints_output_to_geo(verbose=verbose) File "/scratch/jenkins_slave/workspace/dials_test_installer/dials-dev/modules/cctbx_project/cctbx/regression/tst_geometry_restraints_2.py", line 805, in exercise_na_restraints_output_to_geo log=out1) File "/scratch/jenkins_slave/workspace/dials_test_installer/dials-dev/modules/cctbx_project/mmtbx/monomer_library/pdb_interpretation.py", line 5270, in run log=log) File "/scratch/jenkins_slave/workspace/dials_test_installer/dials-dev/modules/cctbx_project/mmtbx/monomer_library/pdb_interpretation.py", line 4876, in __init__ restraints_loading_flags=restraints_loading_flags, File "/scratch/jenkins_slave/workspace/dials_test_installer/dials-dev/modules/cctbx_project/mmtbx/monomer_library/pdb_interpretation.py", line 2902, in __init__ log=log, File "/scratch/jenkins_slave/workspace/dials_test_installer/dials-dev/modules/cctbx_project/mmtbx/monomer_library/pdb_interpretation.py", line 2287, in __init__ m_j=mm) File "/scratch/jenkins_slave/workspace/dials_test_installer/dials-dev/modules/cctbx_project/mmtbx/monomer_library/pdb_interpretation.py", line 1513, in get_lib_link return mon_lib_srv.link_link_id_dict["rna3p"] KeyError: 'rna3p' (On a side note: We really should call multiple tests within the same python file separately, instead of running them together within a signle run() method. This file contains 4 tests, but these will result in only a single return value for any upstream processing of the test results, such as Jenkins.) -Markus -- 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 ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ DIALS-support mailing list DIALS-support(a)lists.sourceforge.net<mailto:[email protected]><mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/dials-support

10 years, 10 months

Re: [phenixbb] questions

by Nigel W. Moriarty

Jianghi I can answer some of your questions. See below. Jianghai Zhu wrote: >Hi, > >Got some questions in using phenix.refine. > >1) Can phenix.refine use the ligand library generated by refmac5? > > Yes, it should. >2) How do I use elbow to generate the ligand library when I have more >than one kind of ligands? When I used --residue=xxx more than once, >elbow will only generated library for the last ligand. If I use >elbow multiple times to generate multiple libraries, how do I read >the libraries in? Should I combine them to one file? > > If you have a more recent version of eLBOW you can create a single restraints file for a single PDB file thus elbow.builder protein_and_ligands.pdb --do-all --opt In older versions, you should be able to elbow.builder protein_and_ligands.pdb --residue=LG1,LG2,LG3 --opt to generate the residues you desire. Use elbow.join_cif_files to combine single CIF files into one file. To read more than one CIF file into phenix.refine simply add the file names to the command line phenix.refine filename.pdb filename.mtz ligand1.cif ligand2.cif >3) When I ran phenix.refine, I found the following message in the log. > > Number of residues, atoms: 32, 418 > Unusual residues: {'NAG': 22, 'MAN': 10} > Classifications: {'undetermined': 32} > Link IDs: {None: 31} > Unresolved non-hydrogen bonds: 32 > Unresolved non-hydrogen angles: 64 > Unresolved non-hydrogen dihedrals: 22 > Unresolved non-hydrogen chiralities: 32 > Number of residues, atoms: 18, 28 > Unusual residues: {'GOL': 2, ' MG': 2, ' CA': 14} > Classifications: {'undetermined': 18} > Link IDs: {None: 17} > >I already gave the cif library for NAG. Looks like nothing >happened. How come phenix.refine doesn't recognize Glycerol, Mg, and >Ca? > > The most recent version of phenix.refine will recognise the single metal atoms but currently you need to generate the CIF for glycerol with eLBOW. I have attached a CIF file for GOL using the standard atomic naming from the PDB MSDChem database. >4) The refinement (TLS + ML + B individual) went through, I got >reasonable R, Rfree, rmsdBOND, rmsdANGLE. But the B factors are >pretty low. The B factor of the backbone is much lower than the side >chain, some have numbers like 4. Some metal atoms also have B >factors around 4. What did I do wrong? > >Thanks. > >Jianghai >_______________________________________________ >phenixbb mailing list >phenixbb(a)phenix-online.org >http://www.phenix-online.org/mailman/listinfo/phenixbb > > > -- Nigel W. Moriarty Building 64R0246B, Physical Biosciences Division Lawrence Berkeley National Laboratory Berkeley, CA 94720-8235 Phone : 510-486-5709 Fax : 510-486-5909 Email : NWMoriarty(a)LBL.gov Web : CCI.LBL.gov # electronic Ligand Builder and Optimisation Workbench (eLBOW) # - a module of PHENIX version 1.25b (Mon Sep 17 16:26:00 2006) # - file written: Thu Dec 14 08:55:16 2006 # # Quantum optimisation: True # Method: AM1 # SMILES string: OCC(O)CO # Template file: /net/cci/filer1/share/rdb_resources/hicup/g/gol_clean.pdb # data_comp_list loop_ _chem_comp.id _chem_comp.three_letter_code _chem_comp.name _chem_comp.group _chem_comp.number_atoms_all _chem_comp.number_atoms_nh _chem_comp.desc_level LIG LIG 'Unknown ' ligand 14 6 . # data_comp_LIG # loop_ _chem_comp_atom.comp_id _chem_comp_atom.atom_id _chem_comp_atom.type_symbol _chem_comp_atom.type_energy _chem_comp_atom.partial_charge _chem_comp_atom.x _chem_comp_atom.y _chem_comp_atom.z LIG O1 O OH1 . 0.0208 0.0709 0.0355 LIG C1 C CH2 . 1.4325 -0.0011 0.0109 LIG C2 C CH1 . 1.9132 0.0138 1.4647 LIG O2 O OH1 . 1.3682 -1.1074 2.1354 LIG C3 C CH2 . 3.4402 -0.1109 1.4474 LIG O3 O OH1 . 3.8600 -0.1930 2.7956 LIG 1H01 H HOH1 . -0.2646 0.0606 -0.8845 LIG 1H02 H HCH2 . 1.8594 0.8904 -0.5225 LIG 2H02 H HCH2 . 1.7739 -0.9421 -0.4960 LIG 1H03 H HCH1 . 1.6018 0.9730 1.9593 LIG 1H04 H HOH1 . 0.9761 -0.7765 2.9506 LIG 1H05 H HCH2 . 3.8935 0.7878 0.9507 LIG 2H05 H HCH2 . 3.7316 -1.0360 0.8822 LIG 1H06 H HOH1 . 4.8200 -0.2706 2.7757 # loop_ _chem_comp_bond.comp_id _chem_comp_bond.atom_id_1 _chem_comp_bond.atom_id_2 _chem_comp_bond.type _chem_comp_bond.value_dist _chem_comp_bond.value_dist_esd LIG C1 O1 single 1.41370 0.02 LIG C2 C1 single 1.53131 0.02 LIG O2 C2 single 1.41559 0.02 LIG C3 C2 single 1.53210 0.02 LIG O3 C3 single 1.41441 0.02 LIG 1H01 O1 single 0.96335 0.02 LIG 1H02 C1 single 1.12320 0.02 LIG 2H02 C1 single 1.12196 0.02 LIG 1H03 C2 single 1.12330 0.02 LIG 1H04 O2 single 0.96319 0.02 LIG 1H05 C3 single 1.12248 0.02 LIG 2H05 C3 single 1.12263 0.02 LIG 1H06 O3 single 0.96326 0.02 # loop_ _chem_comp_angle.comp_id _chem_comp_angle.atom_id_1 _chem_comp_angle.atom_id_2 _chem_comp_angle.atom_id_3 _chem_comp_angle.value_angle _chem_comp_angle.value_angle_esd LIG C2 C1 O1 107.24269 3.0 LIG 1H02 C1 O1 110.32761 3.0 LIG 2H02 C1 O1 110.75942 3.0 LIG 1H01 O1 C1 106.18066 3.0 LIG O2 C2 C1 108.73907 3.0 LIG C3 C2 C1 107.54137 3.0 LIG 1H03 C2 C1 109.83557 3.0 LIG 1H02 C1 C2 108.89201 3.0 LIG 2H02 C1 C2 109.97070 3.0 LIG 1H04 O2 C2 106.59896 3.0 LIG O3 C3 C2 106.84813 3.0 LIG 1H05 C3 C2 110.01935 3.0 LIG 2H05 C3 C2 109.35677 3.0 LIG C3 C2 O2 108.94178 3.0 LIG 1H03 C2 O2 111.15686 3.0 LIG 1H03 C2 C3 110.53511 3.0 LIG 1H06 O3 C3 106.30838 3.0 LIG 1H05 C3 O3 110.39062 3.0 LIG 2H05 C3 O3 110.79298 3.0 LIG 2H02 C1 1H02 109.60233 3.0 LIG 2H05 C3 1H05 109.39863 3.0 # loop_ _chem_comp_tor.comp_id _chem_comp_tor.id _chem_comp_tor.atom_id_1 _chem_comp_tor.atom_id_2 _chem_comp_tor.atom_id_3 _chem_comp_tor.atom_id_4 _chem_comp_tor.value_angle _chem_comp_tor.value_angle_esd _chem_comp_tor.period LIG Var_01 O2 C2 C1 O1 60.33884 10.0 1 LIG Var_02 C3 C2 C1 O1 178.16082 10.0 1 LIG Var_03 O3 C3 C2 C1 -175.86192 10.0 1 LIG Var_04 O3 C3 C2 O2 -58.17137 10.0 1

19 years, 1 month

Re: [phenixbb] reflection file utility and use of modified phases in refinement

by Engin Ozkan

Thank you. Another colleague had actually pointed out the issue to me. A detailed explanation of all mtz labels within the documentation might help. Engin On 8/28/09 7:47 AM, Thomas C. Terwilliger wrote: > Hi Engin, > > Thanks, yes, I see now what you are looking at: > > --- Data for refinement FP SIGFP PHIM FOMM HLAM HLBM HLCM HLDM > FreeR_flag --- > hklout_ref: AutoBuild_run_1_/exptl_fobs_phases_freeR_flags.mtz > > The file exptl_fobs_phases_freeR_flags.mtz has a copy of the > (experimental) HL coefficients that were input to autobuild. The labels > HLAM HLBM etc are indeed confusing...they have the ending "M" because they > were copied by resolve and it outputs HLAM etc...but in fact they are not > density modified, just copied straight from the input data file. > > Thank you for pointing that out. > All the best, > Tom T > > > >>> Hi Tom, >>> >>> My second question was about autobuild recommending modified phases to >>> be used in further refinement. >>> This is the end of the log file printed by autobuild. See the line for >>> "Data for refinement": >>> >>> Summary of output files for Solution 3 from rebuild cycle 4 >>> >>> --- Model (PDB file) --- >>> pdb_file: AutoBuild_run_1_/cycle_best_4.pdb >>> >>> --- Refinement log file --- >>> log_refine: AutoBuild_run_1_/cycle_best_4.log_refine >>> >>> --- Model-building log file --- >>> log: AutoBuild_run_1_/cycle_best_4.log >>> >>> --- Model-map correlation log file --- >>> log_eval: AutoBuild_run_1_/cycle_best_4.log_eval >>> >>> --- 2FoFc and FoFc map coefficients from refinement 2FOFCWT PH2FOFCWT >>> FOFCWT PH >>> FOFCWT --- >>> refine_map_coeffs: AutoBuild_run_1_/cycle_best_refine_map_coeffs_4.mtz >>> >>> --- Data for refinement FP SIGFP PHIM FOMM HLAM HLBM HLCM HLDM >>> FreeR_flag --- >>> hklout_ref: AutoBuild_run_1_/exptl_fobs_phases_freeR_flags.mtz >>> >>> --- Density-modification log file --- >>> log_denmod: AutoBuild_run_1_/cycle_best_4.log_denmod >>> >>> --- Density-modified map coefficients FP PHIM FOM --- >>> hklout_denmod: AutoBuild_run_1_/cycle_best_4.mtz >>> >>> If HLAM, HLBM, HLCM and HLDM are density-modified phases, it looks like >>> that's what autobuild suggests. >>> >>> Thanks again, >>> >>> Engin >>> >>> On 8/28/09 7:07 AM, Thomas C. Terwilliger wrote: >>> >>>> Hi Engin, >>>> >>>> I'm not sure about your main question...I hope that Nat or Pavel will >>>> answer you on that. >>>> >>>> On the use of density-modified phases in refinement: AutoBuild expects >>>> experimental phases in the data file, with experimental HL coefficients, >>>> and it by default it will use those HL coefficients in refinement with >>>> an >>>> MLHL target. >>>> >>>> The phase probabilities from resolve statistical density modification >>>> are >>>> pretty accurate, and not inflated, so you could use them in refinement >>>> if >>>> you wanted to. I don't suggest it, however, because the >>>> density-modification phase information is not fully independent of the >>>> other information used in refinement (e.g., a flat solvent is implicit >>>> in >>>> your refinement already, so including that through density modification >>>> is >>>> partially redundant). >>>> >>>> ps: I hope AutoBuild doesn't recommend using density-modified phases in >>>> refinement, so if you could send me the text where it says that, I will >>>> check that out! >>>> >>>> All the best, >>>> Tom T >>>> >>>> >>>> >>>>>> Hi everybody, >>>>>> >>>>>> I had some trouble with the reflection file utility today. I've been >>>>>> trying to import Rfree-flag column from one of the mtz's to my >>>>>> combined >>>>>> mtz, and it never does. The R-free flag is always left out of the >>>>>> output >>>>>> even when I have it selected. Have you guys seen this (I'm using 147)? >>>>>> >>>>>> Another question I have is about the output of phenix.autobuild. >>>>>> Phenix.autobuild tells me to use modified phase probabilities (HLAM, >>>>>> etc.) in refinement. I am assuming this is density-modified phases. >>>>>> But >>>>>> I've always thought that this would be bad practice (possibly because >>>>>> of >>>>>> unrealistically high FOMs and possible flattening of loops, etc, but >>>>>> maybe resolve does a better job than, say DM). Any ideas on that one? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Engin >>>>>> >>>>>> -- >>>>>> Engin Özkan >>>>>> Post-doctoral Scholar >>>>>> Dept of Molecular and Cellular Physiology >>>>>> Howard Hughes Medical Institute >>>>>> Stanford University School of Medicine >>>>>> ph: (650)-498-7111 >>>>>> >>>>>> _______________________________________________ >>>>>> phenixbb mailing list >>>>>> phenixbb(a)phenix-online.org >>>>>> http://www.phenix-online.org/mailman/listinfo/phenixbb >>>>>> >>>>>> >>>>>> >>>> _______________________________________________ >>>> phenixbb mailing list >>>> phenixbb(a)phenix-online.org >>>> http://www.phenix-online.org/mailman/listinfo/phenixbb >>>> >>>> >>> >>> -- >>> Engin Özkan >>> Post-doctoral Scholar >>> Laboratory of K. Christopher Garcia >>> Howard Hughes Medical Institute >>> Dept of Molecular and Cellular Physiology >>> 279 Campus Drive, Beckman Center B173 >>> Stanford School of Medicine >>> Stanford, CA 94305 >>> ph: (650)-498-7111 >>> >>> >>> > -- Engin Özkan Post-doctoral Scholar Laboratory of K. Christopher Garcia Howard Hughes Medical Institute Dept of Molecular and Cellular Physiology 279 Campus Drive, Beckman Center B173 Stanford School of Medicine Stanford, CA 94305 ph: (650)-498-7111

16 years, 5 months

Re: [cctbxbb] bootstrap.py build on Ubuntu

by Billy Poon

Hi David, Scratch the lib64z1 and lib64z1-dev packages. Apparently, those are for i386. For 12.04, 14.04, and 16.04, libz.so is placed in /usr/lib/x86_64-linux-gnu by the zlib1g-dev package. It looks like Ubuntu libraries are now placed in a directory named by architecture to better support multiple architectures on the same machine. I updated install_base_packages to supply that directory for building PIL. This is specific to x86_64, so this won't work on 32-bit Ubuntu. But if you want a 32-bit Ubuntu build, installing lib64z1-dev should work. Let me know if you have any more issues. Thanks! -- 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 Tue, Jun 14, 2016 at 11:29 AM, David Waterman <dgwaterman(a)gmail.com> wrote: > 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 >> > > _______________________________________________ > cctbxbb mailing list > cctbxbb(a)phenix-online.org > http://phenix-online.org/mailman/listinfo/cctbxbb > >

9 years, 7 months

Re: [phenixbb] Using LigandFit to identify unknown density

by Maia Cherney

Thanks, Pavel, now I got it. Maia Pavel Afonine wrote: > Hi Maia, > > phenix.refine refines occupancies during occupancy refinement, it > refines B-factors during B-factor refinement and it refines > coordinates during coordinate refinement. The B-factor restraints are > applied at B-factor refinement step. phenix.refine iterates these > steps as many times as large the main.number_of_macro_cycles parameter > is (3, by default). Obviously, no B-factor are restraints applied if > you refine occupancies only. > > Yes, what Peter mentioned actually happens during refinement (if > B-factor refinement is enabled). That's what the B-factor restraints > do in general. > > Pavel. > > > On 1/27/10 3:28 PM, Maia Cherney wrote: >> Hi Pavel, Peter, >> >> Thank you for your reply. My question is if the phenix.refine >> actually uses the B-factor restraints in the occupancy refinement. I >> did not give any restraints, so it should happen automatically? I >> like the idea that Peter mentioned that the restraints should make B >> -factors similar to surrounding molecules. Again, my question is does >> phenix.refine actually uses this approach? >> >> Maia >> >> >> >> Pavel Afonine wrote: >>> Hi Maia, >>> >>> first, I agree with Peter - the B-factor restraints should help, >>> indeed. >>> >>> Second, I think we discussed this subject already on November 25, 2009: >>> >>> Subject: Re: [phenixbb] occupancy refinement >>> Date: 11/25/09 7:38 AM >>> >>> and I believe I didn't change my mind about it since that. I'm >>> appending that email conversation to the bottom of this email. >>> >>> Overall, if you get good 2mFo-DFc map and clear residual mFo-DFc >>> map, and ligand's B-factors are similar or slightly larger than >>> those of surrounding atoms, and refined occupancy looks reasonable, >>> then I think you are fine. >>> >>> Pavel. >>> >>> >>> On 1/27/10 2:05 PM, Maia Cherney wrote: >>>> Hi Pavel, >>>> >>>> I have six ligands at partial occupacies in my structure. >>>> Simultaneous refinement of occupancy and B factors in phenix gives >>>> a value of 0.7 for the ligand occupancy that looks reasonable. >>>> How does phenix can perform such a refinement given the occupancies >>>> and B factors are highly correlated? Indeed, you can >>>> increase/decrease the ligand occupancies while simultaneously >>>> increacing/decreasing their B factors without changing the R factor >>>> value. What criteria does phenix use in such a refinement if R >>>> factor does not tell much? >>>> >>>> Maia >>> >>> ******* COPY (11/25/09)************ >>> >>> >>> >>> On 11/25/09 7:38 AM, Maia Cherney wrote: >>>> Hi Pavel, >>>> >>>> It looks like all different refined occupancies starting from >>>> different initial occupancies converged to the same number upon >>>> going through very many cycles of refinement. >>>> >>>> Maia >>>> >>>> >>>> Pavel Afonine wrote: >>>> >>>>> Hi Maia, >>>>> >>>>> the atom parameters, such as occupancy, B-factor and even position >>>>> are interdependent in some sense. That is, if you have somewhat >>>>> incorrect occupancy, that B-factor refinement may compensate for >>>>> it; if you misplaced an atom the refinement of its occupancy >>>>> or/and B-factor will compensate for this. Note in all the above >>>>> cases the 2mFo-DFc and mFo-DFc maps will appear almost identical, >>>>> as well as R-factors. >>>>> >>>>> So, I think your goal of finding a "true" occupancy is hardly >>>>> achievable. >>>>> >>>>> Although, I think you can approach it by doing very many >>>>> refinements (say, several hundreds) (where you refine occupancies, >>>>> B-factors and coordinates) each refinement starting with different >>>>> occupancy and B-factor values, and make sure that each refinement >>>>> converges. Then select a subset of refined structures with similar >>>>> and low R-factors (discard those cases where refinement got stuck >>>>> for whatever reason and R-factors are higher) (and probably >>>>> similar looking 2mFo-DFc and mFo-DFc maps in the region of >>>>> interest). Then see where the refined occupancies and B-factors >>>>> are clustering, and the averaged values will probably give you an >>>>> approximate values for occupancy and B. I did not try this myself >>>>> but always wanted to. >>>>> >>>>> If you have a structure consisting of 9 carbons and one gold atom, >>>>> then I would expect that the "second digit" in gold's occupancy >>>>> would matter. However, if we speak about dozen of ligand atoms >>>>> (which are probably a combination of C,N,O) out of a few thousands >>>>> of atoms of the whole structure, then I would not expect the >>>>> "second digit" to be visibly important. >>>>> >>>>> Pavel. >>>>> >>>>> >>>>> On 11/24/09 8:08 PM, chern wrote: >>>>> >>>>>> Thank you Kendall and Pavel for your responces. >>>>>> I really want to determine the occupancy of my ligand. I saw one >>>>>> suggestion to try different refinements with different >>>>>> occupancies and compare the B-factors. >>>>>> The occupancy with a B-factor that is at the level with the >>>>>> average protein B-factors, is a "true" occupancy. >>>>>> I also noticed the dependence of the ligand occupancy on the >>>>>> initial occupancy. I saw the difference of 10 to 15%, that is why >>>>>> I am wondering if the second digit after the decimal point makes >>>>>> any sence. >>>>>> Maia >>>>>> >>>>>> ----- Original Message ----- >>>>>> *From:* Kendall Nettles <mailto:[email protected]> >>>>>> *To:* PHENIX user mailing list >>>>>> <mailto:[email protected]> >>>>>> *Sent:* Tuesday, November 24, 2009 8:22 PM >>>>>> *Subject:* Re: [phenixbb] occupancy refinement >>>>>> >>>>>> Hi Maia, >>>>>> I think the criteria for occupancy refinement of ligands is >>>>>> similar to a decision to add an alt conformation for an amino >>>>>> acid. I don’t refine occupancy of a ligand unless the difference >>>>>> map indicates that we have to. Sometimes part of the igand >>>>>> may be >>>>>> conformationally mobile and show poor density, but I personally >>>>>> don’t think this justifies occupancy refinement without evidence >>>>>> from the difference map. I agree with Pavel that you shouldn’t >>>>>> expect much change in overall statistics, unless the ligand has >>>>>> very low occupancy., or you have a very small protein. We >>>>>> typically see 0.5-1% difference in R factors from refining with >>>>>> ligand versus without for nuclear receptor igand binding domains >>>>>> of about 250 amino acids, and we see very small differences from >>>>>> occupancy refinement of the ligands. >>>>>> >>>>>> Regarding the error, I have noticed differences of 10% percent >>>>>> occupancy depending on what you set the starting occupancy >>>>>> before >>>>>> refinement. That is, if the starting occupancy starts at 1, you >>>>>> might end up with 50%, but if you start it at 0.01, you might >>>>>> get >>>>>> 40%. I don’t have the expertise to explain why this is, but I >>>>>> also don’t think it is necessarily important. I think it is more >>>>>> important to convince yourself that the ligand binds how you >>>>>> think it does. With steroid receptors, the ligand is usually >>>>>> planer, and tethered by hydrogen bonds on two ends. That leaves >>>>>> us with with four possible poses, so if in doubt, we will >>>>>> dock in >>>>>> the ligand in all of the four orientations and refine. So >>>>>> far, we >>>>>> have had only one of several dozen structures where the ligand >>>>>> orientation was not obvious after this procedure. I worry >>>>>> about a >>>>>> letter to the editor suggesting that the electron density for >>>>>> the >>>>>> ligand doesn’t support the conclusions of the paper, not whether >>>>>> the occupancy is 40% versus 50%. >>>>>> >>>>>> You might also want to consider looking at several maps, such as >>>>>> the simple or simulated annealing composite omit maps. These can >>>>>> be noisy, so also try the kicked maps ( >>>>>> >>>>>> http://www.phenix-online.org/pipermail/phenixbb/2009-September/002573.html), >>>>>> >>>>>> >>>>>> <http://www.phenix-online.org/pipermail/phenixbb/2009-September/002573.html%…,> >>>>>> >>>>>> which I have become a big fan of. >>>>>> >>>>>> Regards, >>>>>> Kendall Nettles >>>>>> >>>>>> On 11/24/09 3:07 PM, "chern(a)ualberta.ca" <chern(a)ualberta.ca> >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> I am wondering what is the criteria for occupancy >>>>>> refinement of >>>>>> ligands. I noticed that R factors change very little, but >>>>>> the >>>>>> ligand >>>>>> B-factors change significantly . On the other hand, the >>>>>> occupancy is >>>>>> refined to the second digit after the decimal point. How can >>>>>> I find >>>>>> out the error for the refined occupancy of ligands? >>>>>> >>>>>> Maia >>>>>> >>> >>> _______________________________________________ >>> 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 > >

16 years

Re: [cctbxbb] Git status update

by Aaron Brewster

Hi Markus, Indeed, dials.lbl.gov is built off of the same sources. I was more concerned about cctbx.sourceforge.net. We can look into that on our end. As for the repositories, there are licensing issues with the way you have things set up and we would like to examine if the code duplication that is occurring can be avoided. We (Billy and I) will make up a list of dependencies and their licenses and how we think they should be hosted. Should we do a brief skype call over the next couple days? Thanks, -Aaron On Tue, Nov 1, 2016 at 2:04 AM, <markus.gerstel(a)diamond.ac.uk> wrote: > Hi Aaron, > > > > If you could send me your gmail addresses and I’ll share the doc. > > > > Regarding your questions: > > 1. Syncing the repositories is done using subgit and I run this > currently 4 times a day. > > 2. Yes, the repositories are copies of what we are distributing. > No, I do not think we should remove them, rather we should if at all > possible extend them by adding their development history and actually point > to them. Currently no changes can be made to any of those packages, and – > from a distribution point of view, worse – nobody knows if and when those > packages do change. What I therefore do for dials releases is a) download > all the packages, b) unpack them into the respective repositories and c) > see if any changes were made before I d) tag the repository for release. As > you can see this has a massive time impact and is part of the reason why > releases are currently more painful than they have to be. Therefore if the > packages were recently updated this is not a problem since nobody currently > refers to them outside the stable releases. > > 3. Isn’t dials.lbl.gov already running off the > https://github.com/dials/dials.github.io repository? I am sure we can > have something similar for the cctbx websites. We already generate > http://cctbx.github.io/ but I don’t atm know where cctbx.sourceforge.net > comes from. > > > > -Markus > > > > Dr Markus Gerstel MBCS > > Postdoctoral Research Associate > > Tel: +44 1235 778698 > > > > Diamond Light Source Ltd. > > Diamond House > > Harwell Science & Innovation Campus > > Didcot > > Oxfordshire > > OX11 0DE > > > > *From:* cctbxbb-bounces(a)phenix-online.org [mailto:cctbxbb-bounces@ > phenix-online.org] *On Behalf Of *Aaron Brewster > *Sent:* 28 October 2016 23:48 > > *To:* cctbx mailing list > *Subject:* Re: [cctbxbb] Git status update > > > > Hi Markus, > > > > Billy, Nigel and I worked through the plan you originally sent out (linked > at the top of this email thread). We've added a couple questions as > comments in the document (expounded on below). Also, could you make the > document writeable by Billy, Nigel and I? We want to assign some of the > tasks listed. > > > > Here are the questions: > > - How is the repository at https://github.com/cctbx/cctbx being synced > with the SVN version? (This is just my own curiosity :) > - We think the non-cctbx repositories there that are copies (clipper, > boost, annlib, etc.) of the bundles distributed alongside cctbx need to be > removed from the git cctbx organization as they are duplications of what we > are currently distributing. You say they are there so you can do tagging > with the dials releases, but if Billy has updated the versions at LBL, then > wouldn't these versions hosted by git already be out of date? Which would > affect the dials stable releases? > - We need to think about how websites such as dials.lbl.gov or > cctbx.sourceforge.net will be affected by moving to git. Probably > it's just updating links or moving html files? > > Thanks, > > -Aaron > > > > On Tue, Aug 23, 2016 at 6:32 AM, <markus.gerstel(a)diamond.ac.uk> wrote: > > Hi Marcin. > > Currently I would say there is no plan. I do not have the history of the > projects, so I could not do anything about that. I also don't use any of > those repositories, so can't really comment on their status or future. I > created the repositories only so I can tag versions for the DIALS releases, > otherwise someone changing the downloadable archive would affect stable > releases. > > -Markus > > Dr Markus Gerstel MBCS > Postdoctoral Research Associate > Tel: +44 1235 778698 > > Diamond Light Source Ltd. > Diamond House > Harwell Science & Innovation Campus > Didcot > Oxfordshire > OX11 0DE > > > -----Original Message----- > From: cctbxbb-bounces(a)phenix-online.org [mailto:cctbxbb-bounces@ > phenix-online.org] On Behalf Of Marcin Wojdyr > Sent: 23 August 2016 14:26 > To: cctbx mailing list > Subject: Re: [cctbxbb] Git status update > > Hi Markus, > what's the plan for the repositories that are currently imported as "copy > of LBL archive" (without history). > I guess the plan is to preserve the history - but will they be merged or > added as submodule/subtree of the main cctbx repository? > > Marcin > _______________________________________________ > 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 > >

9 years, 3 months

Re: [cctbxbb] Git status update

by markus.gerstel＠diamond.ac.uk

Hi Aaron, Yes. Please give a shout when ready. -Markus (Side note: If it’s the same to you I would prefer a hangout call because I can’t remember my Skype account details. Otherwise I’ll dig them up or get a new account.) Dr Markus Gerstel MBCS Postdoctoral Research Associate Tel: +44 1235 778698 Diamond Light Source Ltd. Diamond House Harwell Science & Innovation Campus Didcot Oxfordshire OX11 0DE From: cctbxbb-bounces(a)phenix-online.org [mailto:[email protected]] On Behalf Of Aaron Brewster Sent: 01 November 2016 17:51 To: cctbx mailing list Subject: Re: [cctbxbb] Git status update Hi Markus, Indeed, dials.lbl.gov<http://dials.lbl.gov> is built off of the same sources. I was more concerned about cctbx.sourceforge.net<http://cctbx.sourceforge.net>. We can look into that on our end. As for the repositories, there are licensing issues with the way you have things set up and we would like to examine if the code duplication that is occurring can be avoided. We (Billy and I) will make up a list of dependencies and their licenses and how we think they should be hosted. Should we do a brief skype call over the next couple days? Thanks, -Aaron On Tue, Nov 1, 2016 at 2:04 AM, <markus.gerstel(a)diamond.ac.uk<mailto:[email protected]>> wrote: Hi Aaron, If you could send me your gmail addresses and I’ll share the doc. Regarding your questions: 1. Syncing the repositories is done using subgit and I run this currently 4 times a day. 2. Yes, the repositories are copies of what we are distributing. No, I do not think we should remove them, rather we should if at all possible extend them by adding their development history and actually point to them. Currently no changes can be made to any of those packages, and – from a distribution point of view, worse – nobody knows if and when those packages do change. What I therefore do for dials releases is a) download all the packages, b) unpack them into the respective repositories and c) see if any changes were made before I d) tag the repository for release. As you can see this has a massive time impact and is part of the reason why releases are currently more painful than they have to be. Therefore if the packages were recently updated this is not a problem since nobody currently refers to them outside the stable releases. 3. Isn’t dials.lbl.gov<http://dials.lbl.gov> already running off the https://github.com/dials/dials.github.io repository? I am sure we can have something similar for the cctbx websites. We already generate http://cctbx.github.io/ but I don’t atm know where cctbx.sourceforge.net<http://cctbx.sourceforge.net> comes from. -Markus Dr Markus Gerstel MBCS Postdoctoral Research Associate Tel: +44 1235 778698<tel:%2B44%201235%20778698> Diamond Light Source Ltd. Diamond House Harwell Science & Innovation Campus Didcot Oxfordshire OX11 0DE From: cctbxbb-bounces(a)phenix-online.org<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Aaron Brewster Sent: 28 October 2016 23:48 To: cctbx mailing list Subject: Re: [cctbxbb] Git status update Hi Markus, Billy, Nigel and I worked through the plan you originally sent out (linked at the top of this email thread). We've added a couple questions as comments in the document (expounded on below). Also, could you make the document writeable by Billy, Nigel and I? We want to assign some of the tasks listed. Here are the questions: * How is the repository at https://github.com/cctbx/cctbx being synced with the SVN version? (This is just my own curiosity :) * We think the non-cctbx repositories there that are copies (clipper, boost, annlib, etc.) of the bundles distributed alongside cctbx need to be removed from the git cctbx organization as they are duplications of what we are currently distributing. You say they are there so you can do tagging with the dials releases, but if Billy has updated the versions at LBL, then wouldn't these versions hosted by git already be out of date? Which would affect the dials stable releases? * We need to think about how websites such as dials.lbl.gov<http://dials.lbl.gov> or cctbx.sourceforge.net<http://cctbx.sourceforge.net> will be affected by moving to git. Probably it's just updating links or moving html files? Thanks, -Aaron On Tue, Aug 23, 2016 at 6:32 AM, <markus.gerstel(a)diamond.ac.uk<mailto:[email protected]>> wrote: Hi Marcin. Currently I would say there is no plan. I do not have the history of the projects, so I could not do anything about that. I also don't use any of those repositories, so can't really comment on their status or future. I created the repositories only so I can tag versions for the DIALS releases, otherwise someone changing the downloadable archive would affect stable releases. -Markus Dr Markus Gerstel MBCS Postdoctoral Research Associate Tel: +44 1235 778698<tel:%2B44%201235%20778698> Diamond Light Source Ltd. Diamond House Harwell Science & Innovation Campus Didcot Oxfordshire OX11 0DE -----Original Message----- From: cctbxbb-bounces(a)phenix-online.org<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Marcin Wojdyr Sent: 23 August 2016 14:26 To: cctbx mailing list Subject: Re: [cctbxbb] Git status update Hi Markus, what's the plan for the repositories that are currently imported as "copy of LBL archive" (without history). I guess the plan is to preserve the history - but will they be merged or added as submodule/subtree of the main cctbx repository? Marcin _______________________________________________ cctbxbb mailing list cctbxbb(a)phenix-online.org<mailto:[email protected]> 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<mailto:[email protected]> 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

9 years, 3 months

Re: [cctbxbb] Making branches by accident

by Nigel Moriarty

Thanks for the clarifications. 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 On Thu, Dec 8, 2016 at 10:12 AM, <markus.gerstel(a)diamond.ac.uk> wrote: > Hi Nigel, > > The log (and the blame log) should show the times of the commit, > regardless of whether you merge the branch into master or rebase your > branch onto master at the end. > > When you rebase your commits you can also get the rebase time. eg. for > your last rebased commit: > $ git show 4fa192b0 --format=fuller > The author+date pair is the person who originally wrote the code (rather: > who made the original commit), the commit+date pair is set by whoever > rebased/cherry-picked/etc. it last. > > -Markus > > > PS: Just to clarify - if you deliberately use branches to do isolated > feature development, merging is absolutely fine. > > ________________________________ > From: cctbxbb-bounces(a)phenix-online.org [cctbxbb-bounces(a)phenix-online.org] > on behalf of Nigel Moriarty [nwmoriarty(a)lbl.gov] > Sent: Thursday, December 08, 2016 17:41 > To: cctbx mailing list > Subject: Re: [cctbxbb] Making branches by accident > > Markus > > I was a non-rebaser but I have set it to true on my second machine. So my > question is regardind branches. I have made a branch, made some changes and > merged the master into the branch. I will make some more changes during > testing. I assume that I merge into the master at some point. Will the > commits appear in the log based on the time of the merge or the time I > committed in the branch? > > 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<http://CCI.LBL.gov> > > On Thu, Dec 8, 2016 at 12:14 AM, <markus.gerstel(a)diamond.ac.uk<mailto: > markus.gerstel(a)diamond.ac.uk>> wrote: > I use a custom prompt so I can see what is going on when I am in a git > repository folder. > > This is the code one could add to their ~/.bashrc: > https://gist.github.com/Anthchirp/dfc9a4382f8dfc9a97fe1039c9e6789a > > This is what it looks like: > https://postimg.org/image/8c9h72qwd/ > > This is what happens in the image: > * yellow brackets indicate you are in git territory, and contain the > current branch name > * red branch name = uncommitted changes in repository > * positive number: number of commits the local repository is ahead of the > remote repository > * the 'git pull' command causes an implicit merge commit, which I undo > with the next command > * negative number: number of commits the local repository is behind the > remote repository > * both negative and positive number: branches have diverged > > Maybe someone finds it useful. > > -Markus > > > ________________________________ > From: cctbxbb-bounces(a)phenix-online.org<mailto:cctbxbb-bounces@ > phenix-online.org> [cctbxbb-bounces(a)phenix-online.org<mailto:cctbxbb- > bounces(a)phenix-online.org>] on behalf of Pavel Afonine [pafonine(a)lbl.gov > <mailto:[email protected]>] > Sent: Wednesday, December 07, 2016 18:24 > To: cctbxbb(a)phenix-online.org<mailto:[email protected]> > Subject: Re: [cctbxbb] Making branches by accident > > This happened to me a few times now, and just double-checked that my > .gitconfig contains "rebase = true". Let's see if it happens again.. > Pavel > > On 12/7/16 00:02, Graeme.Winter(a)diamond.ac.uk<mailto: > Graeme.Winter(a)diamond.ac.uk><mailto:[email protected]<mailto: > Graeme.Winter(a)diamond.ac.uk>> wrote: > Morning all > > I am seeing a certain amount of “Merge branch 'master' of github.com: > cctbx/cctbx_project” coming through on the commits – this usually means > you did not do a git pull –rebase before the git push. This can be set to > the default by using the spell Markus sent out > > git config --global pull.rebase true > > This will need to be done on each machine you push from, else getting the > habit of doing a git pull –rebase before push is a good one. > > We have had this on and off with DIALS but it tends to pass easily enough. > > What bad happens? Nothing really but the history becomes confusing… > > So: may be worth checking that you have the pull.rebase thing set? > > Cheerio Graeme > > > > -- > > This e-mail and any attachments may contain confidential, copyright and or > privileged material, and are for the use of the intended addressee only. If > you are not the intended addressee or an authorised recipient of the > addressee please notify us of receipt by returning the e-mail and do not > use, copy, retain, distribute or disclose the information in or attached to > the e-mail. > Any opinions expressed within this e-mail are those of the individual and > not necessarily of Diamond Light Source Ltd. > Diamond Light Source Ltd. cannot guarantee that this e-mail or any > attachments are free from viruses and we cannot accept liability for any > damage which you may sustain as a result of software viruses which may be > transmitted in or with the message. > Diamond Light Source Limited (company no. 4375679). Registered in England > and Wales with its registered office at Diamond House, Harwell Science and > Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom > > > > > _______________________________________________ > cctbxbb mailing list > cctbxbb(a)phenix-online.org<mailto:[email protected]><mailto: > cctbxbb(a)phenix-online.org<mailto:[email protected]>> > 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 > > > _______________________________________________ > cctbxbb mailing list > cctbxbb(a)phenix-online.org > http://phenix-online.org/mailman/listinfo/cctbxbb >

9 years, 2 months

Re: [cctbxbb] Making branches by accident

by Billy Poon

Also, what is the minimum version of git that we should be using? I have git 2.9.3 on my Mac (10.12.1), but we have git 1.7.1 on our shared Linux development machine (CentOS 6.7). -- 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, Dec 8, 2016 at 10:12 AM, <markus.gerstel(a)diamond.ac.uk> wrote: > Hi Nigel, > > The log (and the blame log) should show the times of the commit, > regardless of whether you merge the branch into master or rebase your > branch onto master at the end. > > When you rebase your commits you can also get the rebase time. eg. for > your last rebased commit: > $ git show 4fa192b0 --format=fuller > The author+date pair is the person who originally wrote the code (rather: > who made the original commit), the commit+date pair is set by whoever > rebased/cherry-picked/etc. it last. > > -Markus > > > PS: Just to clarify - if you deliberately use branches to do isolated > feature development, merging is absolutely fine. > > ________________________________ > From: cctbxbb-bounces(a)phenix-online.org [cctbxbb-bounces(a)phenix-online.org] > on behalf of Nigel Moriarty [nwmoriarty(a)lbl.gov] > Sent: Thursday, December 08, 2016 17:41 > To: cctbx mailing list > Subject: Re: [cctbxbb] Making branches by accident > > Markus > > I was a non-rebaser but I have set it to true on my second machine. So my > question is regardind branches. I have made a branch, made some changes and > merged the master into the branch. I will make some more changes during > testing. I assume that I merge into the master at some point. Will the > commits appear in the log based on the time of the merge or the time I > committed in the branch? > > 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<http://CCI.LBL.gov> > > On Thu, Dec 8, 2016 at 12:14 AM, <markus.gerstel(a)diamond.ac.uk<mailto: > markus.gerstel(a)diamond.ac.uk>> wrote: > I use a custom prompt so I can see what is going on when I am in a git > repository folder. > > This is the code one could add to their ~/.bashrc: > https://gist.github.com/Anthchirp/dfc9a4382f8dfc9a97fe1039c9e6789a > > This is what it looks like: > https://postimg.org/image/8c9h72qwd/ > > This is what happens in the image: > * yellow brackets indicate you are in git territory, and contain the > current branch name > * red branch name = uncommitted changes in repository > * positive number: number of commits the local repository is ahead of the > remote repository > * the 'git pull' command causes an implicit merge commit, which I undo > with the next command > * negative number: number of commits the local repository is behind the > remote repository > * both negative and positive number: branches have diverged > > Maybe someone finds it useful. > > -Markus > > > ________________________________ > From: cctbxbb-bounces(a)phenix-online.org<mailto:cctbxbb-bounces@ > phenix-online.org> [cctbxbb-bounces(a)phenix-online.org<mailto:cctbxbb- > bounces(a)phenix-online.org>] on behalf of Pavel Afonine [pafonine(a)lbl.gov > <mailto:[email protected]>] > Sent: Wednesday, December 07, 2016 18:24 > To: cctbxbb(a)phenix-online.org<mailto:[email protected]> > Subject: Re: [cctbxbb] Making branches by accident > > This happened to me a few times now, and just double-checked that my > .gitconfig contains "rebase = true". Let's see if it happens again.. > Pavel > > On 12/7/16 00:02, Graeme.Winter(a)diamond.ac.uk<mailto: > Graeme.Winter(a)diamond.ac.uk><mailto:[email protected]<mailto: > Graeme.Winter(a)diamond.ac.uk>> wrote: > Morning all > > I am seeing a certain amount of “Merge branch 'master' of github.com: > cctbx/cctbx_project” coming through on the commits – this usually means > you did not do a git pull –rebase before the git push. This can be set to > the default by using the spell Markus sent out > > git config --global pull.rebase true > > This will need to be done on each machine you push from, else getting the > habit of doing a git pull –rebase before push is a good one. > > We have had this on and off with DIALS but it tends to pass easily enough. > > What bad happens? Nothing really but the history becomes confusing… > > So: may be worth checking that you have the pull.rebase thing set? > > Cheerio Graeme > > > > -- > > This e-mail and any attachments may contain confidential, copyright and or > privileged material, and are for the use of the intended addressee only. If > you are not the intended addressee or an authorised recipient of the > addressee please notify us of receipt by returning the e-mail and do not > use, copy, retain, distribute or disclose the information in or attached to > the e-mail. > Any opinions expressed within this e-mail are those of the individual and > not necessarily of Diamond Light Source Ltd. > Diamond Light Source Ltd. cannot guarantee that this e-mail or any > attachments are free from viruses and we cannot accept liability for any > damage which you may sustain as a result of software viruses which may be > transmitted in or with the message. > Diamond Light Source Limited (company no. 4375679). Registered in England > and Wales with its registered office at Diamond House, Harwell Science and > Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom > > > > > _______________________________________________ > cctbxbb mailing list > cctbxbb(a)phenix-online.org<mailto:[email protected]><mailto: > cctbxbb(a)phenix-online.org<mailto:[email protected]>> > 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 > > > _______________________________________________ > cctbxbb mailing list > cctbxbb(a)phenix-online.org > http://phenix-online.org/mailman/listinfo/cctbxbb >

9 years, 2 months

Search results for query "look through"