Re: [ccp4bb] Rmergicide Through Programming

[Graeme Winter]

HI Jacob

Yes, I got this - and I appreciate the benefit of Rmeas for dealing with 
measuring agreement for small-multiplicity observations. Having this *as well* 
is very useful and I agree Rmeas / Rpim / CC-half should be the primary 
“quality” statistics.

However, you asked if there is any reason to *keep* rather than *eliminate* 
Rmerge, and I offered one :o)

I do not see what harm there is reporting Rmerge, even if it is just used in 
the inner shell or just used to capture a flavour of the data set overall. I 
also appreciate that Rmeas converges to the same value for large multiplicity 
i.e.:

   Overall  InnerShell  OuterShell
Low resolution limit   39.02 39.02  1.39
High resolution limit   1.35  6.04  1.35

Rmerge  (within I+/I-) 0.080 0.057 2.871
Rmerge  (all I+ and I-)0.081 0.059 2.922
Rmeas (within I+/I-)   0.081 0.058 2.940
Rmeas (all I+ & I-)0.082 0.059 2.958
Rpim (within I+/I-)0.013 0.009 0.628
Rpim (all I+ & I-) 0.009 0.007 0.453
Rmerge in top intensity bin0.050- - 
Total number of observations 1265512 16212 53490
Total number unique17515   224  1280
Mean((I)/sd(I)) 29.7 104.3   1.5
Mn(I) half-set correlation CC(1/2) 1.000 1.000 0.778
Completeness   100.0  99.7 100.0
Multiplicity72.3  72.4  41.8

Anomalous completeness 100.0 100.0 100.0
Anomalous multiplicity  37.2  42.7  21.0
DelAnom correlation between half-sets  0.497 0.766-0.026
Mid-Slope of Anom Normal Probability   1.039   - -  

(this is a good case for Rpim & CC-half as resolution limit criteria)

If the statistics you want to use are there & some others also, what is the 
pressure to remove them? Surely we want to educate on how best to interpret the 
entire table above to get a fuller picture of the overall quality of the data? 
My 0th-order request would be to publish the three shells as above ;o)

Cheers Graeme



> On 4 Jul 2017, at 22:09, Keller, Jacob  wrote:
> 
> I suggested replacing Rmerge/sym/cryst with Rmeas, not Rpim. Rmeas is simply 
> (Rmerge * sqrt(n/n-1)) where n is the number of measurements of that 
> reflection. It's merely a way of correcting for the multiplicity-related 
> artifact of Rmerge, which is becoming even more of a problem with data sets 
> of increasing variability in multiplicity. Consider the case of comparing a 
> data set with a multiplicity of 2 versus one of 100: equivalent data quality 
> would yield Rmerges diverging by a factor of ~1.4. But this has all been 
> covered before in several papers. It can be and is reported in resolution 
> bins, so can used exactly as you say. So, why not "disappear" Rmerge from the 
> software?
> 
> The only reason I could come up with for keeping it is historical reasons or 
> comparisons to previous datasets, but anyway those comparisons would be 
> confounded by variabities in multiplicity and a hundred other things, so come 
> on, developers, just comment it out!
> 
> JPK
> 
> 
> 
> 
> -Original Message-
> From: graeme.win...@diamond.ac.uk [mailto:graeme.win...@diamond.ac.uk] 
> Sent: Tuesday, July 04, 2017 4:37 PM
> To: Keller, Jacob 
> Cc: ccp4bb@jiscmail.ac.uk
> Subject: Re: [ccp4bb] Rmergicide Through Programming
> 
> HI Jacob
> 
> Unbiased estimate of the true unmerged I/sig(I) of your data (I find this 
> particularly useful at low resolution) i.e. if your inner shell Rmerge is 10% 
> your data agree very poorly; if 2% says your data agree very well provided 
> you have sensible multiplicity… obviously depends on sensible interpretation. 
> Rpim hides this (though tells you more about the quality of average 
> measurement) 
> 
> Essentially, for I/sig(I) you can (by and large) adjust your sig(I) values 
> however you like if you were so inclined. You can only adjust Rmerge by 
> excluding measurements.
> 
> I would therefore defend that - amongst the other stats you enumerate below - 
> it still has a place 
> 
> Cheers Graeme
> 
>> On 4 Jul 2017, at 14:10, Keller, Jacob  wrote:
>> 
>>> Rmerge does contain information which complements the others. 
>> 
>> What information? I was trying to think of a counterargument to what I 
>> proposed, but could not think of a reason in the world to keep reporting it.
>> 
>> JPK
>> 
>> 
>> On 4 Jul 2017, at 12:00, Keller, Jacob 
>> > wrote:
>> 
>> Dear Crystallographers,
>> 
>> Having been repeatedly 

