[ccp4bb] A Postdoctoral Position in Structural Biology/Molecular Biology at the University of Nebraska-Lincoln, Lincoln NE, USA

[limei zhang]

One postdoctoral research associate position is immediately available in Prof. 
Limei Zhang’s group at the Dept. of Biochemistry and the Redox Biology Center, 
University of Nebraska-Lincoln, USA (http://biochem.unl.edu). The research in 
the Zhang Laboratory focuses on the structure-mechanism relationship of 
proteins in redox biology, stress response and antibiotic resistance.



The successful candidates are expected to have the following requirements:

  *   Have a recent PhD degree (or expected soon) in molecular biology, 
biochemistry, microbiology or similar field with track record in conducting 
high quality research.
  *   Expertise in either structural biology or advanced molecular biology is 
highly desired
  *   With excellent communication and collaborative skills

The position offers competitive salary and benefits package.

The University of Nebraska-Lincoln is located in a vibrant and safe city 
offering outstanding and affordable quality of life, and numerous 
multi-cultural and entertainment benefits. The Redox Biology Center is 
organized as a broad-based interdisciplinary and multi-institutional entity 
involving researchers from the University of Nebraska-Lincoln and the 
University of Nebraska Medical Center in Omaha, and offers supportive and 
collaborative international environment as well as access to cutting edge 
proteomics, metabolomics, crystallography, and NMR facilities.

To apply for the position, please submit a letter of interest with a short 
summary of past research experience; your curriculum vitae, and contact 
information for three professional references, including phone numbers and 
emails to limei.zh...@unl.edu

As an EO/AA employer, qualified applicants are considered for employment 
without regard to race, color, ethnicity, national origin, sex, pregnancy, 
sexual orientation, gender identity, religion, disability, age, genetic 
information, veteran status, marital status, and/or political affiliation. See 
http://www.unl.edu/equity/notice-nondiscrimination.







To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1

[ccp4bb] Berkeley Server Outage (Starting October evening 8th)

[Paul Adams]

Dear Colleagues,

  as a result of the increased frequency of wildfires in California the power 
company is taking steps to reduce risk under certain weather conditions. This 
entails shutting down electricity to regions that are experiencing dry windy 
conditions. We have been informed that the weather this week meets their 
criteria for a shutdown in our part of the Bay Area. Therefore several of the 
Berkeley servers will be shut down today and will return later in the week. 
This will affect:

- The Phenix web site (http://phenix-online.org/)
- The DIALS West web site (http://dials.lbl.gov/)
- The CCI web site (http://cci.lbl.gov/)
- The Structural Biology Technology Portal (http://technology.sbkb.org/)

  Bug reports and emails requesting help should be queued and we will receive 
them once the servers are back online. We apologize for any inconvenience.

  Cheers,
Paul

-- 
Paul Adams
Division Director, Molecular Biophysics & Integrated Bioimaging, Berkeley Lab 
(http://biosciences.lbl.gov/divisions/mbib)
Division Deputy for Biosciences, Advanced Light Source, Berkeley Lab 
(https://als.lbl.gov)
Principal Investigator, ALS-ENABLE, Advanced Light Source, Berkeley Lab 
(http://als-enable.lbl.gov)
Group Leader, Computational Crystallography Initiative, Berkeley Lab 
(http://cci.lbl.gov)
Vice President for Technology, the Joint BioEnergy Institute 
(http://www.jbei.org)
Laboratory Research Manager, ENIGMA Science Focus Area (http://enigma.lbl.gov)
Adjunct Professor, Department of Bioengineering, U.C. Berkeley 
(http://bioeng.berkeley.edu)
Adjunct Professor, Comparative Biochemistry, U.C. Berkeley 
(http://compbiochem.berkeley.edu)

Building 33, Room 347
Building 978, Room 4126
Building 977, Room 180C
Tel: 1-510-486-4225
http://cci.lbl.gov/paul

Lawrence Berkeley Laboratory
1 Cyclotron Road
BLDG 33R0345
Berkeley, CA 94720, USA.

Executive Assistant: Louise Benvenue [ lbenve...@lbl.gov ][ 1-510-495-2506 ]
--



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1

Re: [ccp4bb] Shelx and debian 10

[Peter Keller]

Dear Tim,

You are making a good point, but.

On 08/10/2019 15:19, Tim Gruene wrote:

Dear George,

as we discussed this issue back in 2016, 'cutting edge distribution' may be a
relative term. This discussion, 
https://einsteinathome.org/content/vsyscall-now-disabled-latest-linux-distros, 
refers to 'ancient versions of glibc' where
the problem occurs.  It seems to be solved with libc-2.15, which was released
2012. I suspect that there are so few reports w.r.t. shelx? because most
distributions enable 'vsyscall=emulate' by default to avoid complaints. Debian
just does not do this.

It may be time to balance the number of SHELX users that still run a 'ancient
versions of' linux vs. those which upgraded their operating system at least
once since 2011...


 RHEL 6/CentOS 6 are using glibc-2.12, and that distro still has a 
year of Extended Lifecycle Support left. ;-).


However, we are really talking about kernels that don't support vDSO, 
rather than glibc versions, and I seriously doubt that anyone is trying 
to run SHELX on a distro now with a kernel that old. I don't know 
exactly which kernel version first supported vDSO, but it might have 
been 2.6.12: , which was 
released in 2004.


I don't have any machines running a truly ancient distro to play around 
with, but Wikipedia tells me that RHEL 4 (using kernel 2.6.9) went out 
of support in 2011, so your estimated date seems about right. RHEL 5 was 
using kernel 2.6.18, so probably already had vDSO support.


Regards,

Peter.




Best,
Tim


On Tuesday, October 8, 2019 3:53:02 PM CEST Peter Keller wrote:

Dear George

On 08/10/2019 11:21, George Sheldrick wrote:

As explained in the attached email from Peter Keller, I was
deliberately preparing the binary Linux SHELX distribution using older
(2011) system libraries so that the programs would run on older
systems that many users are still using. Unfortunately this means that
they do not run on some recent cutting edge distributions including
Debian 10. This can be fixed with 'vsyscall=emulate' when installing
the OS but not all users may be allowed to do this. Dynamic binaries
would be smaller but would require the user to provide the right
libraries.

If I prepare statically linked binaries (using the latest ifort and
ubuntu) they appear to run on current systems but may have problems on
older systems. I may have to offer (e.g. in CCP4 and on the SHELX
server) two sets of Linux binaries in the future, one for 'vintage'
systems and one for current systems.

This is treating the two possibilities as different architectures. This
is a viable approach. Having said that, I doubt that anyone is using a
system now that only supports the vsyscall method for time() etc. I
suspect that linking with a suitable version of glibc would produce a
portable, static executable.

Then, there is also the package approach that David mentioned, although
that requires learning new tools.


Alternatively I could provide both statically and dynamically linked
versions.

There are two approaches for rolling your own dynamically-linked
executables that avoid the need for users to supply the required
libraries themselves:

(1) Link most libraries statically, using link options like
'-Wl,-Bstatic,-lsomelib1,-lsomelib2,-Bdynamic'. This is the kind of
approach that Clemens Vonrhein is using for a future release of Global
Phasing software. The final executables only have minimal run-time
dependencies:

  % ldd `which process`
  linux-vdso.so.1 (0x7b54f000)
  libc.so.6 => /lib64/libc.so.6 (0x7f144842a000)
  /lib64/ld-linux-x86-64.so.2 (0x7f14487e4000)

If a system cannot provide these dependencies, the sysadmin will have
bigger problems to solve than SHELXD not working ;-)

(2) Ship any required libraries that are not provided by the system

along with your binaries. This is the approach that CCP4 is taking:

%  ldd `which mtzdump`
 linux-vdso.so.1 (0x7ffe039e1000)
 libccp4f.so.0 =>
/public/xtal/ccp4/7.0/official/Linux-x86_64/ccp4-7.0/bin/../lib/libccp4f.s
o.0 (0x7fbdd53f5000)
 libccp4c.so.0 =>
/public/xtal/ccp4/7.0/official/Linux-x86_64/ccp4-7.0/bin/../lib/libccp4c.s
o.0 (0x7fbdd51bd000)
 libgfortran.so.3 =>
/public/xtal/ccp4/7.0/official/Linux-x86_64/ccp4-7.0/bin/../lib/libgfortra
n.so.3 (0x7fbdd4ecb000)
 libm.so.6 => /lib64/libm.so.6 (0x7fbdd4b93000)
 libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7fbdd497b000)
 libc.so.6 => /lib64/libc.so.6 (0x7fbdd45c1000)
 libmmdb2.so.0 =>
/public/xtal/ccp4/7.0/official/Linux-x86_64/ccp4-7.0/bin/../lib/../lib/lib
mmdb2.so.0 (0x7fbdd42af000)
 /lib64/ld-linux-x86-64.so.2 (0x7fbdd7f5e000)
 libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x7fbdd3f25000)

The path to the directory containing CCP4-supplied shared libraries is

encoded in the executable itself:

% readelf -d `which mtzdump`

   Dynamic section at offset 0x7650 contains 31 entries:
  

[ccp4bb] Explore your inner lattice

[David Schuller]

https://www.cnet.com/news/diamonception-miners-find-diamond-trapped-inside-another-diamond/


 Diamonception: Miners find diamond trapped inside another diamond


--
===
All Things Serve the Beam
===
   David J. Schuller
   modern man in a post-modern world
   MacCHESS, Cornell University
   schul...@cornell.edu




To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1

Re: [ccp4bb] Shelx and debian 10

[Tim Gruene]

Dear George,

as we discussed this issue back in 2016, 'cutting edge distribution' may be a 
relative term. This discussion, 
https://einsteinathome.org/content/vsyscall-now-disabled-latest-linux-distros, 
refers to 'ancient versions of glibc' where 
the problem occurs.  It seems to be solved with libc-2.15, which was released 
2012. I suspect that there are so few reports w.r.t. shelx? because most 
distributions enable 'vsyscall=emulate' by default to avoid complaints. Debian 
just does not do this.

It may be time to balance the number of SHELX users that still run a 'ancient 
versions of' linux vs. those which upgraded their operating system at least 
once since 2011...

Best,
Tim


On Tuesday, October 8, 2019 3:53:02 PM CEST Peter Keller wrote:
> Dear George
> 
> On 08/10/2019 11:21, George Sheldrick wrote:
> > As explained in the attached email from Peter Keller, I was
> > deliberately preparing the binary Linux SHELX distribution using older
> > (2011) system libraries so that the programs would run on older
> > systems that many users are still using. Unfortunately this means that
> > they do not run on some recent cutting edge distributions including
> > Debian 10. This can be fixed with 'vsyscall=emulate' when installing
> > the OS but not all users may be allowed to do this. Dynamic binaries
> > would be smaller but would require the user to provide the right
> > libraries.
> > 
> > If I prepare statically linked binaries (using the latest ifort and
> > ubuntu) they appear to run on current systems but may have problems on
> > older systems. I may have to offer (e.g. in CCP4 and on the SHELX
> > server) two sets of Linux binaries in the future, one for 'vintage'
> > systems and one for current systems.
> 
> This is treating the two possibilities as different architectures. This
> is a viable approach. Having said that, I doubt that anyone is using a
> system now that only supports the vsyscall method for time() etc. I
> suspect that linking with a suitable version of glibc would produce a
> portable, static executable.
> 
> Then, there is also the package approach that David mentioned, although
> that requires learning new tools.
> 
> > Alternatively I could provide both statically and dynamically linked
> > versions.
> 
> There are two approaches for rolling your own dynamically-linked
> executables that avoid the need for users to supply the required
> libraries themselves:
> 
> (1) Link most libraries statically, using link options like
> '-Wl,-Bstatic,-lsomelib1,-lsomelib2,-Bdynamic'. This is the kind of
> approach that Clemens Vonrhein is using for a future release of Global
> Phasing software. The final executables only have minimal run-time
> dependencies:
> 
>  % ldd `which process`
>  linux-vdso.so.1 (0x7b54f000)
>  libc.so.6 => /lib64/libc.so.6 (0x7f144842a000)
>  /lib64/ld-linux-x86-64.so.2 (0x7f14487e4000)
> 
> If a system cannot provide these dependencies, the sysadmin will have
> bigger problems to solve than SHELXD not working ;-)
> 
> (2) Ship any required libraries that are not provided by the system
> 
> along with your binaries. This is the approach that CCP4 is taking:
> >%  ldd `which mtzdump`
> > linux-vdso.so.1 (0x7ffe039e1000)
> > libccp4f.so.0 =>
> > /public/xtal/ccp4/7.0/official/Linux-x86_64/ccp4-7.0/bin/../lib/libccp4f.s
> > o.0 (0x7fbdd53f5000)
> > libccp4c.so.0 =>
> > /public/xtal/ccp4/7.0/official/Linux-x86_64/ccp4-7.0/bin/../lib/libccp4c.s
> > o.0 (0x7fbdd51bd000)
> > libgfortran.so.3 =>
> > /public/xtal/ccp4/7.0/official/Linux-x86_64/ccp4-7.0/bin/../lib/libgfortra
> > n.so.3 (0x7fbdd4ecb000)
> > libm.so.6 => /lib64/libm.so.6 (0x7fbdd4b93000)
> > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7fbdd497b000)
> > libc.so.6 => /lib64/libc.so.6 (0x7fbdd45c1000)
> > libmmdb2.so.0 =>
> > /public/xtal/ccp4/7.0/official/Linux-x86_64/ccp4-7.0/bin/../lib/../lib/lib
> > mmdb2.so.0 (0x7fbdd42af000)
> > /lib64/ld-linux-x86-64.so.2 (0x7fbdd7f5e000)
> > libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x7fbdd3f25000)
> 
> The path to the directory containing CCP4-supplied shared libraries is
> 
> encoded in the executable itself:
> > % readelf -d `which mtzdump`
> > 
> >   Dynamic section at offset 0x7650 contains 31 entries:
> >   TagType Name/Value
> >  0x0001 (NEEDED) Shared library: [libccp4f.so.0]
> >  0x0001 (NEEDED) Shared library: [libccp4c.so.0]
> >  0x0001 (NEEDED) Shared library:
> > [libgfortran.so.3]
> >  0x0001 (NEEDED) Shared library: [libm.so.6]
> >  0x0001 (NEEDED) Shared library: [libgcc_s.so.1]
> >  0x0001 (NEEDED) Shared library: [libc.so.6]
> >  0x000f (RPATH)  Library rpath: [$ORIGIN/../lib]
> 
> Note the special token "$ORIGIN", which means the directory co

Re: [ccp4bb] Shelx and debian

[Peter Keller]

Dear Isabel

On 08/10/2019 14:53, Isabel Uson wrote:

Dear Bernhard and Peter,

as Tim describes, changing the grub loader fixes the problem.


Unfortunately, this is not a viable solution. Many crystallographers do 
not have root access on their systems. Their system administration staff 
will have the task of ensuring system stability for a large community of 
users with a wide range of requirements, and may have policies in place 
which make the changing of kernel parameters extremely problematic. For 
example, an extensive set of compliance procedures may have to be 
repeated after a change to kernel parameters, and busy sysadmins may 
argue that this cannot be prioritised for the sake of a few specialised 
applications, no matter how important to the crystallographers.


I am sure that this sounds alien to crystallographers who manage their 
own systems, but those of us who distribute software have to deal with 
the world as it is.


I have looked into the changes to eliminate system calls and provide a 
version that would work without changes to the system, they are 
relatively minor. SHELXE just needs to eliminate calls to system time, 
pity for the convenient profiling but it can still be an option to be 
activated with the appropriate kernel. I just checked that the static 
version compiled with this change works perfectly on Debian 10.
SHELXD in addition would need to get the number of threads as an input 
parameter rather than use what it detects in the system. We could 
shift to the interfaces the tasks of finding out the number of cores 
(and passing some time information to record in the output). The 
parameter already exists (-t) and users still fond of a terminal and 
command line usually know how many cores their machines have.


IMHO it would be a pity to change/remove functionality when the problem 
can be solved in other ways.




Up to George of course, whether he wants us to provide these versions 
and by when. Maybe he favours other alternatives.


but yes, George and others need to decide. I'm not pushing for any 
solution in particular, except to say that it should work for major 
distributions in their default configuration.


Regards,

Peter.


Best wishes,

Isabel


--
Peter Keller Tel.: +44 (0)1223 353033
Global Phasing Ltd., Fax.: +44 (0)1223 366889
Sheraton House,
Castle Park,
Cambridge CB3 0AX
United Kingdom




To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1

[ccp4bb] Les Houches-TSRC Workshop on Protein Dynamics, June 7-12, 2020

[martin weik]

*Les Houches-TSRC Workshop on Protein Dynamics, June 7-12, 2020*

We cordially invite applications to participate in the 4th edition of 
the Protein Dynamics Workshop to be held in Les Houches, close to 
Chamonix/Mont Blanc, in the French Alps from June 7-12, 2020.


This workshop gathers about 70 speakers and participants working in the 
wide area of protein dynamics, in the outstanding location of the 
historical Ecole de Physique des Houches, an environment ideally suited 
for exchange of ideas and fostering collaborations. About 30 invited 
speakers will give oral presentations that comprise a pedagogic 
introduction to the methodology employed, followed by applications from 
their own work, and a particular emphasis on discussions within the 
cross-disciplinary participants.*

*

Please find information on our website

https://tinyurl.com/protdyn2020


The organizing committee
Enrica Bordignon 
 
(Ruhr University Bochum, Germany)
Matthias Heyden 
 
(Arizona State University, USA)
Paul Schanda 
 
(Institut de Biologie Structurale, Grenoble, France)
Ben Schuler 
 
(University of Zurich, Switzerland)
Martin Weik 
 
(Institut de Biologie Structurale, Grenoble, France)


--
Martin Weik
Structural Protein Dynamics Research Team
Institut de Biologie Structurale
CAMPUS EPN
71 avenue des Martyrs
CS10090
38044 Grenoble Cedex 9; France  

Phone:(33) 4 57 42 85 80


email:  w...@ibs.fr
http://www.ibs.fr/groups/dynamics-and-kinetics-of-molecular/structural-protein-dynamics/?lang=en




To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1

[ccp4bb] Shelx and debian

[Isabel Uson]

Dear Bernhard and Peter,

as Tim describes, changing the grub loader fixes the problem. I have looked
into the changes to eliminate system calls and provide a version that would
work without changes to the system, they are relatively minor. SHELXE just
needs to eliminate calls to system time, pity for the convenient profiling
but it can still be an option to be activated with the appropriate kernel.
I just checked that the static version compiled with this change works
perfectly on Debian 10.
SHELXD in addition would need to get the number of threads as an input
parameter rather than use what it detects in the system. We could shift to
the interfaces the tasks of finding out the number of cores (and passing
some time information to record in the output). The parameter already
exists (-t) and users still fond of a terminal and command line usually
know how many cores their machines have.

Up to George of course, whether he wants us to provide these versions and
by when. Maybe he favours other alternatives.
Best wishes,

Isabel


> --
>
> Date:Mon, 7 Oct 2019 17:05:44 +0200
> From:Bernhard Rupp 
> Subject: Shelx and debian 10
>
> Hi Fellows,
>
>
>
> we updated to Debian 10 on the local workshop computers, and reinstalled
>
> Coot and ccp4. All fine.
>
>
>
> Problem: Shelxc/d/e/  does not run, and
>
> the call exits immediately sans any message.
>
>
>
> This holds for the binaries included in ccp4 as well as for those from the
> SHELX site.
>
> The executables from CCP4 and SHELX site – same file size, probably same -
> run fine under Debian 9.
>
>
>
> I suspect a library problem.
>
>
>
> Does some kind soul have CDE binaries for Debian 10 to share?
>
>
>
> Many thx in advance, BR
>
>
>
>
> 
> 
>
> Bernhard Rupp
>
> Department of Genetics and Pharmacology
>
> Institute of Genetic Epidemiology
>
> Medical University Innsbruck
>
> Schöpfstrasse 41
>
> A 6020 Innsbruck – Austria
>
> +43 (676) 571-0536
>
> bernhard.r...@i-med.ac.at
>
>
> 
> 
>
> k.k. Hofkristallamt
>
> San Diego, CA 92084
>
> 001 (925) 209-7429
>
> b...@ruppweb.org
>
> b...@hofkristallamt.org
>
> http://www.ruppweb.org/
>
> ---
>
>
>
>
> 
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
>
> --
>
> Date:Mon, 7 Oct 2019 16:53:44 +0100
> From:Peter Keller 
> Subject: Re: Shelx and debian 10
>
> Dear Bernhard,
>
> We had this issue drawn to our attention last year by an early adopter
> of Debian 10 while it was still in testing. I thought that it was a bug,
> and submitted a report accordingly here:
> . I was told
> that it is not a bug, but a feature ;-)
>
> If you are able, you could try setting the kernel parameter
> vsyscall=emulate. In the longer term, SHELXC/D/E will have to be rebuilt
> to support systems where the vsyscall has been disabled. This means they
> have to be dynamic executables that include the following in the output
> of 'ldd':
>
> % ldd /bin/bash
>  linux-vdso.so.1 (0x7fff50952000)
>  
>
> All current distros use vDSO, so this shouldn't cause portability
> problems by itself, but handling dynamic executables can be trickier
> than static ones.
>
> For a little more background, see 
>
> Finally, you have my commiserations: although this change has been a
> long time coming, it hasn't attracted a lot of attention. It was bound
> to catch users of static executables by surprise.
>
> Regards,
>
> Peter.
>
>
> On 07/10/2019 16:05, Bernhard Rupp wrote:
> >
> > Hi Fellows,
> >
> > we updated to Debian 10 on the local workshop computers, and reinstalled
> >
> > Coot and ccp4. All fine.
> >
> > Problem: Shelxc/d/e/  does not run, and
> >
> > the call exits immediately sans any message.
> >
> > This holds for the binaries included in ccp4 as well as for those from
> > the SHELX site.
> >
> > The executables from CCP4 and SHELX site – same file size, probably
> > same - run fine under Debian 9.
> >
> > I suspect a library problem.
> >
> > Does some kind soul have CDE binaries for Debian 10 to share?
> >
> > Many thx in advance, BR
> >
> >
> 
> >
> > Bernhard Rupp
> >
> > Department of Genetics and Pharmacology
> >
> > Institute of Genetic Epidemiology
> >
> > Medical University Innsbruck
> >
> > Schöpfstrasse 41
> >
> > A 6020 Innsbruck – Austria
> >
> > +43 (676) 571-0536
> >
> > bernhard.r...@i-med.ac.at
> >
> >
> --

Re: [ccp4bb] Shelx and debian 10

[Peter Keller]

Dear George

On 08/10/2019 11:21, George Sheldrick wrote:
As explained in the attached email from Peter Keller, I was 
deliberately preparing the binary Linux SHELX distribution using older 
(2011) system libraries so that the programs would run on older 
systems that many users are still using. Unfortunately this means that 
they do not run on some recent cutting edge distributions including 
Debian 10. This can be fixed with 'vsyscall=emulate' when installing 
the OS but not all users may be allowed to do this. Dynamic binaries 
would be smaller but would require the user to provide the right 
libraries.


If I prepare statically linked binaries (using the latest ifort and 
ubuntu) they appear to run on current systems but may have problems on 
older systems. I may have to offer (e.g. in CCP4 and on the SHELX 
server) two sets of Linux binaries in the future, one for 'vintage' 
systems and one for current systems.


This is treating the two possibilities as different architectures. This 
is a viable approach. Having said that, I doubt that anyone is using a 
system now that only supports the vsyscall method for time() etc. I 
suspect that linking with a suitable version of glibc would produce a 
portable, static executable.


Then, there is also the package approach that David mentioned, although 
that requires learning new tools.


Alternatively I could provide both statically and dynamically linked 
versions. 


There are two approaches for rolling your own dynamically-linked 
executables that avoid the need for users to supply the required 
libraries themselves:


(1) Link most libraries statically, using link options like 
'-Wl,-Bstatic,-lsomelib1,-lsomelib2,-Bdynamic'. This is the kind of 
approach that Clemens Vonrhein is using for a future release of Global 
Phasing software. The final executables only have minimal run-time 
dependencies:


    % ldd `which process`
    linux-vdso.so.1 (0x7b54f000)
    libc.so.6 => /lib64/libc.so.6 (0x7f144842a000)
    /lib64/ld-linux-x86-64.so.2 (0x7f14487e4000)

If a system cannot provide these dependencies, the sysadmin will have 
bigger problems to solve than SHELXD not working ;-)


(2) Ship any required libraries that are not provided by the system 
along with your binaries. This is the approach that CCP4 is taking:



   %  ldd `which mtzdump`
    linux-vdso.so.1 (0x7ffe039e1000)
    libccp4f.so.0 => 
/public/xtal/ccp4/7.0/official/Linux-x86_64/ccp4-7.0/bin/../lib/libccp4f.so.0 
(0x7fbdd53f5000)
    libccp4c.so.0 => 
/public/xtal/ccp4/7.0/official/Linux-x86_64/ccp4-7.0/bin/../lib/libccp4c.so.0 
(0x7fbdd51bd000)
    libgfortran.so.3 => 
/public/xtal/ccp4/7.0/official/Linux-x86_64/ccp4-7.0/bin/../lib/libgfortran.so.3 
(0x7fbdd4ecb000)

    libm.so.6 => /lib64/libm.so.6 (0x7fbdd4b93000)
    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7fbdd497b000)
    libc.so.6 => /lib64/libc.so.6 (0x7fbdd45c1000)
    libmmdb2.so.0 => 
/public/xtal/ccp4/7.0/official/Linux-x86_64/ccp4-7.0/bin/../lib/../lib/libmmdb2.so.0 
(0x7fbdd42af000)

    /lib64/ld-linux-x86-64.so.2 (0x7fbdd7f5e000)
    libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x7fbdd3f25000)


The path to the directory containing CCP4-supplied shared libraries is 
encoded in the executable itself:



% readelf -d `which mtzdump`

  Dynamic section at offset 0x7650 contains 31 entries:
  Tag    Type Name/Value
 0x0001 (NEEDED) Shared library: [libccp4f.so.0]
 0x0001 (NEEDED) Shared library: [libccp4c.so.0]
 0x0001 (NEEDED) Shared library: 
[libgfortran.so.3]

 0x0001 (NEEDED) Shared library: [libm.so.6]
 0x0001 (NEEDED) Shared library: [libgcc_s.so.1]
 0x0001 (NEEDED) Shared library: [libc.so.6]
 0x000f (RPATH)  Library rpath: [$ORIGIN/../lib]


Note the special token "$ORIGIN", which means the directory containing 
the executable (this is documented in the 'man' page for ld.so). The 
RPATH item is set to the above value with an option like 
'-Wl,-rpath,\$ORIGIN/../lib' (where the '$' character needs to be 
escaped from the shell, obviously).


Note that -rpath is not the same as -L: -L is used at link-time to find 
the libraries needed to check that all the symbols are resolvable. 
-rpath is used to locate shared libraries at run-time: its argument 
doesn't even have to exist at link-time. If you go down this route, you 
will need to specify both -L and -rpath.



What do users think?


As for which is the best approach, I'll let others make their opinions 
known, but I hope that this explanation has helped.


Regards,

Peter.



Best wishes, George


On 08.10.19 11:04, Peter Keller wrote:

HI Tim,

On Mon, 7 Oct 2019, Tim Gruene wrote:


Date: Mon, 07 Oct 2019 23:04:28 +0200
From: Tim Gruene 
To: Peter Keller 
Cc: CCP4BB@jiscmail.ac.uk
Subject: Re: [ccp4bb] Shelx and debia

Re: [ccp4bb] coiled coil molecular replacement - PS

[Sergei Strelkov]

> 1. Try our coiled-coil modelling server
> https://pharm.kuleuven.be/apps/biocryst/ccfold.php

Some more explanation here. This server runs our CCFold algorithm (Guzenko & 
Strelkov (2017) Bioinformatics, article btx551). CCFold is a threading-type 
algorithm which was specifically designed to model coiled coils from amino-acid 
sequence. This is why it is fundamentally faster than generic algorithms like 
Quark or Rosetta. CCFold is also trivial to run using our web server or a local 
installation if you prefer. The modelling accuracy of CCFold was discussed in 
the Guzenko and Strelkov paper cited above.

Sergei


From: CCP4 bulletin board  on behalf of Sergei Strelkov 

Sent: Tuesday, October 8, 2019 14:14
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] coiled coil molecular replacement

Dear Tommi,

With coiled coils you certainly want to use the best search model possible. 
Coiled coils are elongated structures and a small local inaccuracy of your 
search model may result in large differences (in terms of overall rmsd) with 
respect to the true structure. Two suggestions:

1. Try our coiled-coil modelling server
https://pharm.kuleuven.be/apps/biocryst/ccfold.php

2. Prepare a set of partial models (corresponding to various parts/lengths e.g. 
50-60% of the total length) and attempt MR with each of them. In our experience 
the standard algorithms (MolRep/Phaser) can also work well. It depends a lot on 
the space group and particular packing of your dimers (dense packings being the 
most challenging).

Hope this helps,
Sergei


Prof. Sergei V. Strelkov
Laboratory for Biocrystallography
Department of Pharmaceutical Sciences, KU Leuven
O&N2, Campus Gasthuisberg, Herestraat 49 bus 822, 3000 Leuven, Belgium
Phone: +32 16 33 08 45, mobile: +32 486 29 41 32
Lab pages: http://pharm.kuleuven.be/Biocrystallography


From: CCP4 bulletin board  on behalf of Kajander, Tommi 
A 
Sent: Monday, October 7, 2019 23:33
To: CCP4BB@JISCMAIL.AC.UK
Subject: [ccp4bb] coiled coil molecular replacement

Hello,

We have a bit tricky case of coiled coil protein with good data (2.05Å) for 
dimeric coiled coil (dimer in AU)  - looks like AMPLE might be a way
to solve such cases, if you know other good programs please suggest (Better yet 
if there is a clear how-to manual)

Some technical tips on usage for generation of fragments for AMPLE would be of 
help, not completely on top of that… (running the QUARK server, the real 
sequence is bit over 200 aa so not sure what is the best approach here? 
Rosetta? any how-to for that.. well i am running Robetta fragments too).

with AMPLE can I do this with the online server or better run locally (need 
Rosetta installed I take it?)

Suppose I could try Rosetta-MR also, but to my recollection that requires some 
kind of a phaser hit first to be improved, and i dont think I am there.

Thanks for any comments,

Best,
Tommi






To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1

Re: [ccp4bb] Shelx and debian 10

[David Schuller]

There is now another alternative. There are platforms for packaging 
software with necessary libraries. PyMOL for example is available using 
"snap".


https://www.mail-archive.com/ccp4bb@jiscmail.ac.uk/msg46623.html



On 2019-10-08 06:21, George Sheldrick wrote:
As explained in the attached email from Peter Keller, I was 
deliberately preparing the binary Linux SHELX distribution using older 
(2011) system libraries so that the programs would run on older 
systems that many users are still using. Unfortunately this means that 
they do not run on some recent cutting edge distributions including 
Debian 10. This can be fixed with 'vsyscall=emulate' when installing 
the OS but not all users may be allowed to do this. Dynamic binaries 
would be smaller but would require the user to provide the right 
libraries.


If I prepare statically linked binaries (using the latest ifort and 
ubuntu) they appear to run on current systems but may have problems on 
older systems. I may have to offer (e.g. in CCP4 and on the SHELX 
server) two sets of Linux binaries in the future, one for 'vintage' 
systems and one for current systems. Alternatively I could provide 
both statically and dynamically linked versions. What do users think?


Best wishes, George


On 08.10.19 11:04, Peter Keller wrote:

HI Tim,

On Mon, 7 Oct 2019, Tim Gruene wrote:


Date: Mon, 07 Oct 2019 23:04:28 +0200
From: Tim Gruene 
To: Peter Keller 
Cc: CCP4BB@jiscmail.ac.uk
Subject: Re: [ccp4bb] Shelx and debian 10




@Peter: are you sure that without 'vsyscall=emulate' linux binaries 
need to be

dynamically linked? I would be very surprised if the linux kernel would
disable statically linked binaries. I rather think that the vanilla 
versions
of shelx c/d/e (from shelx.uni-goettingen.de) are compiled with an 
obsolete

compiler / obsolete compiler options.


You're right, I wrote my reply to Bernhard too rapidly, and conflated 
two separate issues. Debian 10 still supports static binaries of 
course, but in its default configuration (without vsyscall=emulate), 
those static binaries must be linked with a version of glibc that 
doesn't require vsyscalls. OTOH, dynamic binaries don't suffer from 
this problem, because they can use vDSO provided by the running 
(rather than the build) system.


I think that part of the problem is that traditionally when we want 
to build portable linux binaries, we tend to build on the oldest 
distribution that we want to support, relying on backwards 
compatibility to provide the portability that we are after. We often 
build statically, because it is a robust way of including all the 
required libraries and is less fiddly and error-prone than providing 
them as dynamic libraries. There is also no danger of breakage caused 
by rogue values of LD_LIBRARY_PATH (which users shouldn't be setting 
of course, but we have no way of stopping them). The drawback of this 
approach is that when backwards compatibility is broken, there is no 
application-level fix.


These kinds of problems are rare, but when they do happen the onus is 
on those of us who distribute binary applications to find solutions. 
Some sysadmins may have good reasons for being reluctant to change 
kernel parameters to get third-party applications to work.


Regards,
Peter.




On Monday, October 7, 2019 5:53:44 PM CEST Peter Keller wrote:

Dear Bernhard,

We had this issue drawn to our attention last year by an early adopter
of Debian 10 while it was still in testing. I thought that it was a 
bug,

and submitted a report accordingly here:
. I was told
that it is not a bug, but a feature ;-)

