Re: [ccp4bb] new ContaMiner features

[Marcin Wojdyr]

On 2 December 2017 at 00:31, Ivan Shabalin
 wrote:

>  Instead, we just used the search of the
> unit cell parameters in the PDB, which is much faster (but works only if the
> structure of this particular artifact in the same SpGr is in PDB! otherwise,
> one should use ContaMiner or similar service). This feature is implemented
> in HKL3000, but it can also be done quickly on the PDB webpage.

Even better, one can use SAUC which finds also matches in different
space groups by comparing dimensions of the Niggli (reduced) cell.
http://iterate.sourceforge.net/sauc/

Re: [ccp4bb] new ContaMiner features

[Diana Tomchick]

It is also possible that it co-purifies via a nickel IMAC column purification 
step. The affinity of many E. coli proteins for such columns is well known.

Diana

**
Diana R. Tomchick
Professor
Departments of Biophysics and Biochemistry
University of Texas Southwestern Medical Center
5323 Harry Hines Blvd.
Rm. ND10.214A
Dallas, TX 75390-8816
diana.tomch...@utsouthwestern.edu
(214) 645-6383 (phone)
(214) 645-6353 (fax)

On Dec 1, 2017, at 6:31 PM, Ivan Shabalin  
wrote:

Dear All,

To add my voice to those who wrote crystallization artifacts happen - we just 
witnessed one today. A postdoc from another lab tried crystallizing a protein 
for months. Today, during data collection from his poorly diffracting crystals, 
one of our guys (Dr. Porebski) scaled the data and checked if there is a 
structure with the same Sp Gr and unit cell parameters in the PDB. And there 
was one - 4ZNZ (Escherichia coli carbonic anhydrase (YadF) in complex with Zn - 
an artifact of purification), deposited by our group two years ago. Quick 
molecular replacement showed that it is indeed the protein we had in the beam 
today.

The protein looked good on the SDS gel. The band for YadF was definitely less 
than 1% of the protein sample (less than one percent!!! if the gel would not be 
overloaded, nobody would see the band), but it still crystallized. We speculate 
that YadF from Escherichia coli was co-purified with the target protein due to 
relatively strong protein-protein interactions despite multiple purification 
steps.

We did not use ContaMiner, though. Instead, we just used the search of the unit 
cell parameters in the PDB, which is much faster (but works only if the 
structure of this particular artifact in the same SpGr is in PDB! otherwise, 
one should use ContaMiner or similar service). This feature is implemented in 
HKL3000, but it can also be done quickly on the PDB webpage. The procedure, as 
well as cases with other crystallization artifacts, is described in:

Protein purification and crystallization artifacts: The tale usually not told. 
(2016) Protein Sci. 25: 720-733

Today's example clearly shows that depositing these artifacts can greatly help 
others (it took just a few minutes to realize we had an artifact). Therefore, I 
would like to encourage everyone to deposit their artifacts to the PDB, 
especially if these artifacts were crystallized with unit cell parameters not 
reported previously. An increase in the size of the library of crystallization 
artifact structures deposited to the PDB can make troubleshooting of new 
artifacts much easier, and save much effort for those who are new (or not very 
new!) to such cases.


With best regards,
Ivan Shabalin, Ph.D.
Research Scientist,
Department of Molecular Physiology and Biological Physics,
University of Virginia,
1340 Jefferson Park Avenue, Pinn Hall,Room 4223,
Charlottesville, VA 22908

On 11/23/2017 02:35 PM, r...@mrc-lmb.cam.ac.uk wrote:
> Dear Stefan,
> Just a couple of thoughts:
> - first of all I think that Gerard is absolutely right, it would have been
> nice to raise such issues first with the developers. In my experience,
> Staraniso does a fantastic job if used correctly.
> - but if you're OK with public trials, may I ask: why on Earth would anybody
> need ContaMiner? Are you trying to offer some sort of computational cure for
> sloppy biochemistry? There is zero point in crystallizing crap samples, sorry
> to say this. In my 17 or so years in Strubi I've never heard of anybody
> crystallizing a "contaminant", being it a purification tag or whatever.
> I suppose this might have happened to somebody you know, hence the motivation
> to spend time on the bizarre ContaMiner. Which is a pity, a silly outcome
> would only teach people to do their job (or train their robots) properly.
> Best wishes,
> Radu






UT Southwestern


Medical Center



The future of medicine, today.

Re: [ccp4bb] new ContaMiner features

[Ivan Shabalin]

Dear All,

To add my voice to those who wrote crystallization artifacts happen - we 
just witnessed one today. A postdoc from another lab tried crystallizing 
a protein for months. Today, during data collection from his poorly 
diffracting crystals, one of our guys (Dr. Porebski) scaled the data and 
checked if there is a structure with the same Sp Gr and unit cell 
parameters in the PDB. And there was one - 4ZNZ (Escherichia coli 
carbonic anhydrase (YadF) in complex with Zn - an artifact of 
purification), deposited by our group two years ago. Quick molecular 
replacement showed that it is indeed the protein we had in the beam today.


The protein looked good on the SDS gel. The band for YadF was definitely 
less than 1% of the protein sample (less than one percent!!! if the gel 
would not be overloaded, nobody would see the band), but it still 
crystallized. We speculate that YadF from Escherichia coli was 
co-purified with the target protein due to relatively strong 
protein-protein interactions despite multiple purification steps.


We did not use ContaMiner, though. Instead, we just used the search of 
the unit cell parameters in the PDB, which is much faster (but works 
only if the structure of this particular artifact in the same SpGr is in 
PDB! otherwise, one should use ContaMiner or similar service). This 
feature is implemented in HKL3000, but it can also be done quickly on 
the PDB webpage. The procedure, as well as cases with other 
crystallization artifacts, is described in:


Protein purification and crystallization artifacts: The tale usually not 
told. (2016) Protein Sci. 25: 720-733


Today's example clearly shows that depositing these artifacts can 
greatly help others (it took just a few minutes to realize we had an 
artifact). Therefore, I would like to encourage everyone to deposit 
their artifacts to the PDB, especially if these artifacts were 
crystallized with unit cell parameters not reported previously. An 
increase in the size of the library of crystallization artifact 
structures deposited to the PDB can make troubleshooting of new 
artifacts much easier, and save much effort for those who are new (or 
not very new!) to such cases.



With best regards,
Ivan Shabalin, Ph.D.
Research Scientist,
Department of Molecular Physiology and Biological Physics,
University of Virginia,
1340 Jefferson Park Avenue, Pinn Hall,Room 4223,
Charlottesville, VA 22908

On 11/23/2017 02:35 PM, r...@mrc-lmb.cam.ac.uk wrote:

Dear Stefan,

Just a couple of thoughts:

- first of all I think that Gerard is absolutely right, it would have been
nice to raise such issues first with the developers. In my experience,
Staraniso does a fantastic job if used correctly.

- but if you're OK with public trials, may I ask: why on Earth would anybody
need ContaMiner? Are you trying to offer some sort of computational cure for
sloppy biochemistry? There is zero point in crystallizing crap samples, sorry
to say this. In my 17 or so years in Strubi I've never heard of anybody
crystallizing a "contaminant", being it a purification tag or whatever.

I suppose this might have happened to somebody you know, hence the motivation
to spend time on the bizarre ContaMiner. Which is a pity, a silly outcome
would only teach people to do their job (or train their robots) properly.

Best wishes,

Radu

Re: [ccp4bb] new ContaMiner features

[Stefan Arold]

Hi Radu
thank you for your nice message - it is indeed unclear how often these
cases happen. From our side it was nice to hear that people acknowledged
the usefulness of our tool - which can also be used to rule out (known)
contaminant crystals.
Given that our ContaMiner will (by its design) not be cited much
(contaminants don't get published), such positive feedback is our source of
happiness.

With best wishes,
Stefan

On 27 November 2017 at 12:35,  wrote:

> Hi Stefan,
>
> I also owe you an apology for my bad choice of words. One can debate about
> usefulness, but Pavel is right, the software is not "bizarre". And, as
> several
> people pointed out, it certainly addresses a need (which I didn't know
> about).
> Mea culpa.
>
> Best wishes,
>
> Radu
>
>
> > Dear Gerard
> >
> > I am really sorry that my badly formulated 'final word of warning' has
> made
> > you and others spend much time for composing well-formulated replies. I
> was
> > at PX1 yesterday, and Leo reminded me of the issue, hence I included it
> > into my message.
> > You are absolutely right that reports of anomalies should go to the
> > developers - however the issue here is already known (as shown in the
> > STARANISO Warning message) and cannot be solved by us at the ContaMiner
> > level. Given the popularity of Staraniso, I just wanted to inform our
> users
> > that this particular issue is propagated into the ContaMiner results. I
> > should have worded it more carefully.
> >
> > Many thanks to Leo and Pierre for helping explain!
> >
> > With best wishes
> > Stefan
> >
> >
> >
> > On 24 November 2017 at 13:07, Gerard Bricogne 
> > wrote:
> >
> >> Dear Radu,
> >>
> >>  I would not want to take undue advantage of this already
> >> voluminous thread, but your PS takes us into a different direction,
> >> namely the whole myth-ridden topic of "weak data" - but that will be
> >> for another thread, another time ;-) .
> >>
> >>
> >>  With best wishes,
> >>
> >>   Gerard.
> >>
> >> --
> >> On Fri, Nov 24, 2017 at 01:02:08AM -, r...@mrc-lmb.cam.ac.uk wrote:
> >> > Hi Leo,
> >> >
> >> > I agree that the horror beamline stories you describe are far too
> common.
> >> > Unfortunately, they start earlier, in the wet lab or even before.
> >> Exactly the
> >> > same attitude (careless construct design, crystallising whatever
> "dirty"
> >> > samples, not bothering optimising cryoprotection and so on) leads to
> >> wasting a
> >> > lot of resources, including synchrotron time. In some cases, as people
> >> pointed
> >> > out, problems such as contaminations (and even more so anisotropic
> data,
> >> for
> >> > the matter) are unavoidable. But too often, as we all know, it's
> simply
> >> bad
> >> > practice, lack of training etc. Web servers can only help up to a
> >> point...
> >> >
> >> > Best wishes,
> >> >
> >> > Radu
> >> > PS: At least, one day, maximum-likelihood refinement programs will
> deal
> >> with
> >> > weak data satisfactorily :-) Nobody likes to throw data away.
> >> >
> >> >
> >> > > Dear all,
> >> > >
> >> > > to join Pierre's comments on what 'strange' things happen at the
> >> beamlines...
> >> > > yet not too strange for (too) many people: huge screening of salt
> >> crystals,
> >> > > complete data collection of dramatically low resolution data, full
> >> power
> >> > > coupled with 360Deg data collection etc. etc. etc. We do
> unfortunately
> >> see too
> >> > > many 'blind shots, deal with it later, and move on' experiments
> that it
> >> > > becomes depressive. I personally do not see why we would close our
> >> eyes to
> >> > > servers and/or data analysis tools that could help you think less,
> or
> >> better
> >> > > say help you understanding what is eventually happening with your
> data.
> >> > >
> >> > > Cheers, leo
> >> > >
> >> > > -
> >> > > Leonard Chavas
> >> > > -
> >> > > Synchrotron SOLEIL
> >> > > Proxima-I
> >> > > L'Orme des Merisiers
> >> > > Saint-Aubin - BP 48
> >> > > 91192 Gif-sur-Yvette Cedex
> >> > > France
> >> > > -
> >> > > Phone:  +33 169 359 746
> >> > > Mobile: +33 644 321 614
> >> > > E-mail: leonard.cha...@synchrotron-soleil.fr
> >> > > -
> >> > >
> >> > >> On 24 Nov 2017, at 00:23, Edward A. Berry 
> wrote:
> >> > >>
> >> > >> My 2 cents worth:
> >> > >> I think contaminer is an extremely useful service. I may be a
> sloppy
> >> > >> biochemist,
> >> > >> but I am not the only one. There are multiple structures in the
> >> database of
> >> > >> say
> >> > >> bacterioferritin or AcrB that were solved from crystals that were
> >> supposed
> >> > >> to
> >> > >> be something else. I remember in a discussion with the organizer
> of my
> >> > >> session
> >> > >> at a Gordon conference, she excitedly announced that there would be
> >> > >> preliminary
> >> > >> crystallographic data on respiratory Complex I. But by the time of
> the
> >> > >> conference
> >> > >> the authors discovered they had crystallized 

Re: [ccp4bb] new ContaMiner features

[radu]

Hi Stefan,