Re: [ccp4bb] Rmergicide Through Programming

[Keller, Jacob]

I asked an editor at a prominent journal to change the template file, 
mentioning the consensus among crystallographers about the matter, but they did 
not seem willing. Maybe someone with more name-recognition would be more 
effective. Or a circulated letter from a number of prominent crystallographers? 
Or…it really doesn’t matter that much?

JPK

From: Eleanor Dodson [mailto:eleanor.dod...@york.ac.uk]
Sent: Tuesday, July 04, 2017 5:37 PM
To: Keller, Jacob 
Cc: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Rmergicide Through Programming

Agree although i usually look to CC1/2.   Rmeas makes more sense than Rmerge 
but- most software reports both,  so cant you just provide Rmeas yourself   
Probably simpler to persuade journals to alter the Table 1 requirements than 
get all developers to comment those lines out!

Eleanor



On 4 July 2017 at 22:09, Keller, Jacob 
> wrote:
I suggested replacing Rmerge/sym/cryst with Rmeas, not Rpim. Rmeas is simply 
(Rmerge * sqrt(n/n-1)) where n is the number of measurements of that 
reflection. It's merely a way of correcting for the multiplicity-related 
artifact of Rmerge, which is becoming even more of a problem with data sets of 
increasing variability in multiplicity. Consider the case of comparing a data 
set with a multiplicity of 2 versus one of 100: equivalent data quality would 
yield Rmerges diverging by a factor of ~1.4. But this has all been covered 
before in several papers. It can be and is reported in resolution bins, so can 
used exactly as you say. So, why not "disappear" Rmerge from the software?

The only reason I could come up with for keeping it is historical reasons or 
comparisons to previous datasets, but anyway those comparisons would be 
confounded by variabities in multiplicity and a hundred other things, so come 
on, developers, just comment it out!

JPK




-Original Message-
From: graeme.win...@diamond.ac.uk 
[mailto:graeme.win...@diamond.ac.uk]
Sent: Tuesday, July 04, 2017 4:37 PM
To: Keller, Jacob >
Cc: ccp4bb@jiscmail.ac.uk
Subject: Re: [ccp4bb] Rmergicide Through Programming

HI Jacob

Unbiased estimate of the true unmerged I/sig(I) of your data (I find this 
particularly useful at low resolution) i.e. if your inner shell Rmerge is 10% 
your data agree very poorly; if 2% says your data agree very well provided you 
have sensible multiplicity… obviously depends on sensible interpretation. Rpim 
hides this (though tells you more about the quality of average measurement)

Essentially, for I/sig(I) you can (by and large) adjust your sig(I) values 
however you like if you were so inclined. You can only adjust Rmerge by 
excluding measurements.

I would therefore defend that - amongst the other stats you enumerate below - 
it still has a place

Cheers Graeme

> On 4 Jul 2017, at 14:10, Keller, Jacob 
> > wrote:
>
>> Rmerge does contain information which complements the others.
>
> What information? I was trying to think of a counterargument to what I 
> proposed, but could not think of a reason in the world to keep reporting it.
>
> JPK
>
>
> On 4 Jul 2017, at 12:00, Keller, Jacob 
> >>
>  wrote:
>
> Dear Crystallographers,
>
> Having been repeatedly chagrinned about the continued use and reporting of 
> Rmerge rather than Rmeas or similar, I thought of a potential way to promote 
> the change: what if merging programs would completely omit Rmerge/cryst/sym? 
> Is there some reason to continue to report these stats, or are they just 
> grandfathered into the software? I doubt that any journal or crystallographer 
> would insist on reporting Rmerge per se. So, I wonder what developers would 
> think about commenting out a few lines of their code, seeing what happens? 
> Maybe a comment to the effect of "Rmerge is now deprecated; use Rmeas" would 
> be useful as well. Would something catastrophic happen?
>
> All the best,
>
> Jacob Keller
>
> ***
> Jacob Pearson Keller, PhD
> Research Scientist
> HHMI Janelia Research Campus / Looger lab
> Phone: (571)209-4000 x3159
> Email: 
> kell...@janelia.hhmi.org>
> ***
>
>
> --
> 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 