If you are able, you could try setting the kernel parameter
vsyscall=emulate. In the longer term, SHELXC/D/E will have to be 
rebuilt
to support systems where the vsyscall has been disabled. This means 
they
have to be dynamic executables that include the following in the 
output

of 'ldd':

% ldd /bin/bash
 linux-vdso.so.1 (0x7fff50952000)
 

All current distros use vDSO, so this shouldn't cause portability
problems by itself, but handling dynamic executables can be trickier
than static ones.

For a little more background, see 

Finally, you have my commiserations: although this change has been a
long time coming, it hasn't attracted a lot of attention. It was bound
to catch users of static executables by surprise.

Regards,

Peter.

On 07/10/2019 16:05, Bernhard Rupp wrote:

Hi Fellows,

we updated to Debian 10 on the local workshop computers, and 
reinstalled


Coot and ccp4. All fine.

Problem: Shelxc/d/e/  does not run, and

the call exits immediately sans any message.

This holds for the binaries included in ccp4 as well as for those 
from

the SHELX site.

The executables from CCP4 and SHELX site – same file size, probably
same - run fine under Debian 9.

I suspect a library problem.

Does some kind soul have CDE binaries for Debian 10 to share?

Many thx 

Re: [ccp4bb] coiled coil molecular replacement

[Sergei Strelkov]