I also owe you an apology for my bad choice of words. One can debate about
usefulness, but Pavel is right, the software is not "bizarre". And, as several
people pointed out, it certainly addresses a need (which I didn't know about).
Mea culpa.

Best wishes,

Radu


> Dear Gerard
>
> I am really sorry that my badly formulated 'final word of warning' has made
> you and others spend much time for composing well-formulated replies. I was
> at PX1 yesterday, and Leo reminded me of the issue, hence I included it
> into my message.
> You are absolutely right that reports of anomalies should go to the
> developers - however the issue here is already known (as shown in the
> STARANISO Warning message) and cannot be solved by us at the ContaMiner
> level. Given the popularity of Staraniso, I just wanted to inform our users
> that this particular issue is propagated into the ContaMiner results. I
> should have worded it more carefully.
>
> Many thanks to Leo and Pierre for helping explain!
>
> With best wishes
> Stefan
>
>
>
> On 24 November 2017 at 13:07, Gerard Bricogne 
> wrote:
>
>> Dear Radu,
>>
>>  I would not want to take undue advantage of this already
>> voluminous thread, but your PS takes us into a different direction,
>> namely the whole myth-ridden topic of "weak data" - but that will be
>> for another thread, another time ;-) .
>>
>>
>>  With best wishes,
>>
>>   Gerard.
>>
>> --
>> On Fri, Nov 24, 2017 at 01:02:08AM -, r...@mrc-lmb.cam.ac.uk wrote:
>> > Hi Leo,
>> >
>> > I agree that the horror beamline stories you describe are far too common.
>> > Unfortunately, they start earlier, in the wet lab or even before.
>> Exactly the
>> > same attitude (careless construct design, crystallising whatever "dirty"
>> > samples, not bothering optimising cryoprotection and so on) leads to
>> wasting a
>> > lot of resources, including synchrotron time. In some cases, as people
>> pointed
>> > out, problems such as contaminations (and even more so anisotropic data,
>> for
>> > the matter) are unavoidable. But too often, as we all know, it's simply
>> bad
>> > practice, lack of training etc. Web servers can only help up to a
>> point...
>> >
>> > Best wishes,
>> >
>> > Radu
>> > PS: At least, one day, maximum-likelihood refinement programs will deal
>> with
>> > weak data satisfactorily :-) Nobody likes to throw data away.
>> >
>> >
>> > > Dear all,
>> > >
>> > > to join Pierre's comments on what 'strange' things happen at the
>> beamlines...
>> > > yet not too strange for (too) many people: huge screening of salt
>> crystals,
>> > > complete data collection of dramatically low resolution data, full
>> power
>> > > coupled with 360Deg data collection etc. etc. etc. We do unfortunately
>> see too
>> > > many 'blind shots, deal with it later, and move on' experiments that it
>> > > becomes depressive. I personally do not see why we would close our
>> eyes to
>> > > servers and/or data analysis tools that could help you think less, or
>> better
>> > > say help you understanding what is eventually happening with your data.
>> > >
>> > > Cheers, leo
>> > >
>> > > -
>> > > Leonard Chavas
>> > > -
>> > > Synchrotron SOLEIL
>> > > Proxima-I
>> > > L'Orme des Merisiers
>> > > Saint-Aubin - BP 48
>> > > 91192 Gif-sur-Yvette Cedex
>> > > France
>> > > -
>> > > Phone:  +33 169 359 746
>> > > Mobile: +33 644 321 614
>> > > E-mail: leonard.cha...@synchrotron-soleil.fr
>> > > -
>> > >
>> > >> On 24 Nov 2017, at 00:23, Edward A. Berry  wrote:
>> > >>
>> > >> My 2 cents worth:
>> > >> I think contaminer is an extremely useful service. I may be a sloppy
>> > >> biochemist,
>> > >> but I am not the only one. There are multiple structures in the
>> database of
>> > >> say
>> > >> bacterioferritin or AcrB that were solved from crystals that were
>> supposed
>> > >> to
>> > >> be something else. I remember in a discussion with the organizer of my
>> > >> session
>> > >> at a Gordon conference, she excitedly announced that there would be
>> > >> preliminary
>> > >> crystallographic data on respiratory Complex I. But by the time of the
>> > >> conference
>> > >> the authors discovered they had crystallized something else. And the
>> > >> beautiful crystals
>> > >> of Paracoccus Complex II (from Doug Rees's lab?) that graced the
>> catalog of
>> > >> Hampton Research (And I believe were part of the basis for the first
>> > >> membrane
>> > >> protein screen) never saw publication.  The authors of
>> > >>  http://www.sciencedirect.com/science/article/pii/S0304416506000894
>> > >> certainly feel there is a real problem.  Some proteins crystallize
>> readily
>> > >> even when
>> > >> present as minor contaminants. And some protein complexes become more
>> > >> heterogeneous
>> > >> if over-purified due to partial loss of loosely-bound subunits.
>> > >> Most of my career I've worked with high-abundance natural-source
>> proteins.
>> > >> During a recent foray into the 

Re: [ccp4bb] new ContaMiner features

[Gerard Bricogne]

Dear Stefan,

 Thank you for your message. I am sure that we will figure out
what caused the spurious results described by Pierre, now that we know
about them ;-) . 

 Perhaps my reaction to your message was a little too loaded with
tension, and if so I regret it. The fact is that we are encountering
much "mental viscosity" in our discussions about a simple framework
for anisotropic statistics, which makes it hard not to become a bit 
defensive at times. 

 It was nice to read that your ContaMiner server is so highly
appreciated!


 With best wishes,
 
  Gerard.

--
On Fri, Nov 24, 2017 at 03:12:50PM +0100, Stefan Arold wrote:
> Dear Gerard
> 
> I am really sorry that my badly formulated 'final word of warning' has made
> you and others spend much time for composing well-formulated replies. I was
> at PX1 yesterday, and Leo reminded me of the issue, hence I included it
> into my message.
> You are absolutely right that reports of anomalies should go to the
> developers - however the issue here is already known (as shown in the
> STARANISO Warning message) and cannot be solved by us at the ContaMiner
> level. Given the popularity of Staraniso, I just wanted to inform our users
> that this particular issue is propagated into the ContaMiner results. I
> should have worded it more carefully.
> 
> Many thanks to Leo and Pierre for helping explain!
> 
> With best wishes
> Stefan
> 
> 
> 
> On 24 November 2017 at 13:07, Gerard Bricogne 
> wrote:
> 
> > Dear Radu,
> >
> >  I would not want to take undue advantage of this already
> > voluminous thread, but your PS takes us into a different direction,
> > namely the whole myth-ridden topic of "weak data" - but that will be
> > for another thread, another time ;-) .
> >
> >
> >  With best wishes,
> >
> >   Gerard.
> >
> > --
> > On Fri, Nov 24, 2017 at 01:02:08AM -, r...@mrc-lmb.cam.ac.uk wrote:
> > > Hi Leo,
> > >
> > > I agree that the horror beamline stories you describe are far too common.
> > > Unfortunately, they start earlier, in the wet lab or even before.
> > Exactly the
> > > same attitude (careless construct design, crystallising whatever "dirty"
> > > samples, not bothering optimising cryoprotection and so on) leads to
> > wasting a
> > > lot of resources, including synchrotron time. In some cases, as people
> > pointed
> > > out, problems such as contaminations (and even more so anisotropic data,
> > for
> > > the matter) are unavoidable. But too often, as we all know, it's simply
> > bad
> > > practice, lack of training etc. Web servers can only help up to a
> > point...
> > >
> > > Best wishes,
> > >
> > > Radu
> > > PS: At least, one day, maximum-likelihood refinement programs will deal
> > with
> > > weak data satisfactorily :-) Nobody likes to throw data away.
> > >
> > >
> > > > Dear all,
> > > >
> > > > to join Pierre's comments on what 'strange' things happen at the
> > beamlines...
> > > > yet not too strange for (too) many people: huge screening of salt
> > crystals,
> > > > complete data collection of dramatically low resolution data, full
> > power
> > > > coupled with 360Deg data collection etc. etc. etc. We do unfortunately
> > see too
> > > > many 'blind shots, deal with it later, and move on' experiments that it
> > > > becomes depressive. I personally do not see why we would close our
> > eyes to
> > > > servers and/or data analysis tools that could help you think less, or
> > better
> > > > say help you understanding what is eventually happening with your data.
> > > >
> > > > Cheers, leo
> > > >
> > > > -
> > > > Leonard Chavas
> > > > -
> > > > Synchrotron SOLEIL
> > > > Proxima-I
> > > > L'Orme des Merisiers
> > > > Saint-Aubin - BP 48
> > > > 91192 Gif-sur-Yvette Cedex
> > > > France
> > > > -
> > > > Phone:  +33 169 359 746
> > > > Mobile: +33 644 321 614
> > > > E-mail: leonard.cha...@synchrotron-soleil.fr
> > > > -
> > > >
> > > >> On 24 Nov 2017, at 00:23, Edward A. Berry  wrote:
> > > >>
> > > >> My 2 cents worth:
> > > >> I think contaminer is an extremely useful service. I may be a sloppy
> > > >> biochemist,
> > > >> but I am not the only one. There are multiple structures in the
> > database of
> > > >> say
> > > >> bacterioferritin or AcrB that were solved from crystals that were
> > supposed
> > > >> to
> > > >> be something else. I remember in a discussion with the organizer of my
> > > >> session
> > > >> at a Gordon conference, she excitedly announced that there would be
> > > >> preliminary
> > > >> crystallographic data on respiratory Complex I. But by the time of the
> > > >> conference
> > > >> the authors discovered they had crystallized something else. And the
> > > >> beautiful crystals
> > > >> of Paracoccus Complex II (from Doug Rees's lab?) that graced the
> > catalog of
> > > >> Hampton Research (And I believe were part of the basis for the first
> > > >> membrane
> > > >> protein screen) never saw publication.  The 

Re: [ccp4bb] new ContaMiner features

[Stefan Arold]

Dear Gerard

I am really sorry that my badly formulated 'final word of warning' has made
you and others spend much time for composing well-formulated replies. I was
at PX1 yesterday, and Leo reminded me of the issue, hence I included it
into my message.
You are absolutely right that reports of anomalies should go to the
developers - however the issue here is already known (as shown in the
STARANISO Warning message) and cannot be solved by us at the ContaMiner
level. Given the popularity of Staraniso, I just wanted to inform our users
that this particular issue is propagated into the ContaMiner results. I
should have worded it more carefully.

Many thanks to Leo and Pierre for helping explain!

With best wishes
Stefan



On 24 November 2017 at 13:07, Gerard Bricogne 
wrote:

> Dear Radu,
>
>  I would not want to take undue advantage of this already
> voluminous thread, but your PS takes us into a different direction,
> namely the whole myth-ridden topic of "weak data" - but that will be
> for another thread, another time ;-) .
>
>
>  With best wishes,
>
>   Gerard.
>
> --
> On Fri, Nov 24, 2017 at 01:02:08AM -, r...@mrc-lmb.cam.ac.uk wrote:
> > Hi Leo,
> >
> > I agree that the horror beamline stories you describe are far too common.
> > Unfortunately, they start earlier, in the wet lab or even before.
> Exactly the
> > same attitude (careless construct design, crystallising whatever "dirty"
> > samples, not bothering optimising cryoprotection and so on) leads to
> wasting a
> > lot of resources, including synchrotron time. In some cases, as people
> pointed
> > out, problems such as contaminations (and even more so anisotropic data,
> for
> > the matter) are unavoidable. But too often, as we all know, it's simply
> bad
> > practice, lack of training etc. Web servers can only help up to a
> point...
> >
> > Best wishes,
> >
> > Radu
> > PS: At least, one day, maximum-likelihood refinement programs will deal
> with
> > weak data satisfactorily :-) Nobody likes to throw data away.
> >
> >
> > > Dear all,
> > >
> > > to join Pierre's comments on what 'strange' things happen at the
> beamlines...
> > > yet not too strange for (too) many people: huge screening of salt
> crystals,
> > > complete data collection of dramatically low resolution data, full
> power
> > > coupled with 360Deg data collection etc. etc. etc. We do unfortunately
> see too
> > > many 'blind shots, deal with it later, and move on' experiments that it
> > > becomes depressive. I personally do not see why we would close our
> eyes to
> > > servers and/or data analysis tools that could help you think less, or
> better
> > > say help you understanding what is eventually happening with your data.
> > >
> > > Cheers, leo
> > >
> > > -
> > > Leonard Chavas
> > > -
> > > Synchrotron SOLEIL
> > > Proxima-I
> > > L'Orme des Merisiers
> > > Saint-Aubin - BP 48
> > > 91192 Gif-sur-Yvette Cedex
> > > France
> > > -
> > > Phone:  +33 169 359 746
> > > Mobile: +33 644 321 614
> > > E-mail: leonard.cha...@synchrotron-soleil.fr
> > > -
> > >
> > >> On 24 Nov 2017, at 00:23, Edward A. Berry  wrote:
> > >>
> > >> My 2 cents worth:
> > >> I think contaminer is an extremely useful service. I may be a sloppy
> > >> biochemist,
> > >> but I am not the only one. There are multiple structures in the
> database of
> > >> say
> > >> bacterioferritin or AcrB that were solved from crystals that were
> supposed
> > >> to
> > >> be something else. I remember in a discussion with the organizer of my
> > >> session
> > >> at a Gordon conference, she excitedly announced that there would be
> > >> preliminary
> > >> crystallographic data on respiratory Complex I. But by the time of the
> > >> conference
> > >> the authors discovered they had crystallized something else. And the
> > >> beautiful crystals
> > >> of Paracoccus Complex II (from Doug Rees's lab?) that graced the
> catalog of
> > >> Hampton Research (And I believe were part of the basis for the first
> > >> membrane
> > >> protein screen) never saw publication.  The authors of
> > >>  http://www.sciencedirect.com/science/article/pii/S0304416506000894
> > >> certainly feel there is a real problem.  Some proteins crystallize
> readily
> > >> even when
> > >> present as minor contaminants. And some protein complexes become more
> > >> heterogeneous
> > >> if over-purified due to partial loss of loosely-bound subunits.
> > >> Most of my career I've worked with high-abundance natural-source
> proteins.
> > >> During a recent foray into the realm of overexpressed proteins, my
> group
> > >> has
> > >> crystallized (and solved) at least a half dozen wrong proteins from E.
> > >> coli.
> > >> I spent months on one of these (ATCase in Rhomb sg with low-level
> > >> obverse/reverse
> > >> twinning that caused it to sometimes index as P3) Then solved the rest
> > >> rapidly
> > >> by checking the closest several hits with nearest-cell.  All of these
> E.coli
> > 

Re: [ccp4bb] new ContaMiner features

[Gerard Bricogne]

Dear Radu,

 I would not want to take undue advantage of this already
voluminous thread, but your PS takes us into a different direction,
namely the whole myth-ridden topic of "weak data" - but that will be
for another thread, another time ;-) .


 With best wishes,
 
  Gerard.

