Search results for query "look through"
- 520 messages

[phenixbb] help with phenix.ligand_identification
by Edward A. Berry
I'm having some problems using ligand_identification.
I would like to restrict the search to a specific density peak, even if it is not the highest unmodeled peak or the highest Fo-Fc peak in the map.
I tried using options:
search_center="67.5 18.3 11.8"
or
ligand_near_res=S2063,
Will the search be restricted to that region, or if a particuar ligand doesn't fit that blob,
will it search through the rest of the map? If it is restricted, in what radius?
Is this radius affected by the "search_dist" or "local_search" parameters?
and local_search = True is default?
Is there a threshold level for density level, below which building a ligand in a blob will not be attempted?
I've tried with both search_center= and ligand_near_res=, and something gets
built far away from that site. But there were errors, so I may have something wrong:
phenix.ligand_identification mtz_in=sqr2803or13_031.mtz input_labels="2FOFCWT PH2FOFCWT" \
model=sqr2803or13_031.pdb ligand_near_res=S2063 nproc=2
After preparing the ligand library, then:
Running LigandFit process 1...
Number of atoms in ligand suc.pdb is 23
Running job sequence 1, ligand 2, in /tb/sb/usr20c/berry/ref/sqrdep/sqr2803dep2/phenix2/Temp_1...
Evaluating all ligands in ligand-lib now...and placing fittedligand ### in resolve_ligand_###.pdb
Number of atoms in ligand 2pe.pdb is 28
Running job sequence 0, ligand 1, in /tb/sb/usr20c/berry/ref/sqrdep/sqr2803dep2/phenix2/Temp_0...
Process Process-2:
Traceback (most recent call last):
File "/sw/lnx/phenix-1.12-2829/base/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
self.run()
File "/sw/lnx/phenix-1.12-2829/base/lib/python2.7/multiprocessing/process.py", line 114, in run
self._target(*self._args, **self._kwargs)
File "/sw/lnx/phenix-1.12-2829/build/../modules/phenix/phenix/command_line/ligand_identification.py", line 1382, in RunLigandFit
shutil.rmtree(ligandfit_dir)
File "/sw/lnx/phenix-1.12-2829/base/lib/python2.7/shutil.py", line 247, in rmtree
rmtree(fullname, ignore_errors, onerror)
File "/sw/lnx/phenix-1.12-2829/base/lib/python2.7/shutil.py", line 256, in rmtree
onerror(os.rmdir, path, sys.exc_info())
File "/sw/lnx/phenix-1.12-2829/base/lib/python2.7/shutil.py", line 254, in rmtree
os.rmdir(path)
OSError: [Errno 39] Directory not empty: '/tb/sb/usr20c/berry/ref/sqrdep/sqr2803dep2/phenix2/Temp_1/LigandFit_run_1_/TEMP0'
Process Process-1:
Traceback (most recent call last):
File "/sw/lnx/phenix-1.12-2829/base/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
self.run()
File "/sw/lnx/phenix-1.12-2829/base/lib/python2.7/multiprocessing/process.py", line 114, in run
self._target(*self._args, **self._kwargs)
File "/sw/lnx/phenix-1.12-2829/build/../modules/phenix/phenix/command_line/ligand_identification.py", line 1382, in RunLigandFit
shutil.rmtree(ligandfit_dir)
File "/sw/lnx/phenix-1.12-2829/base/lib/python2.7/shutil.py", line 247, in rmtree
rmtree(fullname, ignore_errors, onerror)
File "/sw/lnx/phenix-1.12-2829/base/lib/python2.7/shutil.py", line 256, in rmtree
onerror(os.rmdir, path, sys.exc_info())
File "/sw/lnx/phenix-1.12-2829/base/lib/python2.7/shutil.py", line 254, in rmtree
os.rmdir(path)
OSError: [Errno 39] Directory not empty: '/tb/sb/usr20c/berry/ref/sqrdep/sqr2803dep2/phenix2/Temp_0/LigandFit_run_1_/TEMP0'
Evaluating LigandFit results ...
The run continues, but it does not test any more ligands after those first two but goes on to evaluate the results.
With nproc = 1, only 1 ligand gets tested. In all cases the first ligand in the library (2PE.pdb) is evaluated as the best.
It is placed in density, but density that has already been built out with (and looks more like) a string of water molecules.
And this is far from the selected residue or coordinates specified.
The directory that raised the error when attempting to be deleted does eventually get removed: after the run there is no TEMP_N in the parent directory.
Any suggestions would be welcome.
Ed
P.S.
- running with .eff file:
['--show_defaults']
ligand_identification {
mtz_in = sqr2803or13_031.mtz
mtz_type = *F diffmap
model = sqr2803or13_031.pdb
ncpu = 1
n_indiv_tries_min = 30
n_indiv_tries_max = 300
n_group_search = 4
search_dist = 10
local_search = True
search_center = "67.5 18.3 11.8"
# ligand_near_res = S2063
verbose = False
debug = False
use_ligandfit = True
search_mode = *default LigandFit
temp_dir = Auto
dry_run = False
# number_of_ligands = 1
cc_min = 0.75
open_in_coot = False
non_bonded = True
keep_all_files = False
# cif_def_file_list =
real_space_target_weight = 10
# job_title = None
ligandfit {
}
}
gives:
[['2pe.pdb', 'suc.pdb', . . . 'upl.pdb']]
/tb/sb/usr20c/berry/ref/sqrdep/sqr2803dep2/phenix2
*******************************************************************************
Sorry, the protein model file None does not seem to exist?
*******************************************************************************
Running LigandFit process 0...
Process Process-1:
Traceback (most recent call last):
File "/sw/lnx/phenix-1.12-2829/base/lib/python2.7/multiprocessing/process.py", line 258, in _bootstrap
self.run()
File "/sw/lnx/phenix-1.12-2829/base/lib/python2.7/multiprocessing/process.py", line 114, in run
self._target(*self._args, **self._kwargs)
File "/sw/lnx/phenix-1.12-2829/build/../modules/phenix/phenix/command_line/ligand_identification.py", line 1122, in RunLigandFit
shutil.copyfile(mtz_in,data_local)
File "/sw/lnx/phenix-1.12-2829/base/lib/python2.7/shutil.py", line 82, in copyfile
with open(src, 'rb') as fsrc:
IOError: [Errno 2] No such file or directory: 'None'
Evaluating LigandFit results ...
Lig_seq Placed/total cc_all cc cc_adj score Code HBscore
Cannot find overall_ligand_scores.log0. This could mean that none of that (sub)set of ligand fitted well.
None of the ligand fit the difference desity well enough. Please try the following --
1) if you input a custom library, try to use the default library (no extra keywords needed), or
2) if you used the default library already, ususlly this means that the density is too small (> 6 atome or more is needed.)
Exiting ......
No good ligand found.
7 years, 9 months