Dear Tommi,

With coiled coils you certainly want to use the best search model possible. 
Coiled coils are elongated structures and a small local inaccuracy of your 
search model may result in large differences (in terms of overall rmsd) with 
respect to the true structure. Two suggestions:

1. Try our coiled-coil modelling server 
https://pharm.kuleuven.be/apps/biocryst/ccfold.php

2. Prepare a set of partial models (corresponding to various parts/lengths e.g. 
50-60% of the total length) and attempt MR with each of them. In our experience 
the standard algorithms (MolRep/Phaser) can also work well. It depends a lot on 
the space group and particular packing of your dimers (dense packings being the 
most challenging).

Hope this helps,
Sergei


Prof. Sergei V. Strelkov
Laboratory for Biocrystallography
Department of Pharmaceutical Sciences, KU Leuven
O&N2, Campus Gasthuisberg, Herestraat 49 bus 822, 3000 Leuven, Belgium
Phone: +32 16 33 08 45, mobile: +32 486 29 41 32
Lab pages: http://pharm.kuleuven.be/Biocrystallography


From: CCP4 bulletin board  on behalf of Kajander, Tommi 
A 
Sent: Monday, October 7, 2019 23:33
To: CCP4BB@JISCMAIL.AC.UK
Subject: [ccp4bb] coiled coil molecular replacement