--
On Fri, Nov 24, 2017 at 01:02:08AM -, r...@mrc-lmb.cam.ac.uk wrote:
> Hi Leo,
> 
> I agree that the horror beamline stories you describe are far too common.
> Unfortunately, they start earlier, in the wet lab or even before. Exactly the
> same attitude (careless construct design, crystallising whatever "dirty"
> samples, not bothering optimising cryoprotection and so on) leads to wasting a
> lot of resources, including synchrotron time. In some cases, as people pointed
> out, problems such as contaminations (and even more so anisotropic data, for
> the matter) are unavoidable. But too often, as we all know, it's simply bad
> practice, lack of training etc. Web servers can only help up to a point...
> 
> Best wishes,
> 
> Radu
> PS: At least, one day, maximum-likelihood refinement programs will deal with
> weak data satisfactorily :-) Nobody likes to throw data away.
> 
> 
> > Dear all,
> >
> > to join Pierre's comments on what 'strange' things happen at the 
> > beamlines...
> > yet not too strange for (too) many people: huge screening of salt crystals,
> > complete data collection of dramatically low resolution data, full power
> > coupled with 360Deg data collection etc. etc. etc. We do unfortunately see 
> > too
> > many 'blind shots, deal with it later, and move on' experiments that it
> > becomes depressive. I personally do not see why we would close our eyes to
> > servers and/or data analysis tools that could help you think less, or better
> > say help you understanding what is eventually happening with your data.
> >
> > Cheers, leo
> >
> > -
> > Leonard Chavas
> > -
> > Synchrotron SOLEIL
> > Proxima-I
> > L'Orme des Merisiers
> > Saint-Aubin - BP 48
> > 91192 Gif-sur-Yvette Cedex
> > France
> > -
> > Phone:  +33 169 359 746
> > Mobile: +33 644 321 614
> > E-mail: leonard.cha...@synchrotron-soleil.fr
> > -
> >
> >> On 24 Nov 2017, at 00:23, Edward A. Berry  wrote:
> >>
> >> My 2 cents worth:
> >> I think contaminer is an extremely useful service. I may be a sloppy
> >> biochemist,
> >> but I am not the only one. There are multiple structures in the database of
> >> say
> >> bacterioferritin or AcrB that were solved from crystals that were supposed
> >> to
> >> be something else. I remember in a discussion with the organizer of my
> >> session
> >> at a Gordon conference, she excitedly announced that there would be
> >> preliminary
> >> crystallographic data on respiratory Complex I. But by the time of the
> >> conference
> >> the authors discovered they had crystallized something else. And the
> >> beautiful crystals
> >> of Paracoccus Complex II (from Doug Rees's lab?) that graced the catalog of
> >> Hampton Research (And I believe were part of the basis for the first
> >> membrane
> >> protein screen) never saw publication.  The authors of
> >>  http://www.sciencedirect.com/science/article/pii/S0304416506000894
> >> certainly feel there is a real problem.  Some proteins crystallize readily
> >> even when
> >> present as minor contaminants. And some protein complexes become more
> >> heterogeneous
> >> if over-purified due to partial loss of loosely-bound subunits.
> >> Most of my career I've worked with high-abundance natural-source proteins.
> >> During a recent foray into the realm of overexpressed proteins, my group
> >> has
> >> crystallized (and solved) at least a half dozen wrong proteins from E.
> >> coli.
> >> I spent months on one of these (ATCase in Rhomb sg with low-level
> >> obverse/reverse
> >> twinning that caused it to sometimes index as P3) Then solved the rest
> >> rapidly
> >> by checking the closest several hits with nearest-cell.  All of these 
> >> E.coli
> >> proteins
> >> were already present in the PDB. I wonder how many were from accidental
> >> crystals.
> >> And now bacterioferritin (this time from M. smegmatis) keeps coming back to
> >> haunt us.
> >>
> >> I would say any time with a new crystal when a molecular replacement
> >> unexpectedly fails,
> >> and even before you start to collect heavy atom or selenomet data, it would
> >> be worth
> >> to submit to nearest-cell and contaminer. I would be more likely to 
> >> question
> >> the
> >> utility of an anisotropy correction server, given that modern
> >> maximum-likelihood
> >> refinement programs can deal with weak data satisfactorily (speaking from
> >> ignorance- I'm sure supporting evidence and examples exist, I just haven't
> >> bothered to look them up. And I know my colleagues here at Upstate have
> >> used
> >> anisotropy correction to good effect with a difficult problem- I hope they
> >> weren't using filled-in maps!)
> >> eab
> >>
> >> On 11/23/2017 03:24 PM, Tristan Croll wrote:
> 

Re: [ccp4bb] new ContaMiner features

[Gerard Bricogne]

9PM +, LEGRAND Pierre wrote:
> >> Dear Gérard,
> >> 
> >> As being part of the group how has initially raised the issue to Stefan, I 
> >> stand out to try clarifying a misinterpretation.
> >> In brief, because we are happy users of StarAniso, it happened that we 
> >> have submitted an mtz that it had produced to the ContaMiner server. We 
> >> were very surprised to find that almost all contaminants evaluated gave 
> >> high scores according to MoRDa. On the contrary, using an "isotropicaly" 
> >> treated mtz, no hit could be detected in by ContaMiner.
> >> 
> >> Being collected on PROXIMA-1 beamline, it coun't be a "badly collected 
> >> datasets" ;-)
> >> 
> >> So, most probably, as you suggested, the issue is linked to some bad 
> >> assumptions made by MoRDa or inadequate criteria choices _in_the_cases_ of 
> >> "corrected" anisotropic data. 
> >> We can probably provide some examples of datasets to the developers 
> >> willing to pursue investigations on this.
> >> 
> >> I completely agree with Tristan! I have to admit having lost several weeks 
> >> in my career (if not months) with "contaminated" crystals. And working on 
> >> an MX beamline, I can testify that this is unfortunately happening 
> >> regularly. 
> >> 
> >> I will finish with a big thanks to all the (StarAniso/ContaMiner/MoRDA) 
> >> developers how are helping us to untwist the unavoidable experimental 
> >> mess/reality.
> >> 
> >> Kind regards,
> >> Pierre 
> >> 
> >> De : CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] de la part de Gerard 
> >> Bricogne [g...@globalphasing.com]
> >> Envoyé : jeudi 23 novembre 2017 19:34
> >> À : CCP4BB@JISCMAIL.AC.UK
> >> Objet : Re: [ccp4bb] new ContaMiner features
> >> 
> >> Dear Stefan,
> >> 
> >> Regarding your final paragraph: your server carries a warning
> >> with the exact wording:
> >> 
> >> "Submitting StarAniso files can give you suspicious results. Use
> >> with care!"
> >> 
> >> It seems rather regrettable that you are posting such a public
> >> warning without ever having contacted the STARANISO developers about
> >> your observations, nor giving any information about what you call
> >> "suspicious" or what the "care" you recommend would consist of.
> >> 
> >> We have taken a great deal of care ourselves in developing the
> >> program and offering it to the community through a server, and the
> >> least we would have expected is that any pattern of "suspicious"
> >> results would be referred to us so that we could investigate them.
> >> There may be some assumptions made in MoRDa that we are not aware of,
> >> that might be incompatible with assumptions made in STARANISO - who
> >> knows? Or it could be that some particularly badly collected datasets
> >> are made to look worse after their anisotropy analysis.
> >> 
> >> Could we discuss your observations, and what it is exactly that
> >> you call "suspicious", before they end up being referred to in such an
> >> uninformative manner as some sort of "Government Health Warning"?
> >> 
> >> I think that would be nice :-) and we would be only too keen to
> >> take whatever extra "care" is needed ourselves. We would all learn
> >> something.
> >> 
> >> 
> >> With best wishes,
> >> 
> >>  Gerard.
> >> 
> >> (on behalf of the STARANISO developers)
> >> 
> >> --
> >> On Thu, Nov 23, 2017 at 05:02:39PM +0100, Stefan Arold wrote:
> >>> Dear Community,
> >>> 
> >>> A quick message to announce the following two new features on our
> >>> ContaMiner web server for the automated detection of unwantedly
> >>> crystallised contaminants (
> >>> https://strube.cbrc.kaust.edu.sa/contaminer/submit)
> >>> 
> >>> 1) online visualisation of 2FoFc and FoFc maps. In cases of positive
> >>> results, the ‘UglyMol’ tab allows to inspect 2FoFc and FoFc maps directly
> >>> in the web browser. Thi
> >>> 
> >>> 2) life-update. Previously, results were sent to you once all ~2000 MR 
> >>> jobs
> >>> were finished. Now, the individual res

Re: [ccp4bb] new ContaMiner features

[Eleanor Dodson]

Ian's words need to emblazoned over all CCP4 distributions.

Users are an essential part of any development work..


As a developer I would never consider constructive user feedback as a
complaint.  Feedback is a critical component of the software development
process and I think I speak for all developers in only wishing that there
was a lot more of it!

On 24 November 2017 at 10:06, Ian Tickle  wrote:

>
> Hi Graeme
>
> On 24 November 2017 at 06:33, Graeme Winter 
> wrote:
>
>>
>> Despite appearances people do not like to contact authors of software
>> packages to complain.
>>
>
> As a developer I would never consider constructive user feedback as a
> complaint.  Feedback is a critical component of the software development
> process and I think I speak for all developers in only wishing that there
> was a lot more of it!
>
> I have been asked on several occasions to incorporate the anisotropy
>> correction into xia2 as it 'always makes things better', and have resisted
>> on the grounds that the purpose of the package is to faithfully analyse the
>> data as provided and provide uncorrected intensities as output. The
>> corrections should ideally be performed within the downstream software,
>> since they then know exactly what has happened to the measurements and will
>> make fewer (ideally no) incorrect assumptions.
>>
>
> This assumes that it make sense to perform the corrections downstream of
> processing.  In the case of anisotropy this may not be the case: the
> anisotropy correction is likely to be intimately linked with the batch
> scaling and error model, so that it only makes sense to incorporate the
> anisotropy correction as an integral component of the processing pipeline,
> not downstream.
>
> It's already routine to write out multiple versions of e.g. phases,
>> weights, sigma values etc based on different assumptions and flag then
>> accordingly - perhaps we should be doing the same with modified
>> intensities, so that packages which require the unmodified values could
>> ignore the corrected ones. That would avoid the need for any health
>> warnings and ensure changes in the wider environment do not invalidate
>> assumptions...
>>
>
> I totally agree!  STARANISO has the option to transfer over all the
> uncorrected data and append the corrected data to it.  This used to be the
> default but is no longer (you have to check a box to activate it), because
> users seemed to get confused by having too many MTZ columns to choose from!
>
>
>> Obviously, all of the above is my humble opinion and other opinions are
>> equally valid.
>>
>
> Likewise!
>
> Regards
>
> -- Ian
>
>

Re: [ccp4bb] new ContaMiner features

[Ian Tickle]

Hi Graeme

On 24 November 2017 at 06:33, Graeme Winter 
wrote:

>
> Despite appearances people do not like to contact authors of software
> packages to complain.
>

As a developer I would never consider constructive user feedback as a
complaint.  Feedback is a critical component of the software development
process and I think I speak for all developers in only wishing that there
was a lot more of it!

I have been asked on several occasions to incorporate the anisotropy
> correction into xia2 as it 'always makes things better', and have resisted
> on the grounds that the purpose of the package is to faithfully analyse the
> data as provided and provide uncorrected intensities as output. The
> corrections should ideally be performed within the downstream software,
> since they then know exactly what has happened to the measurements and will
> make fewer (ideally no) incorrect assumptions.
>

This assumes that it make sense to perform the corrections downstream of
processing.  In the case of anisotropy this may not be the case: the
anisotropy correction is likely to be intimately linked with the batch
scaling and error model, so that it only makes sense to incorporate the
anisotropy correction as an integral component of the processing pipeline,
not downstream.

It's already routine to write out multiple versions of e.g. phases,
> weights, sigma values etc based on different assumptions and flag then
> accordingly - perhaps we should be doing the same with modified
> intensities, so that packages which require the unmodified values could
> ignore the corrected ones. That would avoid the need for any health
> warnings and ensure changes in the wider environment do not invalidate
> assumptions...
>

I totally agree!  STARANISO has the option to transfer over all the
uncorrected data and append the corrected data to it.  This used to be the
default but is no longer (you have to check a box to activate it), because
users seemed to get confused by having too many MTZ columns to choose from!


> Obviously, all of the above is my humble opinion and other opinions are
> equally valid.
>

Likewise!

Regards

-- Ian

Re: [ccp4bb] new ContaMiner features