Re: [ccp4bb] Rmergicide Through Programming

[Francis Reyes]

I find the lack of reporting statistics of the low resolution bins unfortunate!

Most statistics in Table 1 report  the average across all resolutions or just 
the high resolution reflection shell.  

With respect to Rmerge, the agreement between the most intense (low resolution) 
symmetry related reflections is very telling to the quality of the merged data 
in my opinion (radiation damage, absorption errors, very weakly exposed 
crystal, other strange systematic errors, etc). 


F


On Jul 4, 2017, at 4:37 PM, Graeme Winter  wrote:

> Unbiased estimate of the true unmerged I/sig(I) of your data (I find this 
> particularly useful at low resolution) i.e. if your inner shell Rmerge is 10% 
> your data agree very poorly; if 2% says your data agree very well provided 
> you have sensible multiplicity… obviously depends on sensible interpretation.

Re: [ccp4bb] Rmergicide Through Programming

[Eleanor Dodson]

Agree although i usually look to CC1/2.   Rmeas makes more sense than
Rmerge but- most software reports both,  so cant you just provide Rmeas
yourself   Probably simpler to persuade journals to alter the Table 1
requirements than get all developers to comment those lines out!

Eleanor



On 4 July 2017 at 22:09, Keller, Jacob  wrote:

> I suggested replacing Rmerge/sym/cryst with Rmeas, not Rpim. Rmeas is
> simply (Rmerge * sqrt(n/n-1)) where n is the number of measurements of that
> reflection. It's merely a way of correcting for the multiplicity-related
> artifact of Rmerge, which is becoming even more of a problem with data sets
> of increasing variability in multiplicity. Consider the case of comparing a
> data set with a multiplicity of 2 versus one of 100: equivalent data
> quality would yield Rmerges diverging by a factor of ~1.4. But this has all
> been covered before in several papers. It can be and is reported in
> resolution bins, so can used exactly as you say. So, why not "disappear"
> Rmerge from the software?
>
> The only reason I could come up with for keeping it is historical reasons
> or comparisons to previous datasets, but anyway those comparisons would be
> confounded by variabities in multiplicity and a hundred other things, so
> come on, developers, just comment it out!
>
> JPK
>
>
>
>
> -Original Message-
> From: graeme.win...@diamond.ac.uk [mailto:graeme.win...@diamond.ac.uk]
> Sent: Tuesday, July 04, 2017 4:37 PM
> To: Keller, Jacob 
> Cc: ccp4bb@jiscmail.ac.uk
> Subject: Re: [ccp4bb] Rmergicide Through Programming
>
> HI Jacob
>
> Unbiased estimate of the true unmerged I/sig(I) of your data (I find this
> particularly useful at low resolution) i.e. if your inner shell Rmerge is
> 10% your data agree very poorly; if 2% says your data agree very well
> provided you have sensible multiplicity… obviously depends on sensible
> interpretation. Rpim hides this (though tells you more about the quality of
> average measurement)
>
> Essentially, for I/sig(I) you can (by and large) adjust your sig(I) values
> however you like if you were so inclined. You can only adjust Rmerge by
> excluding measurements.
>
> I would therefore defend that - amongst the other stats you enumerate
> below - it still has a place
>
> Cheers Graeme
>
> > On 4 Jul 2017, at 14:10, Keller, Jacob  wrote:
> >
> >> Rmerge does contain information which complements the others.
> >
> > What information? I was trying to think of a counterargument to what I
> proposed, but could not think of a reason in the world to keep reporting it.
> >
> > JPK
> >
> >
> > On 4 Jul 2017, at 12:00, Keller, Jacob > wrote:
> >
> > Dear Crystallographers,
> >
> > Having been repeatedly chagrinned about the continued use and reporting
> of Rmerge rather than Rmeas or similar, I thought of a potential way to
> promote the change: what if merging programs would completely omit
> Rmerge/cryst/sym? Is there some reason to continue to report these stats,
> or are they just grandfathered into the software? I doubt that any journal
> or crystallographer would insist on reporting Rmerge per se. So, I wonder
> what developers would think about commenting out a few lines of their code,
> seeing what happens? Maybe a comment to the effect of "Rmerge is now
> deprecated; use Rmeas" would be useful as well. Would something
> catastrophic happen?
> >
> > All the best,
> >
> > Jacob Keller
> >
> > ***
> > Jacob Pearson Keller, PhD
> > Research Scientist
> > HHMI Janelia Research Campus / Looger lab
> > Phone: (571)209-4000 x3159
> > Email: kell...@janelia.hhmi.org
> > ***
> >
> >
> > --
> > 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
> >
>
>