Hello,

We have a bit tricky case of coiled coil protein with good data (2.05Å) for 
dimeric coiled coil (dimer in AU)  - looks like AMPLE might be a way
to solve such cases, if you know other good programs please suggest (Better yet 
if there is a clear how-to manual)

Some technical tips on usage for generation of fragments for AMPLE would be of 
help, not completely on top of that… (running the QUARK server, the real 
sequence is bit over 200 aa so not sure what is the best approach here? 
Rosetta? any how-to for that.. well i am running Robetta fragments too).

with AMPLE can I do this with the online server or better run locally (need 
Rosetta installed I take it?)

Suppose I could try Rosetta-MR also, but to my recollection that requires some 
kind of a phaser hit first to be improved, and i dont think I am there.

Thanks for any comments,

Best,
Tommi






To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1

Re: [ccp4bb] Shelx and debian 10

[George Sheldrick]

As explained in the attached email from Peter Keller, I was deliberately 
preparing the binary Linux SHELX distribution using older (2011) system 
libraries so that the programs would run on older systems that many 
users are still using. Unfortunately this means that they do not run on 
some recent cutting edge distributions including Debian 10. This can be 
fixed with 'vsyscall=emulate' when installing the OS but not all users 
may be allowed to do this. Dynamic binaries would be smaller but would 
require the user to provide the right libraries.