[Ian Tickle]

l.fr
> -
>
> > On 23 Nov 2017, at 23:53, Gerard Bricogne <g...@globalphasing.com>
> wrote:
> >
> > Dear Pierre,
> >
> > Thank you for throwing some light on the circumstances under
> > which the "suspicious" results cropped up :-) . Was the "Government
> > Heatlh Warning" based on this one and only mtz file, then?
> >
> > We would certainly be interested in examining this dataset for
> > any anomalies in the anisotropy analysis and the mtz file it produced
> > (perhaps you can simply give us the job ID on the server). However the
> > "results" consist of the spurious recognition of molecules that are
> > known not to be in the crystal, so they are the outcome of numerous
> > unspecified steps downstream of the anisotropy analysis itself, that
> > in the end produce a "score" that is misleading. It would be useful to
> > have at least some idea of what those steps are in order to identify
> > the possible causes of the erroneous detections.
> >
> >
> > With best wishes,
> >
> >  Gerard.
> >
> > --
> > On Thu, Nov 23, 2017 at 10:05:09PM +, LEGRAND Pierre wrote:
> >> Dear Gérard,
> >>
> >> As being part of the group how has initially raised the issue to
> Stefan, I stand out to try clarifying a misinterpretation.
> >> In brief, because we are happy users of StarAniso, it happened that we
> have submitted an mtz that it had produced to the ContaMiner server. We
> were very surprised to find that almost all contaminants evaluated gave
> high scores according to MoRDa. On the contrary, using an "isotropicaly"
> treated mtz, no hit could be detected in by ContaMiner.
> >>
> >> Being collected on PROXIMA-1 beamline, it coun't be a "badly collected
> datasets" ;-)
> >>
> >> So, most probably, as you suggested, the issue is linked to some bad
> assumptions made by MoRDa or inadequate criteria choices _in_the_cases_ of
> "corrected" anisotropic data.
> >> We can probably provide some examples of datasets to the developers
> willing to pursue investigations on this.
> >>
> >> I completely agree with Tristan! I have to admit having lost several
> weeks in my career (if not months) with "contaminated" crystals. And
> working on an MX beamline, I can testify that this is unfortunately
> happening regularly.
> >>
> >> I will finish with a big thanks to all the (StarAniso/ContaMiner/MoRDA)
> developers how are helping us to untwist the unavoidable experimental
> mess/reality.
> >>
> >> Kind regards,
> >> Pierre
> >> 
> >> De : CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] de la part de Gerard
> Bricogne [g...@globalphasing.com]
> >> Envoyé : jeudi 23 novembre 2017 19:34
> >> À : CCP4BB@JISCMAIL.AC.UK
> >> Objet : Re: [ccp4bb] new ContaMiner features
> >>
> >> Dear Stefan,
> >>
> >> Regarding your final paragraph: your server carries a warning
> >> with the exact wording:
> >>
> >> "Submitting StarAniso files can give you suspicious results. Use
> >> with care!"
> >>
> >> It seems rather regrettable that you are posting such a public
> >> warning without ever having contacted the STARANISO developers about
> >> your observations, nor giving any information about what you call
> >> "suspicious" or what the "care" you recommend would consist of.
> >>
> >> We have taken a great deal of care ourselves in developing the
> >> program and offering it to the community through a server, and the
> >> least we would have expected is that any pattern of "suspicious"
> >> results would be referred to us so that we could investigate them.
> >> There may be some assumptions made in MoRDa that we are not aware of,
> >> that might be incompatible with assumptions made in STARANISO - who
> >> knows? Or it could be that some particularly badly collected datasets
> >> are made to look worse after their anisotropy analysis.
> >>
> >> Could we discuss your observations, and what it is exactly that
> >> you call "suspicious", before they end up being referred to in such an
> >> uninformative manner as some sort of "Government Health Warning"?
> >>
> >> I think that would be nice :-) and we would be only too keen to
> >> take whatever extra "care" is needed oursel

Re: [ccp4bb] new ContaMiner features

[Pavel Afonine]

It's amusing how a seemingly innocent ad for a new tool can ignite a rather
prickly thread.. I see two keys to this.

Firstly, for those who are not familiar with the issue the add could be
better structured by providing a clearer statement of what the problem is
or why it is important (with appropriate citations as examples) and then
addressing how this is solved using the tool being advertised (ContaMiner).

Second, I can't agree more with with Gerard: "a word of warning" (concerns
about Staraniso use) is best to discuss with respective developers first
before going public. (A nuance though is: not all developers are keen to
open-access source code or even allow their software for benchmarking by
others in some instances. So this may be tricky sometimes.)

Radu's assessment is harsh to my taste.. I guess others commented on this
enough to explain the validity of effort. Plus, I find wording "on the
bizarre ContaMiner" isn't helpful.

All in all, intentionally or not, this made enough of advertisement for
ContaMiner and Staraniso! Win-win, I think!

All the best,
Pavel


On Thu, Nov 23, 2017 at 10:33 PM, Graeme Winter  wrote:

> Dear All,
>
> As someone who is both a user of external software and supports internally
> developed software to external users, I am quite familiar with both sides
> of this argument. From time to time someone will notice a "weird feature"
> in software - sometimes this is a bug, sometimes misuse (which is still by
> and large a bug, but in documentation) and sometimes a change in
> circumstances i.e. reasonable assumptions made in developing a package
> (e.g. background always over 1 count / all data sets have some reflections
> with I/sigI > 3 etc) become problematic.
>
> As an individual developing software, and a member of a team doing so, it
> is always more comfortable if a user comes back with a collegiate "quiet
> word" that the software did something odd. However, I suspect it would be
> for the greater good that a more public approach was taken in general,
> since the less attentive user may miss this odd feature and take the
> results as gospel - if the knowledge of the bug / feature whatever was not
> in the public domain. Despite appearances people do not like to contact
> authors of software packages to complain.
>
> To make a note that "this version of package xyz has been found to be
> sometimes unpredictable with version 123 of the pipeline" does not blame
> the package, or the pipeline, but says that you should be warned with this
> combination. Ideally the authors of package xyz and the pipeline would be
> alerted, by the other developers or users, but it is better (IMHO) to be
> open. Public bug trackers are a good example of this.
>
> I suspect this matter of anisotropy correction is a similar one. Here we
> have a change in circumstances - the actual intensity measurements are
> modified - and passed in as if they are the originals. It is reasonable
> that this may affect the outcome of subsequent analysis and it is hoped
> that this does change the outcome but in a positive manner. This does not
> appear to be the case here.
>
> I have been asked on several occasions to incorporate the anisotropy
> correction into xia2 as it 'always makes things better', and have resisted
> on the grounds that the purpose of the package is to faithfully analyse the
> data as provided and provide uncorrected intensities as output. The
> corrections should ideally be performed within the downstream software,
> since they then know exactly what has happened to the measurements and will
> make fewer (ideally no) incorrect assumptions.
>
> It's already routine to write out multiple versions of e.g. phases,
> weights, sigma values etc based on different assumptions and flag then
> accordingly - perhaps we should be doing the same with modified
> intensities, so that packages which require the unmodified values could
> ignore the corrected ones. That would avoid the need for any health
> warnings and ensure changes in the wider environment do not invalidate
> assumptions...
>
> Obviously, all of the above is my humble opinion and other opinions are
> equally valid.
>
> Best wishes Graeme
>
>
> --
> This e-mail and any attachments may contain confidential, copyright and or
> privileged material, and are for the use of the intended addressee only. If
> you are not the intended addressee or an authorised recipient of the
> addressee please notify us of receipt by returning the e-mail and do not
> use, copy, retain, distribute or disclose the information in or attached to
> the e-mail.
> Any opinions expressed within this e-mail are those of the individual and
> not necessarily of Diamond Light Source Ltd.
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any
> attachments are free from viruses and we cannot accept liability for any
> damage which you may sustain as a result of software viruses which may be
> transmitted in or with the 

Re: [ccp4bb] new ContaMiner features

[Graeme Winter]

Dear All,

As someone who is both a user of external software and supports internally 
developed software to external users, I am quite familiar with both sides of 
this argument. From time to time someone will notice a "weird feature" in 
software - sometimes this is a bug, sometimes misuse (which is still by and 
large a bug, but in documentation) and sometimes a change in circumstances i.e. 
reasonable assumptions made in developing a package (e.g. background always 
over 1 count / all data sets have some reflections with I/sigI > 3 etc) become 
problematic.

As an individual developing software, and a member of a team doing so, it is 
always more comfortable if a user comes back with a collegiate "quiet word" 
that the software did something odd. However, I suspect it would be for the 
greater good that a more public approach was taken in general, since the less 
attentive user may miss this odd feature and take the results as gospel - if 
the knowledge of the bug / feature whatever was not in the public domain. 
Despite appearances people do not like to contact authors of software packages 
to complain. 

To make a note that "this version of package xyz has been found to be sometimes 
unpredictable with version 123 of the pipeline" does not blame the package, or 
the pipeline, but says that you should be warned with this combination. Ideally 
the authors of package xyz and the pipeline would be alerted, by the other 
developers or users, but it is better (IMHO) to be open. Public bug trackers 
are a good example of this. 

I suspect this matter of anisotropy correction is a similar one. Here we have a 
change in circumstances - the actual intensity measurements are modified - and 
passed in as if they are the originals. It is reasonable that this may affect 
the outcome of subsequent analysis and it is hoped that this does change the 
outcome but in a positive manner. This does not appear to be the case here. 

I have been asked on several occasions to incorporate the anisotropy correction 
into xia2 as it 'always makes things better', and have resisted on the grounds 
that the purpose of the package is to faithfully analyse the data as provided 
and provide uncorrected intensities as output. The corrections should ideally 
be performed within the downstream software, since they then know exactly what 
has happened to the measurements and will make fewer (ideally no) incorrect 
assumptions. 

It's already routine to write out multiple versions of e.g. phases, weights, 
sigma values etc based on different assumptions and flag then accordingly - 
perhaps we should be doing the same with modified intensities, so that packages 
which require the unmodified values could ignore the corrected ones. That would 
avoid the need for any health warnings and ensure changes in the wider 
environment do not invalidate assumptions...

Obviously, all of the above is my humble opinion and other opinions are equally 
valid. 

Best wishes Graeme


-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

Re: [ccp4bb] new ContaMiner features

[radu]

Hi Leo,

I agree that the horror beamline stories you describe are far too common.
Unfortunately, they start earlier, in the wet lab or even before. Exactly the
same attitude (careless construct design, crystallising whatever "dirty"
samples, not bothering optimising cryoprotection and so on) leads to wasting a
lot of resources, including synchrotron time. In some cases, as people pointed
out, problems such as contaminations (and even more so anisotropic data, for
the matter) are unavoidable. But too often, as we all know, it's simply bad
practice, lack of training etc. Web servers can only help up to a point...

Best wishes,

Radu
PS: At least, one day, maximum-likelihood refinement programs will deal with
weak data satisfactorily :-) Nobody likes to throw data away.