Re: [ccp4bb] Rmergicide Through Programming

[Keller, Jacob]

I suggested replacing Rmerge/sym/cryst with Rmeas, not Rpim. Rmeas is simply 
(Rmerge * sqrt(n/n-1)) where n is the number of measurements of that 
reflection. It's merely a way of correcting for the multiplicity-related 
artifact of Rmerge, which is becoming even more of a problem with data sets of 
increasing variability in multiplicity. Consider the case of comparing a data 
set with a multiplicity of 2 versus one of 100: equivalent data quality would 
yield Rmerges diverging by a factor of ~1.4. But this has all been covered 
before in several papers. It can be and is reported in resolution bins, so can 
used exactly as you say. So, why not "disappear" Rmerge from the software?

The only reason I could come up with for keeping it is historical reasons or 
comparisons to previous datasets, but anyway those comparisons would be 
confounded by variabities in multiplicity and a hundred other things, so come 
on, developers, just comment it out!

JPK




-Original Message-
From: graeme.win...@diamond.ac.uk [mailto:graeme.win...@diamond.ac.uk] 
Sent: Tuesday, July 04, 2017 4:37 PM
To: Keller, Jacob 
Cc: ccp4bb@jiscmail.ac.uk
Subject: Re: [ccp4bb] Rmergicide Through Programming

HI Jacob

Unbiased estimate of the true unmerged I/sig(I) of your data (I find this 
particularly useful at low resolution) i.e. if your inner shell Rmerge is 10% 
your data agree very poorly; if 2% says your data agree very well provided you 
have sensible multiplicity… obviously depends on sensible interpretation. Rpim 
hides this (though tells you more about the quality of average measurement) 

Essentially, for I/sig(I) you can (by and large) adjust your sig(I) values 
however you like if you were so inclined. You can only adjust Rmerge by 
excluding measurements.

I would therefore defend that - amongst the other stats you enumerate below - 
it still has a place 

Cheers Graeme

> On 4 Jul 2017, at 14:10, Keller, Jacob  wrote:
> 
>> Rmerge does contain information which complements the others. 
> 
> What information? I was trying to think of a counterargument to what I 
> proposed, but could not think of a reason in the world to keep reporting it.
> 
> JPK
> 
> 
> On 4 Jul 2017, at 12:00, Keller, Jacob 
> > wrote:
> 
> Dear Crystallographers,
> 
> Having been repeatedly chagrinned about the continued use and reporting of 
> Rmerge rather than Rmeas or similar, I thought of a potential way to promote 
> the change: what if merging programs would completely omit Rmerge/cryst/sym? 
> Is there some reason to continue to report these stats, or are they just 
> grandfathered into the software? I doubt that any journal or crystallographer 
> would insist on reporting Rmerge per se. So, I wonder what developers would 
> think about commenting out a few lines of their code, seeing what happens? 
> Maybe a comment to the effect of "Rmerge is now deprecated; use Rmeas" would 
> be useful as well. Would something catastrophic happen?
> 
> All the best,
> 
> Jacob Keller
> 
> ***
> Jacob Pearson Keller, PhD
> Research Scientist
> HHMI Janelia Research Campus / Looger lab
> Phone: (571)209-4000 x3159
> Email: kell...@janelia.hhmi.org
> ***
> 
> 
> -- 
> 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
> 

[ccp4bb] [off-topic] PhD position available

[Harmer, Nicholas]

Dear all,


A BBSRC funded PhD position is available in my laboratory in Exeter, focusing 
on enzymes for synthetic biology. The work is most likely going to be more 
enzymology than structural work, but please pass this on to any candidates who 
might be interested.


Full details are available at 
http://www.exeter.ac.uk/studying/funding/award/?id=2643


Kind regards,