Re: [cctbxbb] some thoughts on cctbx and pip
by Graeme.Winter@Diamond.ac.uk
Without discussing the merits of this or whether we _choose_ to make the move to supporting PIP, I am certain it would be _possible_ - many other packages make dispatcher scripts when you pip install them e.g.
Silver-Surfer rescale_f2 :) $ which black; cat $(which black)
/Library/Frameworks/Python.framework/Versions/3.6/bin/black
#!/Library/Frameworks/Python.framework/Versions/3.6/bin/python3.6
# -*- coding: utf-8 -*-
import re
import sys
from black import main
if __name__ == '__main__':
sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
sys.exit(main())
So we _could_ work around the absence of LIBTBX_BUILD etc. in the system. Whether or not we elect to do the work is a different question, and it seems clear that here are very mixed opinions on this.
Best wishes Graeme
On 23 Aug 2019, at 01:21, Luc Bourhis <luc_j_bourhis(a)mac.com<mailto:[email protected]>> 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…). 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/). For example, numpy is built according to this standard (see 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/). 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
_______________________________________________
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
--
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
5 years, 10 months

Re: [cctbxbb] Is there a schedule for the python3 migration or can cctbx.python already be built to be/use a python3 interpreter?
by Billy Poon
Hi Jan,
Good to know about the noexec /tmp error. I'll have to add a $TMPDIR
environment variable since it looks like mounting /tmp as noexec is
becoming more common.
Another note is that the dependencies are updated about every 6 months. The
versions and builds of the conda packages used for dependencies are
explicitly tracked with their URLs and hashes to ensure reproducibility of
the build environment. You can delete the "conda_base" directory and the
bootstrap.py command (run in a shell before sourcing any of the "setpaths"
files) will recreate it.
Let us know if you have any other 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
Fax: (510) 486-5909
Web: https://phenix-online.org
On Fri, Jul 9, 2021 at 3:00 PM Jan M. Simons <marten(a)ifk.rwth-aachen.de>
wrote:
> Am 09.07.21 um 15:11 schrieb Billy Poon:
> > Hi Jan,
> >
> > Do you need to build cctbx from scratch? The cctbx has been available
> > for Python 3 for a while now, but is using conda packages
> > (https://docs.conda.io/en/latest/ <https://docs.conda.io/en/latest/>)
> > for managing dependencies. Building the dependencies from scratch for
> > multiple versions of Python 3 for multiple platforms was getting too
> > complicated.
> >
> > You can install cctbx as a conda package for Python 3.6 through 3.9 with
> > support for macOS (Intel and Apple Silicon), linux, and Windows.
> > Instructions can be found here
> > (https://github.com/cctbx/cctbx_project#installation
> > <https://github.com/cctbx/cctbx_project#installation>), but essentially
> > it is just
> >
> > conda install -c conda-forge cctbx-base
> >
> > to get it into an existing environment. The smtbx module will be
> > available, but not fast_linalg yet.
> >
> > Note that with a conda environment, you do not need to run any of the
> > "setpaths" scripts to set it up. Just activate the environment and cctbx
> > will be available in python.
> >
> > There are also nightly builds of the conda packages on a separate
> > channel (https://github.com/cctbx/cctbx_project#nightly-builds
> > <https://github.com/cctbx/cctbx_project#nightly-builds>). The command
> > above becomes
> >
> > conda install -c cctbx-nightly -c conda-forge cctbx-base
> >
> > You can also build cctbx with Python 3 using conda packages as
> > dependencies
> > (https://github.com/cctbx/cctbx_project#building-a-development-version
> > <https://github.com/cctbx/cctbx_project#building-a-development-version>).
> The
> > bootstrap.py command becomes
> >
> > python bootstrap.py --use-conda --python 38
> >
> > This will install miniconda if conda is not already available on your
> > system.
>
> As I did not have conda installed I went for this option and at first I
> encountered this:
>
> ===== Running in .: base
> Location of conda installation not provided
> Proceeding with a fresh installation
> Downloading
> https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh
> Downloaded file to
> /home/jan/Arbeit/cctbx-dev/Miniconda3-latest-Linux-x86_64.sh
> Installing miniconda to "/home/jan/Arbeit/cctbx-dev/mc3"
> /home/jan/Arbeit/cctbx-dev/mc3/conda.exe: error while loading shared
> libraries: libz.so.1: failed to map segment from shared object
> /home/jan/Arbeit/cctbx-dev/mc3/conda.exe: error while loading shared
> libraries: libz.so.1: failed to map segment from shared object
> Traceback (most recent call last):
> File "modules/cctbx_project/libtbx/auto_build/install_conda.py", line
> 1093, in <module>
> sys.exit(run())
> File "modules/cctbx_project/libtbx/auto_build/install_conda.py", line
> 1069, in run
> verbose=namespace.verbose)
> File "modules/cctbx_project/libtbx/auto_build/install_conda.py", line
> 326, in __init__
> self.conda_base = self.install_miniconda(prefix=self.root_dir)
> File "modules/cctbx_project/libtbx/auto_build/install_conda.py", line
> 543, in install_miniconda
> output = check_output(command_list, env=self.env)
> File
>
> "/home/jan/Arbeit/cctbx-dev/modules/cctbx_project/libtbx/auto_build/installer_utils.py",
> line 68, in check_output
> raise RuntimeError("Call to '%s' failed with exit code %d" %
> (popenargs, retcode))
> RuntimeError: Call to '(['/bin/sh',
> '/home/jan/Arbeit/cctbx-dev/Miniconda3-latest-Linux-x86_64.sh', '-b -u
> -p "/home/jan/Arbeit/cctbx-dev/mc3"'],)' failed with exit code 1
> Process failed with return code 1
>
>
> But after a little research [1] I found the cause to be a noexec /tmp.
>
> Remounting /tmp exec made the bootstrap succeed and now I'm happy with
>
> $ /home/jan/Arbeit/cctbx-dev/build/bin/cctbx.python
> Python 3.8.6 | packaged by conda-forge | (default, Oct 7 2020, 19:08:05)
> [GCC 7.5.0] on linux
>
> So on to finally moving my codebase to Python3.
>
> Thank you all for your support and have a nice weekend
>
> Jan
>
>
>
> [1]
>
> https://stackoverflow.com/questions/60106630/conda-exe-error-while-loading-…
> _______________________________________________
> cctbxbb mailing list
> cctbxbb(a)phenix-online.org
> http://phenix-online.org/mailman/listinfo/cctbxbb
>
3 years, 11 months

Re: [phenixbb] Validation of structure with modified residue
by Xavier Brazzolotto
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 <mailto:[email protected]>> 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 <mailto:[email protected]>
>> Fax : 510-486-5909 Web : CCI.LBL.gov <http://cci.lbl.gov/>
>> ORCID : orcid.org/0000-0001-8857-9464 <https://orcid.org/0000-0001-8857-9464>
>>
>>
>> On Wed, Apr 20, 2022 at 5:02 PM Paul Adams <pdadams(a)lbl.gov <mailto:[email protected]>> 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 <mailto:[email protected]>> 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 <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]>
>> --
>> Paul Adams (he/him/his)
>> Associate Laboratory Director for Biosciences, LBL (https://biosciences.lbl.gov/leadership/ <https://biosciences.lbl.gov/leadership/>)
>> Principal Investigator, Computational Crystallography Initiative, LBL (https://cci.lbl.gov <https://cci.lbl.gov/>)
>> Vice President for Technology, the Joint BioEnergy Institute (http://www.jbei.org <http://www.jbei.org/>)
>> Principal Investigator, ALS-ENABLE, Advanced Light Source (https://als-enable.lbl.gov <https://als-enable.lbl.gov/>)
>> Division Deputy for Biosciences, Advanced Light Source (https://als.lbl.gov <https://als.lbl.gov/>)
>> Laboratory Research Manager, ENIGMA Science Focus Area (http://enigma.lbl.gov <http://enigma.lbl.gov/>)
>> Adjunct Professor, Department of Bioengineering, UC Berkeley (http://bioeng.berkeley.edu <http://bioeng.berkeley.edu/>)
>> Member of the Graduate Group in Comparative Biochemistry, UC Berkeley (http://compbiochem.berkeley.edu <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 <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 <mailto:[email protected]> ] [ 1-510-333-6788 ]
>> Phenix Consortium: Ashley Dawn [ AshleyDawn(a)lbl.gov <mailto:[email protected]> ][ 1-510-486-5455 ]
>>
>> --
>>
>> _______________________________________________
>> phenixbb mailing list
>> phenixbb(a)phenix-online.org <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]>
3 years, 2 months

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
1 year, 11 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, 2 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
18 years, 6 months

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
15 years, 10 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

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
>
>
15 years, 5 months