> Dear all,
>
> to join Pierre's comments on what 'strange' things happen at the beamlines...
> yet not too strange for (too) many people: huge screening of salt crystals,
> complete data collection of dramatically low resolution data, full power
> coupled with 360Deg data collection etc. etc. etc. We do unfortunately see too
> many 'blind shots, deal with it later, and move on' experiments that it
> becomes depressive. I personally do not see why we would close our eyes to
> servers and/or data analysis tools that could help you think less, or better
> say help you understanding what is eventually happening with your data.
>
> Cheers, leo
>
> -
> Leonard Chavas
> -
> Synchrotron SOLEIL
> Proxima-I
> L'Orme des Merisiers
> Saint-Aubin - BP 48
> 91192 Gif-sur-Yvette Cedex
> France
> -
> Phone:  +33 169 359 746
> Mobile: +33 644 321 614
> E-mail: leonard.cha...@synchrotron-soleil.fr
> -
>
>> On 24 Nov 2017, at 00:23, Edward A. Berry  wrote:
>>
>> My 2 cents worth:
>> I think contaminer is an extremely useful service. I may be a sloppy
>> biochemist,
>> but I am not the only one. There are multiple structures in the database of
>> say
>> bacterioferritin or AcrB that were solved from crystals that were supposed
>> to
>> be something else. I remember in a discussion with the organizer of my
>> session
>> at a Gordon conference, she excitedly announced that there would be
>> preliminary
>> crystallographic data on respiratory Complex I. But by the time of the
>> conference
>> the authors discovered they had crystallized something else. And the
>> beautiful crystals
>> of Paracoccus Complex II (from Doug Rees's lab?) that graced the catalog of
>> Hampton Research (And I believe were part of the basis for the first
>> membrane
>> protein screen) never saw publication.  The authors of
>>  http://www.sciencedirect.com/science/article/pii/S0304416506000894
>> certainly feel there is a real problem.  Some proteins crystallize readily
>> even when
>> present as minor contaminants. And some protein complexes become more
>> heterogeneous
>> if over-purified due to partial loss of loosely-bound subunits.
>> Most of my career I've worked with high-abundance natural-source proteins.
>> During a recent foray into the realm of overexpressed proteins, my group
>> has
>> crystallized (and solved) at least a half dozen wrong proteins from E.
>> coli.
>> I spent months on one of these (ATCase in Rhomb sg with low-level
>> obverse/reverse
>> twinning that caused it to sometimes index as P3) Then solved the rest
>> rapidly
>> by checking the closest several hits with nearest-cell.  All of these E.coli
>> proteins
>> were already present in the PDB. I wonder how many were from accidental
>> crystals.
>> And now bacterioferritin (this time from M. smegmatis) keeps coming back to
>> haunt us.
>>
>> I would say any time with a new crystal when a molecular replacement
>> unexpectedly fails,
>> and even before you start to collect heavy atom or selenomet data, it would
>> be worth
>> to submit to nearest-cell and contaminer. I would be more likely to question
>> the
>> utility of an anisotropy correction server, given that modern
>> maximum-likelihood
>> refinement programs can deal with weak data satisfactorily (speaking from
>> ignorance- I'm sure supporting evidence and examples exist, I just haven't
>> bothered to look them up. And I know my colleagues here at Upstate have
>> used
>> anisotropy correction to good effect with a difficult problem- I hope they
>> weren't using filled-in maps!)
>> eab
>>
>> On 11/23/2017 03:24 PM, Tristan Croll wrote:
>>> Dear Radu,
>>>
>>> I think this is a little harsh. Biology is a fabulously messy thing, and
>>> very prone to doing the unexpected. See the excellent paper by
>>> Niedzialkowska et al. at
>>> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4815408/#!po=13.6905 for some
>>> examples. Sometimes unexpected things (which just happen to have a similar
>>> size to your target) carry through all the purification steps - I remember
>>> having terrible trouble isolating his-tagged IGF-I (not for
>>> crystallization) from Sf9 lysates due to a cathepsin-like protease that
>>> stuck doggedly to the Ni-NTA column 

Re: [ccp4bb] new ContaMiner features

[CHAVAS Leonard]

Dear Gerard

I should certainly be the one to blame, as I was the one spotting this 
behaviour to Stefan. Telling this, it could indeed be a problem with the data 
set, yet submitting the original mtz to ContaMiner provided with the strangely 
hoped and expected ContaMiner negative result. I made few tests afterwards, 
quick ones, with other mtz files treated or not with Staraniso, and although 
the direct results were not exactly the same as the extreme 'all positive' 
results noted earlier, it behaved strange (all 'possible positive', while 
standard non-contaminant data give you all 'negative' results).

I then ran MorDa standalone and found the same behaviour: for the first trial, 
it did found a solution... while there were none. Interestingly, Rfac/Rfree in 
the resulting MorDa solved structure was something like 50/20... I strongly 
believe that MorDa, and hence ContaMiner, scores its results on the Rfree 
value. Errors could have been spotted by looking at the ratio, which clearly 
was showing that something wrong is happening, operation either on MorDa or on 
ContaMiner side (or even both). 

Additional investigations are obviously welcome, however and for now, I guess 
the message from Stefan was more in the idea to warn people that having too 
many positive hits for one single data probably means something is wrong with 
the ContaMiner/MorDa processing, more than something is wrong with the dataset 
itself. That goes without saying that something could go wrong if the dataset 
is wrong, obviously... 

To Gerard and good willing developers: would you need the badly behaving data, 
please do let me know and I shall send it to you offline.

Cheers, leo

-
Leonard Chavas
- 
Synchrotron SOLEIL
Proxima-I
L'Orme des Merisiers
Saint-Aubin - BP 48
91192 Gif-sur-Yvette Cedex
France
- 
Phone:  +33 169 359 746
Mobile: +33 644 321 614
E-mail: leonard.cha...@synchrotron-soleil.fr
-

> On 23 Nov 2017, at 23:53, Gerard Bricogne <g...@globalphasing.com> wrote:
> 
> Dear Pierre,
> 
> Thank you for throwing some light on the circumstances under
> which the "suspicious" results cropped up :-) . Was the "Government
> Heatlh Warning" based on this one and only mtz file, then?
> 
> We would certainly be interested in examining this dataset for
> any anomalies in the anisotropy analysis and the mtz file it produced
> (perhaps you can simply give us the job ID on the server). However the
> "results" consist of the spurious recognition of molecules that are
> known not to be in the crystal, so they are the outcome of numerous
> unspecified steps downstream of the anisotropy analysis itself, that
> in the end produce a "score" that is misleading. It would be useful to
> have at least some idea of what those steps are in order to identify
> the possible causes of the erroneous detections. 
> 
> 
> With best wishes,
> 
>  Gerard.
> 
> --
> On Thu, Nov 23, 2017 at 10:05:09PM +, LEGRAND Pierre wrote:
>> Dear Gérard,
>> 
>> As being part of the group how has initially raised the issue to Stefan, I 
>> stand out to try clarifying a misinterpretation.
>> In brief, because we are happy users of StarAniso, it happened that we have 
>> submitted an mtz that it had produced to the ContaMiner server. We were very 
>> surprised to find that almost all contaminants evaluated gave high scores 
>> according to MoRDa. On the contrary, using an "isotropicaly" treated mtz, no 
>> hit could be detected in by ContaMiner.
>> 
>> Being collected on PROXIMA-1 beamline, it coun't be a "badly collected 
>> datasets" ;-)
>> 
>> So, most probably, as you suggested, the issue is linked to some bad 
>> assumptions made by MoRDa or inadequate criteria choices _in_the_cases_ of 
>> "corrected" anisotropic data. 
>> We can probably provide some examples of datasets to the developers willing 
>> to pursue investigations on this.
>> 
>> I completely agree with Tristan! I have to admit having lost several weeks 
>> in my career (if not months) with "contaminated" crystals. And working on an 
>> MX beamline, I can testify that this is unfortunately happening regularly. 
>> 
>> I will finish with a big thanks to all the (StarAniso/ContaMiner/MoRDA) 
>> developers how are helping us to untwist the unavoidable experimental 
>> mess/reality.
>> 
>> Kind regards,
>> Pierre 
>> 
>> De : CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] de la part de Gerard 
>> Bricogne [g...@globalphasing.com]
>> Envoyé : jeudi 23 novembre 2017 19:34
>> À : CCP4BB@JISCMAIL.AC.UK
>> Objet : Re: [ccp4bb] new ContaMiner features
>> 
>> Dea

Re: [ccp4bb] new ContaMiner features

[CHAVAS Leonard]

Dear all, 

to join Pierre's comments on what 'strange' things happen at the beamlines... 
yet not too strange for (too) many people: huge screening of salt crystals, 
complete data collection of dramatically low resolution data, full power 
coupled with 360Deg data collection etc. etc. etc. We do unfortunately see too 
many 'blind shots, deal with it later, and move on' experiments that it becomes 
depressive. I personally do not see why we would close our eyes to servers 
and/or data analysis tools that could help you think less, or better say help 
you understanding what is eventually happening with your data.

Cheers, leo

-
Leonard Chavas
- 
Synchrotron SOLEIL
Proxima-I
L'Orme des Merisiers
Saint-Aubin - BP 48
91192 Gif-sur-Yvette Cedex
France
- 
Phone:  +33 169 359 746
Mobile: +33 644 321 614
E-mail: leonard.cha...@synchrotron-soleil.fr
-