Nic Harmer

University of Exeter

Re: [ccp4bb] Rmergicide Through Programming

[Graeme Winter]

HI Jacob

Unbiased estimate of the true unmerged I/sig(I) of your data (I find this 
particularly useful at low resolution) i.e. if your inner shell Rmerge is 10% 
your data agree very poorly; if 2% says your data agree very well provided you 
have sensible multiplicity… obviously depends on sensible interpretation. Rpim 
hides this (though tells you more about the quality of average measurement) 

Essentially, for I/sig(I) you can (by and large) adjust your sig(I) values 
however you like if you were so inclined. You can only adjust Rmerge by 
excluding measurements.

I would therefore defend that - amongst the other stats you enumerate below - 
it still has a place 

Cheers Graeme

> On 4 Jul 2017, at 14:10, Keller, Jacob  wrote:
> 
>> Rmerge does contain information which complements the others. 
> 
> What information? I was trying to think of a counterargument to what I 
> proposed, but could not think of a reason in the world to keep reporting it.
> 
> JPK
> 
> 
> On 4 Jul 2017, at 12:00, Keller, Jacob 
> > wrote:
> 
> Dear Crystallographers,
> 
> Having been repeatedly chagrinned about the continued use and reporting of 
> Rmerge rather than Rmeas or similar, I thought of a potential way to promote 
> the change: what if merging programs would completely omit Rmerge/cryst/sym? 
> Is there some reason to continue to report these stats, or are they just 
> grandfathered into the software? I doubt that any journal or crystallographer 
> would insist on reporting Rmerge per se. So, I wonder what developers would 
> think about commenting out a few lines of their code, seeing what happens? 
> Maybe a comment to the effect of "Rmerge is now deprecated; use Rmeas" would 
> be useful as well. Would something catastrophic happen?
> 
> All the best,
> 
> Jacob Keller
> 
> ***
> Jacob Pearson Keller, PhD
> Research Scientist
> HHMI Janelia Research Campus / Looger lab
> Phone: (571)209-4000 x3159
> Email: kell...@janelia.hhmi.org
> ***
> 
> 
> -- 
> 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
> 

[ccp4bb] New Position: Product Development Scientist at TTP Labtech (UK)

[Melanie Adams-Cioaba]

Dear All,


Please find the description for a new recruitment below. Any inquiries or
applications should be directed to chloe.kyria...@ttplabtech.com.


Kind regards,

Melanie



*Product Development Scientist*



*Description*

TTP Labtech is looking for an experienced Scientist to help develop new
sample preparation technology that will enable emerging methods of
determining biomolecular structures.



Based near Cambridge, UK, TTP Labtech is a global supplier of innovative
products for accelerating drug development, combining the best science with
first-rate engineering. We design and manufacture a wide range of liquid
dispensing equipment, sample management systems and fluorescence detection
instruments. As part of the TTP Group, Europe’s leading technology
development company, TTP Labtech enjoys an enviable reputation for
innovation, reliability and quality.



The successful candidate will help shape the development of a range of new
products as a key member of the development team. Responsibilities will
include:



   - Understanding product requirements through collaboration with
   structural biology customers
   - Communicating customer needs and specifications to design engineers,
   research physicists and software developers
   - Assisting with testing of rigs and prototypes to determine critical
   process parameters
   - Planning and running experiments, analysing results and preparing
   summary reports
   - Characterising the performance of development prototypes
   - Managing placements with customer development partners, including
   training, analysis and interpretation of customer data and providing
   feedback on the customer experience to the development team
   - In the medium term, engaging with early customers to provide
   applications advice
   - Advising on the direction of further development as a product expert
   - Preparing written material for marketing, such as posters and
   applications notes



Throughout the product lifecycle, you will be working as a member of a
multidisciplinary project team, with increasing product management
responsibilities. Some foreign travel will be required, visiting customers
and attending conferences and exhibitions. The position is based at our
campus near Cambridge, UK so UK-based applicants are preferred.





*Essential Qualifications and Skills: *

   - A 1st or 2:1 degree in a biological science from a leading university.
   A PhD qualification in a relevant field is strongly preferred, although
   equivalent experience will be considered.
   - At least 3 years’ experience in a structural biology  research
   environment
   - Good understanding of the behaviour of protein molecules
   - Good wet laboratory experience and investigative/analytical skills
   - Familiarity with protein crystallography and current trends in
   determining protein structures
   - Creative thinking and logical problem solving
   - Ability to analyse complex technical data
   - First class verbal and written communication skills, fully proficient
   in Word, Excel and PowerPoint
   - Organised, self-motivated and a good team-worker