If I prepare statically linked binaries (using the latest ifort and 
ubuntu) they appear to run on current systems but may have problems on 
older systems. I may have to offer (e.g. in CCP4 and on the SHELX 
server) two sets of Linux binaries in the future, one for 'vintage' 
systems and one for current systems. Alternatively I could provide both 
statically and dynamically linked versions. What do users think?


Best wishes, George


On 08.10.19 11:04, Peter Keller wrote:

HI Tim,

On Mon, 7 Oct 2019, Tim Gruene wrote:


Date: Mon, 07 Oct 2019 23:04:28 +0200
From: Tim Gruene 
To: Peter Keller 
Cc: CCP4BB@jiscmail.ac.uk
Subject: Re: [ccp4bb] Shelx and debian 10




@Peter: are you sure that without 'vsyscall=emulate' linux binaries 
need to be

dynamically linked? I would be very surprised if the linux kernel would
disable statically linked binaries. I rather think that the vanilla 
versions
of shelx c/d/e (from shelx.uni-goettingen.de) are compiled with an 
obsolete

compiler / obsolete compiler options.


You're right, I wrote my reply to Bernhard too rapidly, and conflated 
two separate issues. Debian 10 still supports static binaries of 
course, but in its default configuration (without vsyscall=emulate), 
those static binaries must be linked with a version of glibc that 
doesn't require vsyscalls. OTOH, dynamic binaries don't suffer from 
this problem, because they can use vDSO provided by the running 
(rather than the build) system.