> On 24 Nov 2017, at 00:23, Edward A. Berry  wrote:
> 
> My 2 cents worth:
> I think contaminer is an extremely useful service. I may be a sloppy 
> biochemist,
> but I am not the only one. There are multiple structures in the database of 
> say
> bacterioferritin or AcrB that were solved from crystals that were supposed to
> be something else. I remember in a discussion with the organizer of my session
> at a Gordon conference, she excitedly announced that there would be 
> preliminary
> crystallographic data on respiratory Complex I. But by the time of the 
> conference
> the authors discovered they had crystallized something else. And the 
> beautiful crystals
> of Paracoccus Complex II (from Doug Rees's lab?) that graced the catalog of
> Hampton Research (And I believe were part of the basis for the first membrane
> protein screen) never saw publication.  The authors of
>  http://www.sciencedirect.com/science/article/pii/S0304416506000894
> certainly feel there is a real problem.  Some proteins crystallize readily 
> even when
> present as minor contaminants. And some protein complexes become more 
> heterogeneous
> if over-purified due to partial loss of loosely-bound subunits.
> Most of my career I've worked with high-abundance natural-source proteins.
> During a recent foray into the realm of overexpressed proteins, my group has
> crystallized (and solved) at least a half dozen wrong proteins from E. coli.
> I spent months on one of these (ATCase in Rhomb sg with low-level 
> obverse/reverse
> twinning that caused it to sometimes index as P3) Then solved the rest rapidly
> by checking the closest several hits with nearest-cell.  All of these E.coli 
> proteins
> were already present in the PDB. I wonder how many were from accidental 
> crystals.
> And now bacterioferritin (this time from M. smegmatis) keeps coming back to 
> haunt us.
> 
> I would say any time with a new crystal when a molecular replacement 
> unexpectedly fails,
> and even before you start to collect heavy atom or selenomet data, it would 
> be worth
> to submit to nearest-cell and contaminer. I would be more likely to question 
> the
> utility of an anisotropy correction server, given that modern 
> maximum-likelihood
> refinement programs can deal with weak data satisfactorily (speaking from
> ignorance- I'm sure supporting evidence and examples exist, I just haven't
> bothered to look them up. And I know my colleagues here at Upstate have used
> anisotropy correction to good effect with a difficult problem- I hope they
> weren't using filled-in maps!)
> eab
> 
> On 11/23/2017 03:24 PM, Tristan Croll wrote:
>> Dear Radu,
>> 
>> I think this is a little harsh. Biology is a fabulously messy thing, and 
>> very prone to doing the unexpected. See the excellent paper by 
>> Niedzialkowska et al. at 
>> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4815408/#!po=13.6905 for some 
>> examples. Sometimes unexpected things (which just happen to have a similar 
>> size to your target) carry through all the purification steps - I remember 
>> having terrible trouble isolating his-tagged IGF-I (not for crystallization) 
>> from Sf9 lysates due to a cathepsin-like protease that stuck doggedly to the 
>> Ni-NTA column even under 8M urea, yet co-eluted in imidazole. Even if 
>> contaminant proteins are barely visible on your SDS-PAGE gel, if they 
>> crystallise easily and your target doesn’t...  all these things and many 
>> others have happened, and have undoubtedly driven the occasional poor grad 
>> student to the brink of giving it all up.
>> 
>> I guess in these days of relatively cheap and ubiquitous mass spec it may 
>> make sense to sacrifice a crystal to trypsin digest and MS/MS sequencing 
>> just for peace of mind, but in the average case I think that’s likely to be 
>> overkill. Shooting crystals at a synchrotron is now very routine, so I think 
>> it makes perfect sense to provide a computational check for the (hopefully 
>> rare) surprise case.
>> 
>> Best regards,
>> 
>> Tristan
>> Tristan Croll
>> Research Fellow
>> Cambridge Institute for Medical Research
>> 

Re: [ccp4bb] new ContaMiner features

[Parthasarathy Sampathkumar]

Hi All,

To add, on couple of occasions I re-determined the structure of so-called
"contaminants". Once, the structure of Secreted Ferritin (PDB 1Z6O) from
crystals that were supposedly that of TNF ligand:receptor complex (proteins
expressed in Tni cells), and in the second instant re-determined the
structure of bacterial carbonic-anhydrase. On both instants, contaminants
were identified through cell-constant search (at that time no ContaMiner
server available) in PDB, after realizing that standard Molecular
Replacement did not work. Luckily, did not spend too much time on these
cases.

Best Wishes to All for "contaminant" free crystals on this Thanksgiving Day,

Partha



On Thu, Nov 23, 2017 at 6:23 PM, Edward A. Berry  wrote:

> My 2 cents worth:
> I think contaminer is an extremely useful service. I may be a sloppy
> biochemist,
> but I am not the only one. There are multiple structures in the database
> of say
> bacterioferritin or AcrB that were solved from crystals that were supposed
> to
> be something else. I remember in a discussion with the organizer of my
> session
> at a Gordon conference, she excitedly announced that there would be
> preliminary
> crystallographic data on respiratory Complex I. But by the time of the
> conference
> the authors discovered they had crystallized something else. And the
> beautiful crystals
> of Paracoccus Complex II (from Doug Rees's lab?) that graced the catalog of
> Hampton Research (And I believe were part of the basis for the first
> membrane
> protein screen) never saw publication.  The authors of
>   http://www.sciencedirect.com/science/article/pii/S0304416506000894
> certainly feel there is a real problem.  Some proteins crystallize readily
> even when
> present as minor contaminants. And some protein complexes become more
> heterogeneous
> if over-purified due to partial loss of loosely-bound subunits.
> Most of my career I've worked with high-abundance natural-source proteins.
> During a recent foray into the realm of overexpressed proteins, my group
> has
> crystallized (and solved) at least a half dozen wrong proteins from E.
> coli.
> I spent months on one of these (ATCase in Rhomb sg with low-level
> obverse/reverse
> twinning that caused it to sometimes index as P3) Then solved the rest
> rapidly
> by checking the closest several hits with nearest-cell.  All of these
> E.coli proteins
> were already present in the PDB. I wonder how many were from accidental
> crystals.
> And now bacterioferritin (this time from M. smegmatis) keeps coming back
> to haunt us.
>
> I would say any time with a new crystal when a molecular replacement
> unexpectedly fails,
> and even before you start to collect heavy atom or selenomet data, it
> would be worth
> to submit to nearest-cell and contaminer. I would be more likely to
> question the
> utility of an anisotropy correction server, given that modern
> maximum-likelihood
> refinement programs can deal with weak data satisfactorily (speaking from
> ignorance- I'm sure supporting evidence and examples exist, I just haven't
> bothered to look them up. And I know my colleagues here at Upstate have
> used
> anisotropy correction to good effect with a difficult problem- I hope they
> weren't using filled-in maps!)
> eab
>
> On 11/23/2017 03:24 PM, Tristan Croll wrote:
>
>> Dear Radu,
>>
>> I think this is a little harsh. Biology is a fabulously messy thing, and
>> very prone to doing the unexpected. See the excellent paper by
>> Niedzialkowska et al. at https://www.ncbi.nlm.nih.gov/p
>> mc/articles/PMC4815408/#!po=13.6905 for some examples. Sometimes
>> unexpected things (which just happen to have a similar size to your target)
>> carry through all the purification steps - I remember having terrible
>> trouble isolating his-tagged IGF-I (not for crystallization) from Sf9
>> lysates due to a cathepsin-like protease that stuck doggedly to the Ni-NTA
>> column even under 8M urea, yet co-eluted in imidazole. Even if contaminant
>> proteins are barely visible on your SDS-PAGE gel, if they crystallise
>> easily and your target doesn’t...  all these things and many others have
>> happened, and have undoubtedly driven the occasional poor grad student to
>> the brink of giving it all up.
>>
>> I guess in these days of relatively cheap and ubiquitous mass spec it may
>> make sense to sacrifice a crystal to trypsin digest and MS/MS sequencing
>> just for peace of mind, but in the average case I think that’s likely to be
>> overkill. Shooting crystals at a synchrotron is now very routine, so I
>> think it makes perfect sense to provide a computational check for the
>> (hopefully rare) surprise case.
>>
>> Best regards,
>>
>> Tristan
>> Tristan Croll
>> Research Fellow
>> Cambridge Institute for Medical Research
>> University of Cambridge CB2 0XY
>>
>>
>>
>> On 23 Nov 2017, at 19:35, r...@mrc-lmb.cam.ac.uk > r...@mrc-lmb.cam.ac.uk> wrote:
>>
>> Dear Stefan,
>>>
>>> Just a couple of thoughts:
>>>
>>> - first of 

Re: [ccp4bb] new ContaMiner features

[Edward A. Berry]

My 2 cents worth:
I think contaminer is an extremely useful service. I may be a sloppy biochemist,
but I am not the only one. There are multiple structures in the database of say
bacterioferritin or AcrB that were solved from crystals that were supposed to
be something else. I remember in a discussion with the organizer of my session
at a Gordon conference, she excitedly announced that there would be preliminary
crystallographic data on respiratory Complex I. But by the time of the 
conference
the authors discovered they had crystallized something else. And the beautiful 
crystals
of Paracoccus Complex II (from Doug Rees's lab?) that graced the catalog of
Hampton Research (And I believe were part of the basis for the first membrane
protein screen) never saw publication.  The authors of
  http://www.sciencedirect.com/science/article/pii/S0304416506000894
certainly feel there is a real problem.  Some proteins crystallize readily even 
when
present as minor contaminants. And some protein complexes become more 
heterogeneous
if over-purified due to partial loss of loosely-bound subunits.
Most of my career I've worked with high-abundance natural-source proteins.
During a recent foray into the realm of overexpressed proteins, my group has
crystallized (and solved) at least a half dozen wrong proteins from E. coli.
I spent months on one of these (ATCase in Rhomb sg with low-level 
obverse/reverse
twinning that caused it to sometimes index as P3) Then solved the rest rapidly
by checking the closest several hits with nearest-cell.  All of these E.coli 
proteins
were already present in the PDB. I wonder how many were from accidental 
crystals.
And now bacterioferritin (this time from M. smegmatis) keeps coming back to 
haunt us.

I would say any time with a new crystal when a molecular replacement 
unexpectedly fails,
and even before you start to collect heavy atom or selenomet data, it would be 
worth
to submit to nearest-cell and contaminer. I would be more likely to question the
utility of an anisotropy correction server, given that modern maximum-likelihood
refinement programs can deal with weak data satisfactorily (speaking from
ignorance- I'm sure supporting evidence and examples exist, I just haven't
bothered to look them up. And I know my colleagues here at Upstate have used
anisotropy correction to good effect with a difficult problem- I hope they
weren't using filled-in maps!)
eab

On 11/23/2017 03:24 PM, Tristan Croll wrote:

Dear Radu,

I think this is a little harsh. Biology is a fabulously messy thing, and very 
prone to doing the unexpected. See the excellent paper by Niedzialkowska et al. 
at https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4815408/#!po=13.6905 for some 
examples. Sometimes unexpected things (which just happen to have a similar size 
to your target) carry through all the purification steps - I remember having 
terrible trouble isolating his-tagged IGF-I (not for crystallization) from Sf9 
lysates due to a cathepsin-like protease that stuck doggedly to the Ni-NTA 
column even under 8M urea, yet co-eluted in imidazole. Even if contaminant 
proteins are barely visible on your SDS-PAGE gel, if they crystallise easily 
and your target doesn’t...  all these things and many others have happened, and 
have undoubtedly driven the occasional poor grad student to the brink of giving 
it all up.

I guess in these days of relatively cheap and ubiquitous mass spec it may make 
sense to sacrifice a crystal to trypsin digest and MS/MS sequencing just for 
peace of mind, but in the average case I think that’s likely to be overkill. 
Shooting crystals at a synchrotron is now very routine, so I think it makes 
perfect sense to provide a computational check for the (hopefully rare) 
surprise case.

Best regards,

Tristan
Tristan Croll
Research Fellow
Cambridge Institute for Medical Research
University of Cambridge CB2 0XY


On 23 Nov 2017, at 19:35, r...@mrc-lmb.cam.ac.uk 
 wrote:


Dear Stefan,

Just a couple of thoughts:

- first of all I think that Gerard is absolutely right, it would have been
nice to raise such issues first with the developers. In my experience,
Staraniso does a fantastic job if used correctly.

- but if you're OK with public trials, may I ask: why on Earth would anybody
need ContaMiner? Are you trying to offer some sort of computational cure for
sloppy biochemistry? There is zero point in crystallizing crap samples, sorry
to say this. In my 17 or so years in Strubi I've never heard of anybody
crystallizing a "contaminant", being it a purification tag or whatever.

I suppose this might have happened to somebody you know, hence the motivation
to spend time on the bizarre ContaMiner. Which is a pity, a silly outcome
would only teach people to do their job (or train their robots) properly.

Best wishes,

Radu

--
Radu Aricescu
MRC Laboratory of Molecular Biology
Francis Crick Avenue
Cambridge Biomedical Campus
Cambridge CB2 0QH, U.K.
tel: 

Re: [ccp4bb] new ContaMiner features

[Gerard Bricogne]

Dear Pierre,

 Thank you for throwing some light on the circumstances under
which the "suspicious" results cropped up :-) . Was the "Government
Heatlh Warning" based on this one and only mtz file, then?

 We would certainly be interested in examining this dataset for
any anomalies in the anisotropy analysis and the mtz file it produced
(perhaps you can simply give us the job ID on the server). However the
"results" consist of the spurious recognition of molecules that are
known not to be in the crystal, so they are the outcome of numerous
unspecified steps downstream of the anisotropy analysis itself, that
in the end produce a "score" that is misleading. It would be useful to
have at least some idea of what those steps are in order to identify
the possible causes of the erroneous detections. 


 With best wishes,
 
  Gerard.

--
On Thu, Nov 23, 2017 at 10:05:09PM +, LEGRAND Pierre wrote:
> Dear Gérard,
> 
> As being part of the group how has initially raised the issue to Stefan, I 
> stand out to try clarifying a misinterpretation.
> In brief, because we are happy users of StarAniso, it happened that we have 
> submitted an mtz that it had produced to the ContaMiner server. We were very 
> surprised to find that almost all contaminants evaluated gave high scores 
> according to MoRDa. On the contrary, using an "isotropicaly" treated mtz, no 
> hit could be detected in by ContaMiner.
> 
> Being collected on PROXIMA-1 beamline, it coun't be a "badly collected 
> datasets" ;-)
> 
> So, most probably, as you suggested, the issue is linked to some bad 
> assumptions made by MoRDa or inadequate criteria choices _in_the_cases_ of 
> "corrected" anisotropic data. 
> We can probably provide some examples of datasets to the developers willing 
> to pursue investigations on this.
> 
> I completely agree with Tristan! I have to admit having lost several weeks in 
> my career (if not months) with "contaminated" crystals. And working on an MX 
> beamline, I can testify that this is unfortunately happening regularly. 
> 
> I will finish with a big thanks to all the (StarAniso/ContaMiner/MoRDA) 
> developers how are helping us to untwist the unavoidable experimental 
> mess/reality.
> 
> Kind regards,
> Pierre 
> 
> De : CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] de la part de Gerard 
> Bricogne [g...@globalphasing.com]
> Envoyé : jeudi 23 novembre 2017 19:34
> À : CCP4BB@JISCMAIL.AC.UK
> Objet : Re: [ccp4bb] new ContaMiner features
> 
> Dear Stefan,
> 
>  Regarding your final paragraph: your server carries a warning
> with the exact wording:
> 
>  "Submitting StarAniso files can give you suspicious results. Use
> with care!"
> 
>  It seems rather regrettable that you are posting such a public
> warning without ever having contacted the STARANISO developers about
> your observations, nor giving any information about what you call
> "suspicious" or what the "care" you recommend would consist of.
> 
>  We have taken a great deal of care ourselves in developing the
> program and offering it to the community through a server, and the
> least we would have expected is that any pattern of "suspicious"
> results would be referred to us so that we could investigate them.
> There may be some assumptions made in MoRDa that we are not aware of,
> that might be incompatible with assumptions made in STARANISO - who
> knows? Or it could be that some particularly badly collected datasets
> are made to look worse after their anisotropy analysis.
> 
>  Could we discuss your observations, and what it is exactly that
> you call "suspicious", before they end up being referred to in such an
> uninformative manner as some sort of "Government Health Warning"?
> 
>  I think that would be nice :-) and we would be only too keen to
> take whatever extra "care" is needed ourselves. We would all learn
> something.
> 
> 
>  With best wishes,
> 
>   Gerard.
> 
> (on behalf of the STARANISO developers)
> 
> --
> On Thu, Nov 23, 2017 at 05:02:39PM +0100, Stefan Arold wrote:
> > Dear Community,
> >
> > A quick message to announce the following two new features on our
> > ContaMiner web server for the automated detection of unwantedly
> > crystallised contaminants (
> > https://strube.cbrc.kaust.edu.sa/contaminer/submit)
> >
> > 1) online visualisation of 2FoFc and FoFc maps. In cases of positive
> > results, the ‘UglyMol’ tab allows to inspect 2FoFc and FoFc maps directly
> > in the web browser. Thi
> >
> > 2

Re: [ccp4bb] new ContaMiner features

[Mike Lawrence]

Dear Radu,

here's an example from 11 years ago.

https://www.ncbi.nlm.nih.gov/pubmed/16929094

ContaMiner would have been useful here in that it would terminated the 
crystallographic endeavour earlier

(In this case, however, serendipitous crystallization and structure solution of 
the trace contaminant in fact led to some interesting results).

I guess the issue is the following: if you are trying to crystallise an 
expensive-to-produce protein (e.g., one that requires large-scale mammalian 
cell culture and multiple, high-loss chromatographic steps), would you invest 
effort in developing further rounds of purification to make absolutely sure 
that your protein is contaminant-free before at least having a crack at 
crystallization trials with the almost-pure protein while you wait for more 
cells to grow?

best wishes

Mike


On 24 Nov 2017, at 6:35 am, 
r...@mrc-lmb.cam.ac.uk wrote:

Dear Stefan,

Just a couple of thoughts:

- first of all I think that Gerard is absolutely right, it would have been
nice to raise such issues first with the developers. In my experience,
Staraniso does a fantastic job if used correctly.

- but if you're OK with public trials, may I ask: why on Earth would anybody
need ContaMiner? Are you trying to offer some sort of computational cure for
sloppy biochemistry? There is zero point in crystallizing crap samples, sorry
to say this. In my 17 or so years in Strubi I've never heard of anybody
crystallizing a "contaminant", being it a purification tag or whatever.

I suppose this might have happened to somebody you know, hence the motivation
to spend time on the bizarre ContaMiner. Which is a pity, a silly outcome
would only teach people to do their job (or train their robots) properly.

Best wishes,

Radu

--
Radu Aricescu
MRC Laboratory of Molecular Biology
Francis Crick Avenue
Cambridge Biomedical Campus
Cambridge CB2 0QH, U.K.
tel: +44-(0)1223-267049
fax: +44-(0)1223-268305
www: http://www2.mrc-lmb.cam.ac.uk/group-leaders/a-to-g/radu-aricescu

Dear Stefan,

Regarding your final paragraph: your server carries a warning
with the exact wording:

"Submitting StarAniso files can give you suspicious results. Use
with care!"

It seems rather regrettable that you are posting such a public
warning without ever having contacted the STARANISO developers about
your observations, nor giving any information about what you call
"suspicious" or what the "care" you recommend would consist of.

We have taken a great deal of care ourselves in developing the
program and offering it to the community through a server, and the
least we would have expected is that any pattern of "suspicious"
results would be referred to us so that we could investigate them.
There may be some assumptions made in MoRDa that we are not aware of,
that might be incompatible with assumptions made in STARANISO - who
knows? Or it could be that some particularly badly collected datasets
are made to look worse after their anisotropy analysis.

Could we discuss your observations, and what it is exactly that
you call "suspicious", before they end up being referred to in such an
uninformative manner as some sort of "Government Health Warning"?

I think that would be nice :-) and we would be only too keen to
take whatever extra "care" is needed ourselves. We would all learn
something.


With best wishes,

 Gerard.

(on behalf of the STARANISO developers)

--
On Thu, Nov 23, 2017 at 05:02:39PM +0100, Stefan Arold wrote:
Dear Community,

A quick message to announce the following two new features on our
ContaMiner web server for the automated detection of unwantedly
crystallised contaminants (
https://strube.cbrc.kaust.edu.sa/contaminer/submit)

1) online visualisation of 2FoFc and FoFc maps. In cases of positive
results, the ‘UglyMol’ tab allows to inspect 2FoFc and FoFc maps
directly
in the web browser. Thi

2) life-update. Previously, results were sent to you once all ~2000 MR jobs
were finished. Now, the individual results for each potential contaminant
will appear as soon as they are finished. This feature should substantially
shorten the time for identifying positive results (i.e. contaminant
detected), which are terminated faster than negative ones.

3) custom contaminants. In the ‘Advanced’ tab, users can upload own PDB
files (more than one is possible) to be included as search models. This
feature can be used to include PDB files from your lab bench neighbour’s
project to test for potential lab internal contaminations (through
bacterial contamination or through mix-up of plasmids or glycerol stocks).
This feature could also be ‘abused’ as a means to use the MoRDa pipeline
to
run molecular replacements with template structures that are not yet
deposited in the PDB; for example to run molecular replacement and initial
refinement for liganded or complexed versions of an unpublished structure.
This might be particularly interesting for crystallographers away 