In addition, experience of the following would be beneficial:

   - Understanding of material science and physical processes Experience
   with handling of cryogenic samples
   - Experience of working in a commercial environment including
   interaction with customers



*The rewards*

In addition to competitive salary and benefits, the successful candidate
will enjoy the satisfaction of creating new technology, for developing the
drug therapies of tomorrow.



TTP Labtech encourages an entrepreneurial culture with a light-weight
management style and individuals are encouraged to drive the direction of
their own work. The business is owned by employees and ex-employees so
staff can share in the success of the company through share ownership plans
as well as profit-sharing schemes.



*If interested, please apply to *chloe.kyria...@ttplabtech.com* and include
a cover letter with your application*

[ccp4bb] long loop

[dongxiaofei]

Dear ALL,
I want to make a protein crystal,but there is a long loop between domains of 
protein , which contains two small domains owning about 40 amino acids 
respectively and a loop about 70 amino acids.
Loop is so long and flexible ,but I don't want to delete some fragments,because 
it may be  important for protein's function of a histone demethylase.
Besides, the  surface charge of  protein is whole negative .
I have tried a long time but it is hard to me to get crystal.
 

Would be very grateful for any advice!

Thanks

Dong Xiao

 

 

Re: [ccp4bb] ccp4i2 crashes on start

[Stuart McNicholas]

Dear Johannes,
   Many apologies, this behaviour should certainly not be expected. The
cause could be quite difficult to determine, I shall start by installing a
Ubuntu virtualbox myself.

Best wishes,
Stuart

On 4 July 2017 at 13:46, Johannes Cramer  wrote:

> Dear CCP4 bb,
>
> I would like to use ccp4i2, but every time I try to start it via command
> line, I get the following error message:
>
> Running CCP4i2 browser from: /home/cramejo/programs/ccp4-7.0/share/ccp4i2
>> Python 2.7.10 (default, Aug 28 2015, 12:10:46)
>> [GCC 4.8.2 20140120 (Red Hat 4.8.2-15)]
>> Qt version 4.8.7
>>
>> 440 367
>> Segmentation fault (core dumped)
>
>
> Has anyone experienced this behavior? How (where) can I get a more
> detailed log file? ccp4i (old GUI) works perfectly fine, but the session
> log that is accessible via the interface is only valid for the current
> session.
> I am running 64 bit Kubuntu 10.16 on a windows host virtualbox.
>
> Cheers,
> Johannes
>

Re: [ccp4bb] Rmergicide Through Programming

[Keller, Jacob]

>Rmerge does contain information which complements the others. 

What information? I was trying to think of a counterargument to what I 
proposed, but could not think of a reason in the world to keep reporting it.

JPK


On 4 Jul 2017, at 12:00, Keller, Jacob 
> wrote:

Dear Crystallographers,

Having been repeatedly chagrinned about the continued use and reporting of 
Rmerge rather than Rmeas or similar, I thought of a potential way to promote 
the change: what if merging programs would completely omit Rmerge/cryst/sym? Is 
there some reason to continue to report these stats, or are they just 
grandfathered into the software? I doubt that any journal or crystallographer 
would insist on reporting Rmerge per se. So, I wonder what developers would 
think about commenting out a few lines of their code, seeing what happens? 
Maybe a comment to the effect of "Rmerge is now deprecated; use Rmeas" would be 
useful as well. Would something catastrophic happen?

All the best,

Jacob Keller

***
Jacob Pearson Keller, PhD
Research Scientist
HHMI Janelia Research Campus / Looger lab
Phone: (571)209-4000 x3159
Email: kell...@janelia.hhmi.org
***


-- 
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

[ccp4bb] ccp4i2 crashes on start

[Johannes Cramer]

Dear CCP4 bb,

I would like to use ccp4i2, but every time I try to start it via command
line, I get the following error message:

Running CCP4i2 browser from: /home/cramejo/programs/ccp4-7.0/share/ccp4i2
> Python 2.7.10 (default, Aug 28 2015, 12:10:46)
> [GCC 4.8.2 20140120 (Red Hat 4.8.2-15)]
> Qt version 4.8.7
>
> 440 367
> Segmentation fault (core dumped)