I think that part of the problem is that traditionally when we want to 
build portable linux binaries, we tend to build on the oldest 
distribution that we want to support, relying on backwards 
compatibility to provide the portability that we are after. We often 
build statically, because it is a robust way of including all the 
required libraries and is less fiddly and error-prone than providing 
them as dynamic libraries. There is also no danger of breakage caused 
by rogue values of LD_LIBRARY_PATH (which users shouldn't be setting 
of course, but we have no way of stopping them). The drawback of this 
approach is that when backwards compatibility is broken, there is no 
application-level fix.


These kinds of problems are rare, but when they do happen the onus is 
on those of us who distribute binary applications to find solutions. 
Some sysadmins may have good reasons for being reluctant to change 
kernel parameters to get third-party applications to work.


Regards,
Peter.




On Monday, October 7, 2019 5:53:44 PM CEST Peter Keller wrote:

Dear Bernhard,

We had this issue drawn to our attention last year by an early adopter
of Debian 10 while it was still in testing. I thought that it was a 
bug,

and submitted a report accordingly here:
. I was told
that it is not a bug, but a feature ;-)

If you are able, you could try setting the kernel parameter
vsyscall=emulate. In the longer term, SHELXC/D/E will have to be 
rebuilt
to support systems where the vsyscall has been disabled. This means 
they