Re: [ccp4bb] new ContaMiner features

[radu]

Hi Tom, Tristan, Pierre,

So long that some people find ContaMiner useful, than fair enough :-) But I
still find it really hard to believe that this is a "common" occurrence. Maybe
"regular" at beamlines (who are not to blame of course), but I doubt that
frequency is high. Otherwise, they should really keep away from certain users
;-))

For curiosity I've checked with people around (I happen to be in Oxford
tonight), including some previously involved in running a rather successful,
and high throughput, structural genomics facility here. The answers were, so
far, all negative (i.e. thankfully haven't encountered of such accidents). I'm
wondering whether "crystallisation contaminants" might be related to a
particular type of targets, or expression system, or purification
strategies... I'll check the paper Tristan suggested when I get the chance.

Best wishes,

Radu


> I agree with Tristan, it can be quite easy to crystallise a contaminant even
> when one is trying to be careful during the purification process.
> Before everyone had a mass spec, looking at gels didn't tell you as much as
> you needed to know, as many proteins don't stain well, so are hard to see on
> the gel (and as mentioned, can be in very small quantities and still
> crystallise).
>
> Cheers, tom
>
> -Original Message-
> From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of
> r...@mrc-lmb.cam.ac.uk
> Sent: Friday, 24 November 2017 6:36 AM
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: Re: [ccp4bb] new ContaMiner features
>
> Dear Stefan,
>
> Just a couple of thoughts:
>
> - first of all I think that Gerard is absolutely right, it would have been
> nice to raise such issues first with the developers. In my experience,
> Staraniso does a fantastic job if used correctly.
>
> - but if you're OK with public trials, may I ask: why on Earth would anybody
> need ContaMiner? Are you trying to offer some sort of computational cure for
> sloppy biochemistry? There is zero point in crystallizing crap samples, sorry
> to say this. In my 17 or so years in Strubi I've never heard of anybody
> crystallizing a "contaminant", being it a purification tag or whatever.
>
> I suppose this might have happened to somebody you know, hence the motivation
> to spend time on the bizarre ContaMiner. Which is a pity, a silly outcome
> would only teach people to do their job (or train their robots) properly.
>
> Best wishes,
>
> Radu
>
> --
> Radu Aricescu
> MRC Laboratory of Molecular Biology
> Francis Crick Avenue
> Cambridge Biomedical Campus
> Cambridge CB2 0QH, U.K.
> tel: +44-(0)1223-267049
> fax: +44-(0)1223-268305
> www: http://www2.mrc-lmb.cam.ac.uk/group-leaders/a-to-g/radu-aricescu
>
>> Dear Stefan,
>>
>>  Regarding your final paragraph: your server carries a warning
>> with the exact wording:
>>
>>  "Submitting StarAniso files can give you suspicious results. Use
>> with care!"
>>
>>  It seems rather regrettable that you are posting such a public
>> warning without ever having contacted the STARANISO developers about
>> your observations, nor giving any information about what you call
>> "suspicious" or what the "care" you recommend would consist of.
>>
>>  We have taken a great deal of care ourselves in developing the
>> program and offering it to the community through a server, and the
>> least we would have expected is that any pattern of "suspicious"
>> results would be referred to us so that we could investigate them.
>> There may be some assumptions made in MoRDa that we are not aware of,
>> that might be incompatible with assumptions made in STARANISO - who
>> knows? Or it could be that some particularly badly collected datasets
>> are made to look worse after their anisotropy analysis.
>>
>>  Could we discuss your observations, and what it is exactly that
>> you call "suspicious", before they end up being referred to in such an
>> uninformative manner as some sort of "Government Health Warning"?
>>
>>  I think that would be nice :-) and we would be only too keen to
>> take whatever extra "care" is needed ourselves. We would all learn
>> something.
>>
>>
>>  With best wishes,
>>
>>   Gerard.
>>
>> (on behalf of the STARANISO developers)
>>
>> --
>> On Thu, Nov 23, 2017 at 05:02:39PM +0100, Stefan Arold wrote:
>>> Dear Community,
>>>
>>> A quick message to announce the following two new features on our
>>> ContaMiner web server for the automated detection of unwantedly
>>> 

Re: [ccp4bb] new ContaMiner features

[Tom Peat]

I agree with Tristan, it can be quite easy to crystallise a contaminant even 
when one is trying to be careful during the purification process. 
Before everyone had a mass spec, looking at gels didn't tell you as much as you 
needed to know, as many proteins don't stain well, so are hard to see on the 
gel (and as mentioned, can be in very small quantities and still crystallise). 

Cheers, tom

-Original Message-
From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of 
r...@mrc-lmb.cam.ac.uk
Sent: Friday, 24 November 2017 6:36 AM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] new ContaMiner features

Dear Stefan,

Just a couple of thoughts:

- first of all I think that Gerard is absolutely right, it would have been nice 
to raise such issues first with the developers. In my experience, Staraniso 
does a fantastic job if used correctly.

- but if you're OK with public trials, may I ask: why on Earth would anybody 
need ContaMiner? Are you trying to offer some sort of computational cure for 
sloppy biochemistry? There is zero point in crystallizing crap samples, sorry 
to say this. In my 17 or so years in Strubi I've never heard of anybody 
crystallizing a "contaminant", being it a purification tag or whatever.

I suppose this might have happened to somebody you know, hence the motivation 
to spend time on the bizarre ContaMiner. Which is a pity, a silly outcome would 
only teach people to do their job (or train their robots) properly.

Best wishes,

Radu

--
Radu Aricescu
MRC Laboratory of Molecular Biology
Francis Crick Avenue
Cambridge Biomedical Campus
Cambridge CB2 0QH, U.K.
tel: +44-(0)1223-267049
fax: +44-(0)1223-268305
www: http://www2.mrc-lmb.cam.ac.uk/group-leaders/a-to-g/radu-aricescu

> Dear Stefan,
>
>  Regarding your final paragraph: your server carries a warning 
> with the exact wording:
>
>  "Submitting StarAniso files can give you suspicious results. Use 
> with care!"
>
>  It seems rather regrettable that you are posting such a public 
> warning without ever having contacted the STARANISO developers about 
> your observations, nor giving any information about what you call 
> "suspicious" or what the "care" you recommend would consist of.
>
>  We have taken a great deal of care ourselves in developing the 
> program and offering it to the community through a server, and the 
> least we would have expected is that any pattern of "suspicious"
> results would be referred to us so that we could investigate them.
> There may be some assumptions made in MoRDa that we are not aware of, 
> that might be incompatible with assumptions made in STARANISO - who 
> knows? Or it could be that some particularly badly collected datasets 
> are made to look worse after their anisotropy analysis.
>
>  Could we discuss your observations, and what it is exactly that 
> you call "suspicious", before they end up being referred to in such an 
> uninformative manner as some sort of "Government Health Warning"?
>
>  I think that would be nice :-) and we would be only too keen to 
> take whatever extra "care" is needed ourselves. We would all learn 
> something.
>
>
>  With best wishes,
>
>   Gerard.
>
> (on behalf of the STARANISO developers)
>
> --
> On Thu, Nov 23, 2017 at 05:02:39PM +0100, Stefan Arold wrote:
>> Dear Community,
>>
>> A quick message to announce the following two new features on our 
>> ContaMiner web server for the automated detection of unwantedly 
>> crystallised contaminants (
>> https://strube.cbrc.kaust.edu.sa/contaminer/submit)
>>
>> 1) online visualisation of 2FoFc and FoFc maps. In cases of positive 
>> results, the ‘UglyMol’ tab allows to inspect 2FoFc and FoFc maps 
>> directly in the web browser. Thi
>>
>> 2) life-update. Previously, results were sent to you once all ~2000 
>> MR jobs were finished. Now, the individual results for each potential 
>> contaminant will appear as soon as they are finished. This feature 
>> should substantially shorten the time for identifying positive 
>> results (i.e. contaminant detected), which are terminated faster than 
>> negative ones.
>>
>> 3) custom contaminants. In the ‘Advanced’ tab, users can upload own 
>> PDB files (more than one is possible) to be included as search 
>> models. This feature can be used to include PDB files from your lab 
>> bench neighbour’s project to test for potential lab internal 
>> contaminations (through bacterial contamination or through mix-up of 
>> plasmids or glycerol stocks).
>> This feature could also be ‘abused’ as a means to use the MoRDa 
>> pipeline to run molecular replacements with templat

Re: [ccp4bb] new ContaMiner features

[LEGRAND Pierre]

Dear Gérard,

As being part of the group how has initially raised the issue to Stefan, I 
stand out to try clarifying a misinterpretation.
In brief, because we are happy users of StarAniso, it happened that we have 
submitted an mtz that it had produced to the ContaMiner server. We were very 
surprised to find that almost all contaminants evaluated gave high scores 
according to MoRDa. On the contrary, using an "isotropicaly" treated mtz, no 
hit could be detected in by ContaMiner.

Being collected on PROXIMA-1 beamline, it coun't be a "badly collected 
datasets" ;-)

So, most probably, as you suggested, the issue is linked to some bad 
assumptions made by MoRDa or inadequate criteria choices _in_the_cases_ of 
"corrected" anisotropic data. 
We can probably provide some examples of datasets to the developers willing to 
pursue investigations on this.

I completely agree with Tristan! I have to admit having lost several weeks in 
my career (if not months) with "contaminated" crystals. And working on an MX 
beamline, I can testify that this is unfortunately happening regularly. 

I will finish with a big thanks to all the (StarAniso/ContaMiner/MoRDA) 
developers how are helping us to untwist the unavoidable experimental 
mess/reality.

Kind regards,
Pierre 

De : CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] de la part de Gerard Bricogne 
[g...@globalphasing.com]
Envoyé : jeudi 23 novembre 2017 19:34
À : CCP4BB@JISCMAIL.AC.UK
Objet : Re: [ccp4bb] new ContaMiner features

Dear Stefan,

 Regarding your final paragraph: your server carries a warning
with the exact wording:

 "Submitting StarAniso files can give you suspicious results. Use
with care!"

 It seems rather regrettable that you are posting such a public
warning without ever having contacted the STARANISO developers about
your observations, nor giving any information about what you call
"suspicious" or what the "care" you recommend would consist of.

 We have taken a great deal of care ourselves in developing the
program and offering it to the community through a server, and the
least we would have expected is that any pattern of "suspicious"
results would be referred to us so that we could investigate them.
There may be some assumptions made in MoRDa that we are not aware of,
that might be incompatible with assumptions made in STARANISO - who
knows? Or it could be that some particularly badly collected datasets
are made to look worse after their anisotropy analysis.

 Could we discuss your observations, and what it is exactly that
you call "suspicious", before they end up being referred to in such an
uninformative manner as some sort of "Government Health Warning"?

 I think that would be nice :-) and we would be only too keen to
take whatever extra "care" is needed ourselves. We would all learn
something.


 With best wishes,

  Gerard.

(on behalf of the STARANISO developers)