Has anyone experienced this behavior? How (where) can I get a more detailed
log file? ccp4i (old GUI) works perfectly fine, but the session log that is
accessible via the interface is only valid for the current session.
I am running 64 bit Kubuntu 10.16 on a windows host virtualbox.

Cheers,
Johannes

Re: [ccp4bb] Rmergicide Through Programming

[Graeme Winter]

Jacob

Rmerge does contain information which complements the others. I'd prefer it 
remains but agree it needs to be properly understood alongside the others you 
mention

Cheers Graeme

On 4 Jul 2017, at 12:00, Keller, Jacob 
> wrote:

Dear Crystallographers,

Having been repeatedly chagrinned about the continued use and reporting of 
Rmerge rather than Rmeas or similar, I thought of a potential way to promote 
the change: what if merging programs would completely omit Rmerge/cryst/sym? Is 
there some reason to continue to report these stats, or are they just 
grandfathered into the software? I doubt that any journal or crystallographer 
would insist on reporting Rmerge per se. So, I wonder what developers would 
think about commenting out a few lines of their code, seeing what happens? 
Maybe a comment to the effect of “Rmerge is now deprecated; use Rmeas” would be 
useful as well. Would something catastrophic happen?

All the best,

Jacob Keller

***
Jacob Pearson Keller, PhD
Research Scientist
HHMI Janelia Research Campus / Looger lab
Phone: (571)209-4000 x3159
Email: kell...@janelia.hhmi.org
***


-- 
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

[ccp4bb] Rmergicide Through Programming

[Keller, Jacob]

Dear Crystallographers,

Having been repeatedly chagrinned about the continued use and reporting of 
Rmerge rather than Rmeas or similar, I thought of a potential way to promote 
the change: what if merging programs would completely omit Rmerge/cryst/sym? Is 
there some reason to continue to report these stats, or are they just 
grandfathered into the software? I doubt that any journal or crystallographer 
would insist on reporting Rmerge per se. So, I wonder what developers would 
think about commenting out a few lines of their code, seeing what happens? 
Maybe a comment to the effect of "Rmerge is now deprecated; use Rmeas" would be 
useful as well. Would something catastrophic happen?

All the best,

Jacob Keller

***
Jacob Pearson Keller, PhD
Research Scientist
HHMI Janelia Research Campus / Looger lab
Phone: (571)209-4000 x3159
Email: kell...@janelia.hhmi.org
***

[ccp4bb] Postdoctoral protein crystallography position at The Institute of Cancer Research - Deadline approaching

[Rob Van Montfort]

The Institute of Cancer Research, London, is one of the world’s most 
influential cancer research institutes, with an outstanding record of 
achievement dating back more than 100 years. We provided the first convincing 
evidence that DNA damage is the basic cause of cancer, laying the foundation 
for the now universally accepted idea that cancer is a genetic disease. Today, 
The Institute of Cancer Research (ICR) leads the world at isolating 
cancer-related genes and discovering new targeted drugs for personalised cancer 
treatment. Under the leadership of our Chief Executive, Professor Paul Workman 
FRS, the ICR is ranked as the UK’s leading academic research centre. Together 
with our partner The Royal Marsden, we are rated in the top four cancer centres 
globally. The ICR is committed to attracting, developing and retaining the best 
minds in the world to join us in our mission – to make the discoveries that 
defeat cancer.
The Cancer Research UK Cancer Therapeutics Unit (CTU), within the Division of 
Cancer Therapeutics, is a multidisciplinary 'bench to bedside' centre, 
comprising around 160 staff dedicated to the discovery and development of novel 
therapeutics for the treatment of cancer. The Cancer Therapeutics Unit’s 
exciting goal is to discover high quality small molecule drug candidates and to 
progress these to clinical trial. All the scientific disciplines are in place 
to make this possible, including medicinal chemistry, biology, drug metabolism 
and clinical specialists who focus on new molecular targets emerging from human 
genome and ground breaking cell biology research.