have to be dynamic executables that include the following in the output
of 'ldd':

% ldd /bin/bash
 linux-vdso.so.1 (0x7fff50952000)
 

All current distros use vDSO, so this shouldn't cause portability
problems by itself, but handling dynamic executables can be trickier
than static ones.

For a little more background, see 

Finally, you have my commiserations: although this change has been a
long time coming, it hasn't attracted a lot of attention. It was bound
to catch users of static executables by surprise.

Regards,

Peter.

On 07/10/2019 16:05, Bernhard Rupp wrote:

Hi Fellows,

we updated to Debian 10 on the local workshop computers, and 
reinstalled


Coot and ccp4. All fine.

Problem: Shelxc/d/e/  does not run, and

the call exits immediately sans any message.

This holds for the binaries included in ccp4 as well as for those from
the SHELX site.

The executables from CCP4 and SHELX site – same file size, probably
same - run fine under Debian 9.

I suspect a library problem.

Does some kind soul have CDE binaries for Debian 10 to share?

Many thx in advance, BR

-- 


--

Bernhard Rupp

Department of Genetics and Pharmacology

Institute of Genetic Epidemiology

Medical University Innsbruck

Schöpfstrasse 41

A 6020 Innsbruck – A

Re: [ccp4bb] Shelx and debian 10

[Peter Keller]

HI Tim,

On Mon, 7 Oct 2019, Tim Gruene wrote:


Date: Mon, 07 Oct 2019 23:04:28 +0200
From: Tim Gruene 
To: Peter Keller 
Cc: CCP4BB@jiscmail.ac.uk
Subject: Re: [ccp4bb] Shelx and debian 10





@Peter: are you sure that without 'vsyscall=emulate' linux binaries need to be
dynamically linked? I would be very surprised if the linux kernel would
disable statically linked binaries. I rather think that the vanilla versions
of shelx c/d/e (from shelx.uni-goettingen.de) are compiled with an obsolete
compiler / obsolete compiler options.


You're right, I wrote my reply to Bernhard too rapidly, and conflated 
two separate issues. Debian 10 still supports static binaries of course, 
but in its default configuration (without vsyscall=emulate), those 
static binaries must be linked with a version of glibc that doesn't 
require vsyscalls. OTOH, dynamic binaries don't suffer from this 
problem, because they can use vDSO provided by the running (rather than 
the build) system.


I think that part of the problem is that traditionally when we want to 
build portable linux binaries, we tend to build on the oldest 
distribution that we want to support, relying on backwards compatibility 
to provide the portability that we are after. We often build statically, 
because it is a robust way of including all the required libraries and 
is less fiddly and error-prone than providing them as dynamic libraries. 
There is also no danger of breakage caused by rogue values of 
LD_LIBRARY_PATH (which users shouldn't be setting of course, but we have 
no way of stopping them). The drawback of this approach is that when 
backwards compatibility is broken, there is no application-level fix.


These kinds of problems are rare, but when they do happen the onus is on 
those of us who distribute binary applications to find solutions. Some 
sysadmins may have good reasons for being reluctant to change kernel 
parameters to get third-party applications to work.


Regards,
Peter.




On Monday, October 7, 2019 5:53:44 PM CEST Peter Keller wrote:

Dear Bernhard,

We had this issue drawn to our attention last year by an early adopter
of Debian 10 while it was still in testing. I thought that it was a bug,
and submitted a report accordingly here:
. I was told
that it is not a bug, but a feature ;-)

If you are able, you could try setting the kernel parameter
vsyscall=emulate. In the longer term, SHELXC/D/E will have to be rebuilt
to support systems where the vsyscall has been disabled. This means they
have to be dynamic executables that include the following in the output
of 'ldd':

% ldd /bin/bash
 linux-vdso.so.1 (0x7fff50952000)
 

All current distros use vDSO, so this shouldn't cause portability
problems by itself, but handling dynamic executables can be trickier
than static ones.

For a little more background, see 

Finally, you have my commiserations: although this change has been a
long time coming, it hasn't attracted a lot of attention. It was bound
to catch users of static executables by surprise.

Regards,

Peter.

On 07/10/2019 16:05, Bernhard Rupp wrote:

Hi Fellows,

we updated to Debian 10 on the local workshop computers, and reinstalled

Coot and ccp4. All fine.

Problem: Shelxc/d/e/  does not run, and

the call exits immediately sans any message.

This holds for the binaries included in ccp4 as well as for those from
the SHELX site.

The executables from CCP4 and SHELX site – same file size, probably
same - run fine under Debian 9.

I suspect a library problem.

Does some kind soul have CDE binaries for Debian 10 to share?

Many thx in advance, BR

--
--

Bernhard Rupp

Department of Genetics and Pharmacology

Institute of Genetic Epidemiology

Medical University Innsbruck

Schöpfstrasse 41

A 6020 Innsbruck – Austria

+43 (676) 571-0536

bernhard.r...@i-med.ac.at

--
--

k.k. Hofkristallamt

San Diego, CA 92084

001 (925) 209-7429