--
On Thu, Nov 23, 2017 at 05:02:39PM +0100, Stefan Arold wrote:
> Dear Community,
>
> A quick message to announce the following two new features on our
> ContaMiner web server for the automated detection of unwantedly
> crystallised contaminants (
> https://strube.cbrc.kaust.edu.sa/contaminer/submit)
>
> 1) online visualisation of 2FoFc and FoFc maps. In cases of positive
> results, the ‘UglyMol’ tab allows to inspect 2FoFc and FoFc maps directly
> in the web browser. Thi
>
> 2) life-update. Previously, results were sent to you once all ~2000 MR jobs
> were finished. Now, the individual results for each potential contaminant
> will appear as soon as they are finished. This feature should substantially
> shorten the time for identifying positive results (i.e. contaminant
> detected), which are terminated faster than negative ones.
>
> 3) custom contaminants. In the ‘Advanced’ tab, users can upload own PDB
> files (more than one is possible) to be included as search models. This
> feature can be used to include PDB files from your lab bench neighbour’s
> project to test for potential lab internal contaminations (through
> bacterial contamination or through mix-up of plasmids or glycerol stocks).
> This feature could also be ‘abused’ as a means to use the MoRDa pipeline to
> run molecular replacements with template structures that are not yet
> deposited in the PDB; for example to run molecular replacement and initial
> refinement for liganded or complexed versions of an unpublished structure.
> This might be particularly interesting for crystallographers away from
> their usual home software environment (e.g. at the beamline).
>
> Finally, a word of warning – Staraniso files might give false positives if
> they have large anisotropic cuts.
>
> Keep your crystals clean!
>
> With best wis

Re: [ccp4bb] new ContaMiner features

[Tristan Croll]

Dear Radu,

I think this is a little harsh. Biology is a fabulously messy thing, and very 
prone to doing the unexpected. See the excellent paper by Niedzialkowska et al. 
at https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4815408/#!po=13.6905 for some 
examples. Sometimes unexpected things (which just happen to have a similar size 
to your target) carry through all the purification steps - I remember having 
terrible trouble isolating his-tagged IGF-I (not for crystallization) from Sf9 
lysates due to a cathepsin-like protease that stuck doggedly to the Ni-NTA 
column even under 8M urea, yet co-eluted in imidazole. Even if contaminant 
proteins are barely visible on your SDS-PAGE gel, if they crystallise easily 
and your target doesn’t...  all these things and many others have happened, and 
have undoubtedly driven the occasional poor grad student to the brink of giving 
it all up.

I guess in these days of relatively cheap and ubiquitous mass spec it may make 
sense to sacrifice a crystal to trypsin digest and MS/MS sequencing just for 
peace of mind, but in the average case I think that’s likely to be overkill. 
Shooting crystals at a synchrotron is now very routine, so I think it makes 
perfect sense to provide a computational check for the (hopefully rare) 
surprise case.

Best regards,

Tristan
 
 
Tristan Croll
Research Fellow
Cambridge Institute for Medical Research
University of Cambridge CB2 0XY
 

 

> On 23 Nov 2017, at 19:35, r...@mrc-lmb.cam.ac.uk wrote:
> 
> Dear Stefan,
> 
> Just a couple of thoughts:
> 
> - first of all I think that Gerard is absolutely right, it would have been
> nice to raise such issues first with the developers. In my experience,
> Staraniso does a fantastic job if used correctly.
> 
> - but if you're OK with public trials, may I ask: why on Earth would anybody
> need ContaMiner? Are you trying to offer some sort of computational cure for
> sloppy biochemistry? There is zero point in crystallizing crap samples, sorry
> to say this. In my 17 or so years in Strubi I've never heard of anybody
> crystallizing a "contaminant", being it a purification tag or whatever.
> 
> I suppose this might have happened to somebody you know, hence the motivation
> to spend time on the bizarre ContaMiner. Which is a pity, a silly outcome
> would only teach people to do their job (or train their robots) properly.
> 
> Best wishes,
> 
> Radu
> 
> -- 
> Radu Aricescu
> MRC Laboratory of Molecular Biology
> Francis Crick Avenue
> Cambridge Biomedical Campus
> Cambridge CB2 0QH, U.K.
> tel: +44-(0)1223-267049
> fax: +44-(0)1223-268305
> www: http://www2.mrc-lmb.cam.ac.uk/group-leaders/a-to-g/radu-aricescu
> 
>> Dear Stefan,
>> 
>> Regarding your final paragraph: your server carries a warning
>> with the exact wording:
>> 
>> "Submitting StarAniso files can give you suspicious results. Use
>> with care!"
>> 
>> It seems rather regrettable that you are posting such a public
>> warning without ever having contacted the STARANISO developers about
>> your observations, nor giving any information about what you call
>> "suspicious" or what the "care" you recommend would consist of.
>> 
>> We have taken a great deal of care ourselves in developing the
>> program and offering it to the community through a server, and the
>> least we would have expected is that any pattern of "suspicious"
>> results would be referred to us so that we could investigate them.
>> There may be some assumptions made in MoRDa that we are not aware of,
>> that might be incompatible with assumptions made in STARANISO - who
>> knows? Or it could be that some particularly badly collected datasets
>> are made to look worse after their anisotropy analysis.
>> 
>> Could we discuss your observations, and what it is exactly that
>> you call "suspicious", before they end up being referred to in such an
>> uninformative manner as some sort of "Government Health Warning"?
>> 
>> I think that would be nice :-) and we would be only too keen to
>> take whatever extra "care" is needed ourselves. We would all learn
>> something.
>> 
>> 
>> With best wishes,
>> 
>>  Gerard.
>> 
>> (on behalf of the STARANISO developers)
>> 
>> --
>>> On Thu, Nov 23, 2017 at 05:02:39PM +0100, Stefan Arold wrote:
>>> Dear Community,
>>> 
>>> A quick message to announce the following two new features on our
>>> ContaMiner web server for the automated detection of unwantedly
>>> crystallised contaminants (
>>> https://strube.cbrc.kaust.edu.sa/contaminer/submit)
>>> 
>>> 1) online visualisation of 2FoFc and FoFc maps. In cases of positive
>>> results, the ‘UglyMol’ tab allows to inspect 2FoFc and FoFc maps
>>> directly
>>> in the web browser. Thi
>>> 
>>> 2) life-update. Previously, results were sent to you once all ~2000 MR jobs
>>> were finished. Now, the individual results for each potential contaminant
>>> will appear as soon as they are finished. This feature should substantially
>>> shorten the time for identifying positive 

Re: [ccp4bb] new ContaMiner features

[radu]

Dear Stefan,

Just a couple of thoughts:

- first of all I think that Gerard is absolutely right, it would have been
nice to raise such issues first with the developers. In my experience,
Staraniso does a fantastic job if used correctly.

- but if you're OK with public trials, may I ask: why on Earth would anybody
need ContaMiner? Are you trying to offer some sort of computational cure for
sloppy biochemistry? There is zero point in crystallizing crap samples, sorry
to say this. In my 17 or so years in Strubi I've never heard of anybody
crystallizing a "contaminant", being it a purification tag or whatever.

I suppose this might have happened to somebody you know, hence the motivation
to spend time on the bizarre ContaMiner. Which is a pity, a silly outcome
would only teach people to do their job (or train their robots) properly.

Best wishes,

Radu

-- 
Radu Aricescu
MRC Laboratory of Molecular Biology
Francis Crick Avenue
Cambridge Biomedical Campus
Cambridge CB2 0QH, U.K.
tel: +44-(0)1223-267049
fax: +44-(0)1223-268305
www: http://www2.mrc-lmb.cam.ac.uk/group-leaders/a-to-g/radu-aricescu

> Dear Stefan,
>
>  Regarding your final paragraph: your server carries a warning
> with the exact wording:
>
>  "Submitting StarAniso files can give you suspicious results. Use
> with care!"
>
>  It seems rather regrettable that you are posting such a public
> warning without ever having contacted the STARANISO developers about
> your observations, nor giving any information about what you call
> "suspicious" or what the "care" you recommend would consist of.
>
>  We have taken a great deal of care ourselves in developing the
> program and offering it to the community through a server, and the
> least we would have expected is that any pattern of "suspicious"
> results would be referred to us so that we could investigate them.
> There may be some assumptions made in MoRDa that we are not aware of,
> that might be incompatible with assumptions made in STARANISO - who
> knows? Or it could be that some particularly badly collected datasets
> are made to look worse after their anisotropy analysis.
>
>  Could we discuss your observations, and what it is exactly that
> you call "suspicious", before they end up being referred to in such an
> uninformative manner as some sort of "Government Health Warning"?
>
>  I think that would be nice :-) and we would be only too keen to
> take whatever extra "care" is needed ourselves. We would all learn
> something.
>
>
>  With best wishes,
>
>   Gerard.
>
> (on behalf of the STARANISO developers)
>
> --
> On Thu, Nov 23, 2017 at 05:02:39PM +0100, Stefan Arold wrote:
>> Dear Community,
>>
>> A quick message to announce the following two new features on our
>> ContaMiner web server for the automated detection of unwantedly
>> crystallised contaminants (
>> https://strube.cbrc.kaust.edu.sa/contaminer/submit)
>>
>> 1) online visualisation of 2FoFc and FoFc maps. In cases of positive
>> results, the ‘UglyMol’ tab allows to inspect 2FoFc and FoFc maps
>> directly
>> in the web browser. Thi
>>
>> 2) life-update. Previously, results were sent to you once all ~2000 MR jobs
>> were finished. Now, the individual results for each potential contaminant
>> will appear as soon as they are finished. This feature should substantially
>> shorten the time for identifying positive results (i.e. contaminant
>> detected), which are terminated faster than negative ones.
>>
>> 3) custom contaminants. In the ‘Advanced’ tab, users can upload own PDB
>> files (more than one is possible) to be included as search models. This
>> feature can be used to include PDB files from your lab bench neighbour’s
>> project to test for potential lab internal contaminations (through
>> bacterial contamination or through mix-up of plasmids or glycerol stocks).
>> This feature could also be ‘abused’ as a means to use the MoRDa pipeline
>> to
>> run molecular replacements with template structures that are not yet
>> deposited in the PDB; for example to run molecular replacement and initial
>> refinement for liganded or complexed versions of an unpublished structure.
>> This might be particularly interesting for crystallographers away from
>> their usual home software environment (e.g. at the beamline).
>>
>> Finally, a word of warning – Staraniso files might give false positives if
>> they have large anisotropic cuts.
>>
>> Keep your crystals clean!
>>
>> With best wishes
>>
>> The ContaMiner Team
>
> --
>
>  ===
>  * *
>  * Gerard Bricogne g...@globalphasing.com  *
>  * *
>  * Global Phasing Ltd. *
>  * Sheraton House, Castle Park Tel: +44-(0)1223-353033 *
>  * Cambridge CB3 0AX, UK   Fax: 

Re: [ccp4bb] new ContaMiner features

[Gerard Bricogne]

Dear Stefan,

 Regarding your final paragraph: your server carries a warning
with the exact wording:

 "Submitting StarAniso files can give you suspicious results. Use
with care!"

 It seems rather regrettable that you are posting such a public
warning without ever having contacted the STARANISO developers about
your observations, nor giving any information about what you call
"suspicious" or what the "care" you recommend would consist of. 

 We have taken a great deal of care ourselves in developing the
program and offering it to the community through a server, and the
least we would have expected is that any pattern of "suspicious"
results would be referred to us so that we could investigate them.
There may be some assumptions made in MoRDa that we are not aware of,
that might be incompatible with assumptions made in STARANISO - who
knows? Or it could be that some particularly badly collected datasets
are made to look worse after their anisotropy analysis. 

 Could we discuss your observations, and what it is exactly that
you call "suspicious", before they end up being referred to in such an
uninformative manner as some sort of "Government Health Warning"?

 I think that would be nice :-) and we would be only too keen to
take whatever extra "care" is needed ourselves. We would all learn
something.
 
 
 With best wishes,
 
  Gerard.

(on behalf of the STARANISO developers)

--
On Thu, Nov 23, 2017 at 05:02:39PM +0100, Stefan Arold wrote:
> Dear Community,
> 
> A quick message to announce the following two new features on our
> ContaMiner web server for the automated detection of unwantedly
> crystallised contaminants (
> https://strube.cbrc.kaust.edu.sa/contaminer/submit)
> 
> 1) online visualisation of 2FoFc and FoFc maps. In cases of positive
> results, the ‘UglyMol’ tab allows to inspect 2FoFc and FoFc maps directly
> in the web browser. Thi
> 
> 2) life-update. Previously, results were sent to you once all ~2000 MR jobs
> were finished. Now, the individual results for each potential contaminant
> will appear as soon as they are finished. This feature should substantially
> shorten the time for identifying positive results (i.e. contaminant
> detected), which are terminated faster than negative ones.
> 
> 3) custom contaminants. In the ‘Advanced’ tab, users can upload own PDB
> files (more than one is possible) to be included as search models. This
> feature can be used to include PDB files from your lab bench neighbour’s
> project to test for potential lab internal contaminations (through
> bacterial contamination or through mix-up of plasmids or glycerol stocks).
> This feature could also be ‘abused’ as a means to use the MoRDa pipeline to
> run molecular replacements with template structures that are not yet
> deposited in the PDB; for example to run molecular replacement and initial
> refinement for liganded or complexed versions of an unpublished structure.
> This might be particularly interesting for crystallographers away from
> their usual home software environment (e.g. at the beamline).
> 
> Finally, a word of warning – Staraniso files might give false positives if
> they have large anisotropic cuts.
> 
> Keep your crystals clean!
> 
> With best wishes
> 
> The ContaMiner Team

-- 

 ===
 * *
 * Gerard Bricogne g...@globalphasing.com  *
 * *
 * Global Phasing Ltd. *
 * Sheraton House, Castle Park Tel: +44-(0)1223-353033 *
 * Cambridge CB3 0AX, UK   Fax: +44-(0)1223-366889 *
 * *
 ===