A postdoctoral position is available in Dr Rob van Montfort’s Hit Discovery and 
Structural Design Team within the CTU. The Post-doc will be involved in 
high-throughput X-ray crystallography, fragment-based screening and 
structure-based drug design and will be responsible for protein expression, 
purification, crystallisation, structure determination and structural analysis 
of protein-ligand complexes from one of the CTU’s drug discovery programmes. 
The successful candidate will also be part of the Division of Structural 
Biology, in which the crystallographers in Dr van Montfort’s team are embedded, 
and will have access to state of the art crystallisation facilities, in-house 
X-ray sources and excellent access to synchrotrons. The successful candidate 
will interact closely with the biology, computational chemistry and medicinal 
chemistry teams at the CTU, and will therefore be expected to work across the 
two sites in Chelsea, London and Sutton, Surrey.

Applicants must have a PhD in a biological or physical science, and experience 
in macromolecular crystallography (to include protein biochemistry, protein 
crystallisation, & protein crystallography). Experience in molecular biology, 
protein expression in insect cells, structure-based drug design, and/or 
biophysics will be an advantage.

The starting salary will be in the range £29,960 to £36,830 p.a. inclusive 
(based on previous post-doctoral experience) and the post is offered on a fixed 
term contract of 2 years. Informal enquiries to 
rob.vanmontf...@icr.ac.uk or 
yann-vai.lebi...@icr.ac.uk. Closing date is 
July 9th 2017.

Please DO NOT send your application to Dr van Montfort or Dr Le Bihan; CVs must 
be submitted via our website: www.icr.ac.uk.


Dr. Rob van Montfort
Team Leader Hit Discovery and Structural Design
Joint Interim Head of Division of Structural Biology
Divisions of Cancer Therapeutics and Structural Biology
The Institute of Cancer Research
15 Cotswold Road
Sutton SM2 5NG
UK

Tel:
+44-(0)20-8722-4364 (Sutton)
+44-(0)20-7153-5142 (Chelsea)
Email: rob.vanmontf...@icr.ac.uk







The Institute of Cancer Research: Royal Cancer Hospital, a charitable Company 
Limited by Guarantee, Registered in England under Company No. 534147 with its 
Registered Office at 123 Old Brompton Road, London SW7 3RP.

This e-mail message is confidential and for use by the addressee only.  If the 
message is received by anyone other than the addressee, please return the 
message to the sender by replying to it and then delete the message from your 
computer and network.

[ccp4bb] POSTDOCTORAL POSITION IN MILAN

[Louise Gourlay]

STRUCTURAL BIOLOGY POSTDOCTORAL POSITION IN MILAN (ITALY)

A 2/3 year Postdoc position is available in the Structural Vaccinology division 
of the Structural Biology Unit run by Prof. Martino Bolognesi at the Department 
of Biosciences (University of Milan). The hired Postdoc will carry out the 
recombinant production, crystallisation and 3D structure determination of 
protein antigens from two parasites, Schistosoma mansoni and Trypanosoma cruzi, 
responsible for Schistosomiasis and Chagas disease, respectively. Both 
pathogens are two of several pathogens that are emerging in Lombardy, one of 
the most affluent areas of Italy, due to an increase in immigration. The aim of 
the project is to develop new diagnostic tests for on-site use in hospitals and 
refugee centres.
In this context, 3D structures will serve as the basis for in silico 
epitope mapping methods to guide subsequence computer-aided epitope peptide 
design for immunodiagnostic development based on epitope peptide microarrays. 
The project is highly multi-disciplinary and involves nine partners from the 
Lombardy region, including academic and industrial partners and is funded by 
the Lombardy Council.
The candidate must have a PhD (in biochemistry or similar) and a good 
background in molecular biology and recombinant protein production and 
purification techniques. Experience in protein crystallography and immunology 
will be of advantage. The candidate must work well with others. Participation 
in group meetings, departmental seminars and attendance at international 
conferences and courses will be required. The candidate must be highly 
motivated. Good written and spoken English is essential. 

For more information please contact: Dr. Louise Gourlay 
(louise.gour...@unimi.it ) or Prof. Bolognesi 
(martino.bologn...@unimi.it ).
Position start date: negotiable (no later than 1st October).


Louise J. Gourlay (PhD)
Structural Biology Unit
Dep. Biosciences
University of Milano
Via Celoria 26
20133 Milano
Italy
Tel: + 39 (02) 50314914 
http://bioscienze.bio/ricerca/laboratorio-di-biologia-strutturale/