b...@ruppweb.org

b...@hofkristallamt.org

http://www.ruppweb.org/

---




To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1





--
Peter Keller Tel.: +44 (0)1223 353033
Global Phasing Ltd., Fax.: +44 (0)1223 366889
Sheraton House,
Castle Park,
Cambridge CB3 0AX
United Kingdom



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1

Re: [ccp4bb] coiled coil molecular replacement

[IRACEMA CABALLERO MUÑOZ]

Hi Tommi, as sent by Kay ARCIMBOLDO has a specific mode to solve coiled
coils (http://scripts.iucr.org/cgi-bin/paper?cb5097).

Here you can find the tutorial: http://chango.ibmb.csic.es/tutorial_coiled,
it explains how to launch it through the command line and a summary
explaining the improvements of the mode.

It can also be launched through CCP4i, here you only need to activate "run
coiled-coil mode" and put the search strategy (number of helices and helix
length). In this supplementary table, you have examples of the search
strategy for 150 cases
https://doi.org//10.1107/S2059798317017582/cb5097sup2.xlsx

[image: coiled_coil_mode_ccp4i.png]

And please if you have any questions just let me know.

Best wishes,
Iracema

El mar., 8 oct. 2019 a las 9:33, Daniel Rigden ()
escribió:

> Hi Tommi
>
> Yes, AMPLE does well with coiled-coils. The QUARK route is the easiest
> to try. In your position I would simply trim a bit of sequence off
> either end. Maybe you can see homologs that are a bit shorter at one
> terminus? In any case, that's unlikely to affect the modelling and we've
> seen QUARK make good models of coiled-coil proteins.
>
> For Rosetta modelling we simply recommend you use the Robetta server
> http://robetta.bakerlab.org/fragmentsubmit.jsp for fragment libraries.
> Unless you're processing large numbers of sequences it's not worth
> getting to grips with local fragment library generation. At the moment
> CCP4online takes a file of ready-made models, not carrying out the
> actual modelling for you. Doing local Rosetta modelling via AMPLE is as
> described here
>
> https://ample.readthedocs.io/en/latest/examples/rst/abinitio.html#example-abinitio
>
> Recently, in collaboration with Owen Davies in Newcastle, we've made
> some big improvements to AMPLE's abilities with coiled-coils, involving
> more bespoke modelling protocols, both of a single chain and, where the
> information is known, of a parallel oligomer. I gather Owen has been in
> touch with you about these. The code is available but is not in the
> current CCP4 distribution. We're also planning to improve the AMPLE
> documentation in the next few months and we'll include an example of use
> of this new coiled-coil mode at that time.
>
> Best wishes
>
> Dan
>
> On 07/10/2019 22:33, Kajander, Tommi A wrote:
> > Hello,
> >
> > We have a bit tricky case of coiled coil protein with good data (2.05Å)
> for dimeric coiled coil (dimer in AU)  - looks like AMPLE might be a way
> > to solve such cases, if you know other good programs please suggest
> (Better yet if there is a clear how-to manual)
> >
> > Some technical tips on usage for generation of fragments for AMPLE would
> be of help, not completely on top of that… (running the QUARK server, the
> real sequence is bit over 200 aa so not sure what is the best approach
> here? Rosetta? any how-to for that.. well i am running Robetta fragments
> too).
> >
> > with AMPLE can I do this with the online server or better run locally
> (need Rosetta installed I take it?)
> >
> > Suppose I could try Rosetta-MR also, but to my recollection that
> requires some kind of a phaser hit first to be improved, and i dont think I
> am there.
> >
> > Thanks for any comments,
> >
> > Best,
> > Tommi
> >
> >
> >
> >
> > 
> >
> > To unsubscribe from the CCP4BB list, click the following link:
> > https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
>
> --
> Prof Daniel Rigden
> Institute of Integrative Biology
> Room 101, Biosciences Building
> University of Liverpool
> Crown St., Liverpool, L69 7ZB
>
> (+44) 151 795 4467
> pcwww.liverpool.ac.uk/~drigden/
>
> 
>
> To unsubscribe from the CCP4BB list, click the following link:
> https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1
>



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1

Re: [ccp4bb] coiled coil molecular replacement

[Daniel Rigden]

Hi Tommi

Yes, AMPLE does well with coiled-coils. The QUARK route is the easiest 
to try. In your position I would simply trim a bit of sequence off 
either end. Maybe you can see homologs that are a bit shorter at one 
terminus? In any case, that's unlikely to affect the modelling and we've 
seen QUARK make good models of coiled-coil proteins.


For Rosetta modelling we simply recommend you use the Robetta server 
http://robetta.bakerlab.org/fragmentsubmit.jsp for fragment libraries. 
Unless you're processing large numbers of sequences it's not worth 
getting to grips with local fragment library generation. At the moment 
CCP4online takes a file of ready-made models, not carrying out the 
actual modelling for you. Doing local Rosetta modelling via AMPLE is as 
described here 
https://ample.readthedocs.io/en/latest/examples/rst/abinitio.html#example-abinitio


Recently, in collaboration with Owen Davies in Newcastle, we've made 
some big improvements to AMPLE's abilities with coiled-coils, involving 
more bespoke modelling protocols, both of a single chain and, where the 
information is known, of a parallel oligomer. I gather Owen has been in 
touch with you about these. The code is available but is not in the 
current CCP4 distribution. We're also planning to improve the AMPLE 
documentation in the next few months and we'll include an example of use 
of this new coiled-coil mode at that time.


Best wishes

Dan

On 07/10/2019 22:33, Kajander, Tommi A wrote:

Hello,

We have a bit tricky case of coiled coil protein with good data (2.05Å) for 
dimeric coiled coil (dimer in AU)  - looks like AMPLE might be a way
to solve such cases, if you know other good programs please suggest (Better yet 
if there is a clear how-to manual)

Some technical tips on usage for generation of fragments for AMPLE would be of 
help, not completely on top of that… (running the QUARK server, the real 
sequence is bit over 200 aa so not sure what is the best approach here? 
Rosetta? any how-to for that.. well i am running Robetta fragments too).

with AMPLE can I do this with the online server or better run locally (need 
Rosetta installed I take it?)

Suppose I could try Rosetta-MR also, but to my recollection that requires some 
kind of a phaser hit first to be improved, and i dont think I am there.

Thanks for any comments,

Best,
Tommi






To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1


--
Prof Daniel Rigden
Institute of Integrative Biology
Room 101, Biosciences Building
University of Liverpool
Crown St., Liverpool, L69 7ZB

(+44) 151 795 4467
pcwww.liverpool.ac.uk/~drigden/



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP4BB&A=1