Sunday, 30 October 2011

small 3ml Superdex column performance

From: Alexandra Deaconescu
Date: 15 October 2011 23:04


Hi everyone:

I was hoping I could get your opinion on the performance of the small approx. 3ml gel filtration columns from GE Healthcare. We currently have an Akta fplc and we would like to do small runs using small volumes of sample. As far as I know we have two options:

1. use the Superdex 15/150 columns
these appear to have a slightly lower resolution (the no. of theoretical plates is about 25000 m-1)
these apparently can be directly hooked up to our Akta fplc

2. use Superdex PC 3.2
these have somewhat higher resolution (the no of theoretical plates is 30000 m-1)
these can only be hooked up using a special "Precision Holder" equipped with titanium end fittings (which I have heard clog easily?)

What is your experience with these columns?
Which option of the two do you recommend (cost is not a huge issue, but resolution and overall performance is)?
Have you seen significant band broadening when using these small columns with a regular fplc (rather than Akta's microFPLC)?

I would greatly appreciate your comments! Many thanks...

Bests,
Alex

.

----------
From: Artem Evdokimov


Hi,
 
You're probably referring to the Superdex 5/150 Tricorn column, with working volume of 3ml, and not the 15/150?
 
Those columns work quite nicely for small sample volumes. For analytical runs 15-25ul injection is pretty nice. The PC columns are originally designed to be used with the SMART system, which by the way used to be one of the best analytical products for macromolecules -- optimized path length, one-volume pumps suitable for directly running typical protocols, etc. etc. and for its time the OS was also damn good (OS/2). Sadly, GE did not come up with any direct replacement for this machine, as far as I can tell. AKTA is not optimal for analytical runs - tubing is too long, etc.
 
If you have an old HPLC system moldering in a corner I recommend either of these columns mounted directly in front of the detector. In our current setup the entire portion of the HPLC that is responsible for column selection and heating and so on is bypassed, so there are literally ~4-5 mm of (the thinnest available PPEK) tubing in between the injection valve and the column, and in between the column and the detector. Autosampler is a very helpful feature, esp. when analyzing fractions output from previous step, and as long as the column isn't clogged the run is 8-12 minutes (depending on buffer composition). Now, Agilent software for HPLC is absolutely horrible for this kind of work but it suffices.
 
Artem

P.S. for lower protein quantities don't forget to record the A210, in addition to A280 and A260.

----------
From: Tommi Kajander


Hi,

if you really want it SMART was replaced be Äkta Ettan and nowaays Äkta micro. The nice thing is the easy of use (same software).

However i other think HPLCs might be more flexible and cheaper (e.g. we have schimadzu - cant complain about anything,
interface is more complex, but you dont really need to care about all that... you use just a few options - and there are several other
manufacturers..) --- just as a comment on the analytical systems.  you can inject few microliters...

And the ca. 20 ml S-200/S-75 10/300 works fine for small volumes by the way. at least on our HPLC. why would you need to go smaller??
20-50 ug. in 20 ul should be fine.... did you try? you could try just chaning the tubing on your current Äktä purifier and injecting
via Hamilto syringe?? Connected to HPLC certainly will work.
Of couse if you want faster runs, thats another thing (i think these smaller columns are mainly good for fast screening of quality)

HTH,
tommi
Tommi Kajander, Ph.D.
Structural Biology and Biophysics
Institute of Biotechnology
University of Helsinki
Viikinkaari 1
(P.O. Box 65)
00014 Helsinki
Finland


----------
From: Artem Evdokimov

Hi Tommi :)

I like AKTA systems a lot, and it's uncharacteristic of me to say this but the Micro is kind of a copout  - it's a repurposing of the general AKTA system towards smaller volumes and not a completely specific design like the SMART was. Now, I think I understand why they're doing this -- cost is lower when you recycle components.
 
Principal advantage of small columns on an HPLC-like device is the speed of run. At 10 minutes per cycle (and that's not counting any time one loses on changing buffers!) the speed is adequate to make a reasonable judgment regarding e.g. pooling fractions from a run, in order to decide what to do next, or figuring out if the purification is sufficient to stop and set up crystals, etc. (one hour for 4-6 fractions is not bad). Most other analytical methods are quicker (LC-MS at 4-7 minutes/sample is the next slowest option, everything else is faster) but sizing offers unique insight that's hard to match - SLS/DLS does not give the entire picture (unfortunately).
Of course this only applies to people who, like me, believe that purification should be done as quickly as possible and in as few steps as needed (ideally 1-3 steps in one day) and who also have to screen large-ish numbers of samples. In other situations a larger sample size on a larger column is better since one can collect the good fractions and do something useful with them :)
Artem


Akta Prime

From: Michael Colaner
Date: 12 October 2011 19:28


Dear all,

We have an AktaPrime and GE Lifesciences stop servicing these instruments because they are getting old.  Does anyone know of a third party company that gives contracts to maintain these instruments?  Thank you.

Mike Colaneri

----------
From: Chun Luo


It's not difficult to replace parts of AKTAprime. But the pump may not be available anymore. It should be cheaper to get a new AKTAprime plus than getting a service contract for AKTAprime. AKTAprime plus costs just a little bit over $10,000 for a new one and lasts at least 5 years without a service call. GE probably will support AKTAprime plus for a few more years. --Chun



----------
From: Jan Gebauer

Dear Mike,

strange - I just filed a repair job with labcrew for our old ÄKTA Prime. A technician was in house (for other reasons) when it stopped working and he was confident that he can replace our pump (rotary unit, as he called it)... Well let's hope he really does...
On the other hand, I had also very bad experience with GE technicians in London, but not yet here in Cologne, Germany. Potentially, it depends on your local service?

Regarding Paul Smith's message, I totally agree. A real competitor is needed.
I haven't seen anything, which is nearly as good and versatile as the ÄKTA line (which doesn't mean they couldn't bee imporved!).
Especially, if you are in Science and not in a kind of production facility. The small Bio-Rad Econo system (about the same price tag as the ÄKTAPrime AFAIK), which we use here in the student course, is not nearly as sophisticated as a Prime...

Best,
Jan


--
Dr. Jan Gebauer
AG Prof. Baumann
Institut für Biochemie / Uni-Köln

----------
From: Charles Allerston


Dear Michael,

 

 

alternative people to service FPLC systems in the UK are called LC Services http://www.lcservs.com/ and came highly recommended to us.

 

 

cheers

 

charlie

 

 

----------
From: Mark Brooks <mark.x.brooks@gmail.com>
Date: 15 October 2011 15:44
To: CCP4BB@jiscmail.ac.uk


Dear Mike,
               At Evotec (a UK site), we gave up using GE to service
our GE instruments (!) due to problems with their bureaucracy. Agilent
offer service contracts for Aktas that are competitively priced and
are a work-alike in our experience.

For call-outs, they sub-contract the usual GE engineers that you would
normally see to perform maintenance, and do this with their usual high
level of professionalism.

I think it's a bit of a shame (for GE) that we have to use a third
party like this to organise the preventative maintenance visits etc.,
but it works very well for us.

Yours,

Mark


"Insufficient virtual memory"

From: Ian Tickle
Date: 14 October 2011 10:31


Hello all, some Fortran developer out there must know the answer to
this one.  I'm getting a "forrtl: severe (41): insufficient virtual
memory" error when allocating dynamic memory from a F95 program
compiled with Intel Fortran v11.1.059.  The program was compiled on an
old ia-32 Linux box with 1Gb RAM + 2Gb swap (I only have one Intel
license to compile on this machine), but I'm running it on a brand new
x86-64 box with 12Gb RAM + 8Gb swap.  This should be ample: the
program's maximum total memory requirement (code + static data +
dynamic data) should be no more than 3Gb.

My question is: what do I have to do to make it work?  According to
the ifort man page I need to specify "-mcmodel=medium -shared-intel".

It says: "If your program has COMMON blocks and local data with a
total size smaller than 2GB -mcmodel=small is sufficient.  COMMONs
larger than 2GB require mcmodel=medium or -mcmodel=large.  Allocation
of memory larger than 2GB can be done with any setting of -mcmodel."

I'm a bit confused about the difference here between COMMONS > 2Gb
(which I don't have) and "allocation of memory" > 2Gb (which I assume
I do).

When I try setting -mcmodel=medium (and -shared-intel) I get "ifort:
command line warning #10148: option '-mcmodel' not supported".  Is
this telling me that I have to compile on the 64-bit machine?
Whatever happened to cross-compilation?

All suggestions greatly appreciated!

-- Ian

----------
From: Francois Berenger


Try the GNU (compiler) and see what it says. ;)

----------
From: Ian Tickle


Hi Francois - I won't bore you with the long list of compiler errors
that gfortran gives with my code (ifort compiles the identical code
without error and up until now it has worked just fine on both 32 & 64
bit machines as long as don't try to allocate > 2Gb).

I think we'll have to splash out on an Intel license for a 64-bit
machine (thanks for the low-down on the bugs, Harry).

Anyway thanks to all for the suggestions.

Cheers

-- Ian

----------
From: Kay Diederichs


Hi Ian,

compiling on your 32bit machine gave you a 32bit binary, so your 12GB RAM cannot be used!

HTH,
Kay





Ice rings...

From: Francis E Reyes
Date: 11 October 2011 16:16


All,


So I have two intense ice rings where there appear to be lattice spots in between them.

I understand that any reflections that lie directly on the ice ring are useless, however, how do software programs (HKL2000, d*Trek, mosflm, XDS) deal with these intermediate spots?

It would seem to me that employing a 'resolution cut off' just before the ice ring (on the low resolution side) would be improper, as there are spots on the high resolution side of the ice. (see enclosed .tiff)


In fact, how do these programs deal with spots lying on ice rings? Are they rejected by some algorithm by those programs during integration, or is it up to the scaling/merging (by SCALA for example) step to deal with them?

Thanks!

F



---------------------------------------------
Francis E. Reyes M.Sc.
215 UCB
University of Colorado at Boulder







----------
From: Bruno KLAHOLZ


Dear Francis,

the spots will be excluded individually based on the inhomogeneous background, so you don't need to apply a resolution cutoff.
However, once you have determined and refined your structure it may be worth predicting the intensity of these spots and put them back for map calculation,
this might avoid gaps in your map corresponding to inter-atom distances for which data are missing in the resolution range of the ice rings; as long as this is done only for a relatively small set of reflections there is not much risk of introducing a bias here.

HTH,

Bruno




-
Dr. Bruno P. Klaholz
Department of Integrated Structural Biology
Institute of Genetics and of Molecular and Cellular Biology
IGBMC - UMR 7104 - U 964
1, rue Laurent Fries
BP 10142
67404 ILLKIRCH CEDEX
FRANCE



----------
From: Edward A. Berry


If the ice rings are really sharp, they trigger the bad
background rejection in denzo/HKL2000. To reject more spots,
increase the "reject fraction 0.7" parameter to something
greater than .7. This rejection is on a spot by spot basis,
so spots with good background between the rings should not
be affected. During integration, if you are monitoring
the process with Xdisp, you will see the rejected spots
turn red and/or disappear. To verify they are being
rejected by background fraction, try again with
"reject fraction .3" and see if they stay green/yellow.

If the ice ring is broad compared to the integrating box,
it shows up as a high, slanting baseline and the normal
baseline correction procedure is valid, but sigma will
be higher than for a spot on a white background.

Francis E Reyes wrote:
---------------------------------------------
Francis E. Reyes M.Sc.
215 UCB
University of Colorado at Boulder



----------
From: Dr. Thayumanasamy Somasundaram


Francis,

I would like to bring your attention to our paper in Acta Cryst D Volume 66 (6), 741-744 (2010) where we deal with spots under the ice-rings. We have been very successful in eliminating the ice-rings and recover the data underneath. If you are interested you can request the Python script from Michael Chapman at OHSU.

De-icing: recovery of diffraction intensities in the presence of ice rings, Michael S. Chapman and Thayumanasamy Somasundaram


If you need help please e-mail me outside the CCP4BB.
--------------------------------------------- Francis E. Reyes M.Sc. 215 UCB University of Colorado at Boulder   
Dr. Thayumanasamy Somasundaram [Soma] Director, X-Ray Crystallography Facility (XRF)			 

----------
From: James Stroud


I've used a technique called "annealing", which amounts to holding an index card between the cryo stream and the crystal for a few seconds then removing the card quickly.

In my experience, about 70% of the time the diffraction is worse and about 30% of the time the ice rings will be gone with slightly improved diffraction, allowing recovery of a significant range of data. Most of the time, though, I find another crystal that had a better initial freeze, so annealing has never been a life saver--but it could be under dire circumstances.

James

----------
From: James Holton

Automated outlier rejection in scaling will handle a lot of things, including ice.  Works better with high multiplicity.  Unless, of course, your ice rings are "even", then any integration error due to ice will be the same for all the symmetry mates and the scaling program will be none the wiser.  That said, the integration programs these days tend to have pretty sensible defaults for rejecting spots that have "weird" backgrounds.  Plenty of structures get solved from data that has horrible-looking ice rings using just the defaults.  In fact, I am personally unconvinced that ice rings are a significant problem in and of themselves.  More often, they are simply an indication that something else is wrong, like the crystal warmed up at some point.

  Nevertheless, if you suspect your ice rings are causing a problem, you can try to do something about them.  The "deice" program already mentioned sounds cool, but if you just want to try something quick, excluding the resolution ranges of your ice rings can be done in sftools like this:
select resol > 3.89
select resol < 3.93
absent col F SIGF DANO SIGDANO if col F > 0
and repeat this for each resolution range you want to exclude.  Best to get these ranges from your integration program's graphics display.

In mosflm, you can put "EXCLUDE ICE" on either the "AUTOINDEX" or "RESOLUTION" keywords and have any spots on the canonical hexagonal ice spacings removed automatically.  The problem with excluding resolution ranges, of course, is that your particular "ice rings" may not be where they are supposed to be.  Either due to something physical, like the cooling rate, or something artificial, like an error in the camera parameters.  It is also possible that what you think are "ice rings" are actually "salt rings".  Some salts will precipitate out upon cryo-cooling.  Large ice/salt crystals can also produce a lot of non-Bragg scatter, which means that you can get sharp features far away from the resolution range you expect.  On the other hand, if you have cubic ice instead of hexagonal ice (very common in MX samples), then there are no rings at 3.91A, 3.45A, 2.68A and throwing out these resolution ranges would be a waste. 

Another way to exclude ice is to crank up background-based rejection criteria.  In denzo/HKL2K, you do this with the "reject fraction" keyword, and in mosflm, REJECT MINBG does pretty much the same thing.  There are lots of rejection options in integration programs, and which one works in your particular case depends on what your ice rings look like.  Noone has written a machine-vision type program that can recognize and handle all the cases. You will need to play with these options until the spots you "don't like" turn red in the display.

Of course, the best way to deal with ice rings would be to inspect each and every one of the spots you have near ice rings and decide on its intensity manually.  Then edit the hkl file.


Which brings me to perhaps a more important point: What, exactly, is the "problem" you are having that makes you think the ice rings are to blame?  Can't get an MR solution?  Can't get MAD/SAD phases? 

Ice has a bad rep in MX, and an undeserved one IMHO.  In fact, by controlling either cryoprotectant concentration or cooling rate carefully, you can achieve a mixture of amorphous and cubic ice, and this mixture has a specific volume (density) intermediate between the two.  Many crystals diffract much better when you are able to match the specific volume of the stuff in the solvent channels to the specific volume protein lattice is "trying" to achieve on its own.  A great deal of effort has gone into characterizing this phenomenon (authors: Juers, Weik, Warkentin, Thorne and many others), but I often meet frustrated cryo-screeners who seem to have never heard of any of it!

 In general, the automated "outlier rejection" protocols employed by modern software have taken care of most of the problems ice rings introduce.  For example, difference Pattersons are VERY sensitive to outliers, and all it takes is one bad spot to give you huge ripples that swamp all you peaks, but every heavy-atom finding program I am aware of calculates Pattersons only after fist doing an "outlier rejection" step.  You might also think that ice rings would mess up your preciously subtle anomalous differences, but again, outlier rejection to the rescue. 

Now, that said, depending on automated outlier rejection to save you is of course a questionable policy, but it is an equally bad idea to pretend that it doesn't exist either.  It is funny how in MX we are all ready to grab our torch and pitchfork if we hear of someone manually editing their hkl files to get rid of reflections they "don't like", but as long as "the software" does it, it is okay.  Plausible deniability runs deep.


-James Holton
MAD Scientist
--------------------------------------------- Francis E. Reyes M.Sc. 215 UCB University of Colorado at Boulder      



Saturday, 29 October 2011

Ice rings... [maps and missing reflections]

From: Ed Pozharski
Date: 11 October 2011 18:34


On Tue, 2011-10-11 at 15:24 +0000, Bruno KLAHOLZ wrote:
> However, once you have determined and refined your structure it may be
> worth predicting the intensity of these spots and put them back for
> map calculation,

REFMAC does this by default, because

"expected value of unknown structure factors for missing reflections are
better approximated using DFc than with 0 values."

CNS defaults to excluding them.  As for phenix, I am not entirely sure -
it seems that phenix.refine does too (fill_missing_f_obs= False), but if
you use the GUI then the fill in option is turned on.



--
Oh, suddenly throwing a giraffe into a volcano to make water is crazy?
                                               Julian, King of Lemurs

----------
From: Nat Echols


In practice, it will be turned on for command-line phenix.refine too if you don't supply your own custom map definitions - actually it produces both "filled" and "unfilled" maps, but the former is what most users will see in Coot.

-Nat

----------
From: Pavel Afonine



better, but not always. What about say 80% or so complete dataset? Filling in 20% of Fcalc (or DFcalc or bin-averaged <Fobs> or else - it doesn't matter, since the phase will dominate anyway) will highly bias the map towards the model. Clearly there are cases where filling in a few missing reflections significantly improves map interpretability without introducing any bias. 
phenix.refine always outputs two 2mFo-DFc maps: one is computed using the original set of Fobs, and the other one is computed using set of Fobs where missing reflections filled in with DFc calculated using well determined atoms only. By default, Coot will open the "filled" one.

Pavel


----------
From: Ed Pozharski


DFc, if properly calculated, is the maximum likelihood estimate of the
observed amplitude.  I'd say that 0 is by far the worst possible
estimate, as Fobs are really never exactly zero.  Not sure what the
situation would be when it's better to use Fo=0, perhaps if the model is
grossly incorrect?  But in that case the completeness may be the least
of my worries.

Indeed, phases drive most of the model bias, not amplitudes.  If model
is good and phases are good then the DFc will be a much better estimate
than zero.  If model is bad and phases are bad then filling in missing
reflections will not increase bias too much.  But replacing them with
zeros will introduce extra noise.  In particular, the ice rings may mess
things up and cause ripples.

On a practical side, one can always compare the maps with and without
missing reflections.

--
After much deep and profound brain things inside my head,
I have decided to thank you for bringing peace to our home.
                                   Julian, King of Lemurs

----------
From: Pavel Afonine


Hi Ed,

Yes, that's all true about what is DFc. In terms of missing-Fobs-filling it's not too important (as map appearance concerned) which values you take, DFc, <Fobs> , etc. I spent a few days playing with this some years ago.
Yep, that was the point - sometimes it is good to do, and sometimes it is not, and ...
... this is why phenix.refine outputs both maps -:)

All the best,
Pavel


----------
From: Ed Pozharski

Do you have a real life example of Fobs=0 being better?  You make it
sound as if it's 50/50 situation.

--
"Hurry up before we all come back to our senses!"
                          Julian, King of Lemurs

----------
From: Pavel Afonine




Hopefully, there will be a paper some time soon discussing all this - we work on this right now.
No (sorry if what I wrote sounded that misleading).  

Pavel


----------
From: Randy Read


If the model is really bad and sigmaA is estimated properly, then sigmaA will be close to zero so that D (sigmaA times a scale factor) will be close to zero.  So in the limit of a completely useless model, the two methods of map calculation converge.

Regards,

Randy Read
------
Randy J. Read
Department of Haematology, University of Cambridge
Cambridge Institute for Medical Research     
Wellcome Trust/MRC Building                  
Hills Road                                   
Cambridge CB2 0XY, U.K.                       www-structmed.cimr.cam.ac.uk

----------
From: Garib N Murshudov

In the limit yes. however limit is when we do not have solution, i.e. when model errors are very large.  In the limit map coefficients will be 0 even for 2mFo-DFc maps. In refinement we have some model. At the moment we have choice between 0 and DFc. 0 is not the best estimate as Ed rightly points out. We replace (I am sorry for self promotion, nevertheless: Murshudov et al, 1997) "absent" reflection with DFc, but it introduces bias. Bias becomes stronger as the number of "absent" reflections become larger. We need better way of estimating "unobserved" reflections. In statistics there are few appraoches. None of them is full proof, all of them are computationally expensive. One of the techniques is called multiple imputation. It may give better refinement behaviour and less biased map. Another one is integration over all errors (too many parameters for numerical integration, and there is no closed form formula) of model as well as experimental data. This would give less biased map with more pronounced signal.

Regards
Garib

Garib N Murshudov 
Structural Studies Division
MRC Laboratory of Molecular Biology
Hills Road 
Cambridge 
CB2 0QH UK





----------
From: Ethan Merritt

I don't quite follow how one would generate multiple imputations in this case.

Would this be equivalent to generating a map from (Nobs - N) refls, then
filling in F_estimate for those N refls by back-transforming the map?
Sort of like phase extension, except generating new Fs rather than new phases?

       Ethan
--
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

----------
From: Dale Tronrud


  Unless you do some density modification you'll just get back zeros for
the reflections you didn't enter.

Dale

----------
From: Garib N Murshudov

Best way would be to generate from probability distributions derived after refinement, but it has a problem that you need to integrate over all errors. Another, simpler way would be generate using Wilson distribution multiple times and do refinement multiple times and average results. I have not done any tests but on paper it looks like a sensible procedure.

regards
Garib

----------
From: Ethan Merritt

Dale Tronrud wrote>
Sure.  And different DM procedures would give you different imputations,
or at least that was my vague idea.

Garib N Murshudov wrote>
OK.  That makes sense.

               Ethan

----------
From: Eleanor Dodson


Here we are I presume only worried about strong reflections lost behind an ice ring. At least that is where the discussion began.

Isnt the best approach t  this problem to use integration software which attempts to give a measurement, albeit with a high error estimate?

The discussion has strayed into what to do with incomplete data sets..
In these cases there might be something to learn from the Free Lunch ideas used in ACORN and SHELX and other programs - set the missing reflections to E=1, and normalise them properly to an appropriate amplitude.

Eleanor

----------
From: Tim Gruene


Some people call this the "free-lunch-algorithm" ;-)
Tim

>       Ethan
> [...]
- --
- --
Dr Tim Gruene
Institut fuer anorganische Chemie
Tammannstr. 4
D-37077 Goettingen




----------
From: Edward A. Berry


Doesn't work- the Fourier transform is invertable. As someone already said in this
thread, if the map was made with coefficients of zero for certain reflections
(which is equivalent to omitting those reflections) The back-transform will
give zero for those reflections. Unless you do some density modification first.
So free-lunch is a good name- there aint no such thing!

----------
From: Ethan Merritt

Tim refers to the procedure described in
 Sheldrick, G. M. (2002). Z. Kristallogr. 217, 644–65

which was later incorporated into shelxe as the Free Lunch Algorithm.
It does indeed involve a form of density modification.
Tim is also correct that this procedure is the precedent I had in mind,
although I had forgotten its clever name.

       cheers,

----------
From: George M. Sheldrick


Dear Ethan,

Thankyou for the reference, but actually it's the wrong paper and anyway
my only contribution to the 'free lunch algorithm' was to name it (in the
title of the paper by Uson et al., Acta Cryst. (2007) D63, 1069-1074). By
that time the method was already being used in ACORN and by the Bari group,
who were the first to describe it in print (Caliandro et al., Acta Cryst.
Acta Cryst. (2005) D61, 556-565). As you correctly say, it only makes sense
in the context of density modification, but under favorable conditions,
i.e. native data to 2A or better, inventing data to a resolution that you
would have liked to collect but didn't can make a dramatic improvement to
a map, as SHELXE has often demonstrated. Hence the name. And of course
there is no such thing as a free lunch!

Best regards, George
--
Prof. George M. Sheldrick FRS
Dept. Structural Chemistry,
University of Goettingen,
Tammannstr. 4,
D37077 Goettingen, Germany


----------
From: Tim Gruene


I am glad the structures that have been solved using the
free-lunch-algorithm as implemented in shelxe did not know they were not
allowed to be solved. Of course there is DM involved, as has been
pointed out ;-)
i-

----------
From: James Holton


Indeed we do!  Because this appears to be the sum total of how the correctness of the structure is judged.  It is easy to forget I think that from the "point of view" of the refinement program, all reflections flagged as belonging to the "free" set are, in effect, "missing".   So Rfree is really just a score for how well DFc agrees with Fobs?

-James Holton
MAD Scientist


Quips about "stunning" software and the first structure it helped solve

From: Gerard DVD Kleywegt
Date: 14 October 2011 18:43


Hi all,

The Protein Data Bank in Europe (PDBe; pdbe.org) regularly produces Quips, short stories about QUite Interesting Pdb Structures (pdbe.org/quips). Quips address biologically interesting aspects of one or more PDB entries, coupled with interactive graphics views and often a mini-tutorial or suggestions for further exploration using PDBe services and resources.

Today another Quips episode was released. It looks back at the first crystal structure that was solved with the program Phaser and also tries to explain in (almost) layman's terms how Molecular Replacement works. The accompanying mini-tutorial shows you how to do multiple structure superimposition using PDBeFold (SSM).

The Quips story can be found here: http://pdbe.org/quips?story=Phaser

There is also an RSS feed that informs you whenever there is a new Quips article available. For links to this and several other feeds, see http://pdbe.org/rss

---

If you have an interesting structure whose story you would like to tell (with our help) in the form of a Quips episode, please contact us at pdbe@ebi.ac.uk

--Gerard

---
Gerard J. Kleywegt, 

First contours of a vision for the future of validation at the PDB


From: Gerard DVD Kleywegt
Date: 14 October 2011 18:22


(Posted on behalf of wwPDB)

The Worldwide Protein Data Bank (wwPDB; wwpdb.org) is pleased to direct PDB depositors and users to the recommendations of the wwPDB X-ray Validation Task Force (VTF) that were published in the journal Structure this week (2011, vol. 19: 1395-1412; http://www.cell.com/structure/abstract/S0969-2126(11)00285-1).

The wwPDB X-ray VTF was convened in 2008 to collect expert recommendations and develop consensus on validation methods that should be applied to crystal structures (models and data) in the PDB and to identify software applications to perform these validation tasks. These recommendations are the basis of a new validation suite that will be part of the new Common Tool for Deposition and Annotation (D&A) that is currently being developed by the wwPDB partners. The D&A tool and the X-ray validation pipeline will go into production by the end of 2012 at all wwPDB deposition sites (RCSB PDB, PDBe, PDBj and BMRB). From that moment in time on, depositors of X-ray crystal structures at the PDB will be provided with a detailed validation report. Such reports can be submitted to journals to accompany manuscripts describing new structures, and several publishers are working towards making such reports mandatory. Once the D&A tool is in production, the wwPDB partners also plan to provide the validation pipeline as a server, allowing crystallographers to assess their models before deposition and publication. Additional VTFs have been convened for NMR (by wwPDB) and 3DEM (by EMDataBank).

The wwPDB greatly appreciates the efforts of the authors of the X-ray VTF report: Randy J. Read, Paul D. Adams, W. Bryan Arendall III, Axel T. Brunger, Paul Emsley, Robbie P. Joosten, Gerard J. Kleywegt, Eugene B. Krissinel, Thomas Ltteke, Zbyszek Otwinowski, Anastassis Perrakis, Jane S. Richardson, William H. Sheffler, Janet L. Smith, Ian J. Tickle, Gert Vriend and Peter H. Zwart.

------------------------------------------------------------------------------

--Gerard

Optimisation of weights


From: ‪<kavya
Date: 14 October 2011 06:12

Dear users,

Can the optimization of the X-ray weighing factor
and B-factor (overall wt) as mentioned in the paper
Acta Cryst. (2007). D63, 1274–1281 by Dr.Ian Tickel,
be used for the refinement of the data sets beyond
the resolution range mentioned in the paper: 1.33 -
2.55 Ang?

Also the structures that were used to optimize these
parameters were already solved and refined, so when
we are solving a new structure to what extent does the
model has to be built before starting the optimization?

Thanking you
With Regards
M. Kavyashree



----------
From: Ian Tickle

Hi Kavya

The resolutions of the structures mentioned in the paper were only
examples, the Rfree/-LLfree minimisation method (which are actually
due to Axel Brunger & Gerard Bricogne respectively) does not depend on
resolution.

If the structures are already solved & refined, you don't need to do
any model building, it should be within the radius of convergence with
the new weights - it's only a small adjustment after all.

Cheers

-- Ian


----------
From: ‪<kavya‬
Date: 14 October 2011 11:19



Respected Sir,

For one of the structures that I did optimisation
had values - (resolution of the data - 2.35Ang)

Before optimization- (Bfactor weight=1.0, X-ray Weight - auto)
R factor  0.2362
R free    0.2924
-LLfree   7521.8
rmsBOND   0.0160
zBOND     0.660

After optimisation- (B-factor weight=0.2, X-ray Weight - 0.08)
R factor  0.2327
R free    0.2882
-LLfree   7495.7
rmsBOND   0.0111
zBOND     0.460

Also can you tell me what is the limit for B-factor weight hat can be varied.
Sorry I just re-read your last email and realised and didn't read it
properly the first time.  But what I said still stands: you can of
course try to optimise the weights at an early stage (before adding
waters say), there's no harm doing that, but there's also not much
point since you'll have to do it all again with the complete model,
since adding a lot of waters will undoubtedly change the optimal
weights.  So I just leave the weight optimisation until the model is
complete.  As long as the initial weights are "in the same ball park",
so that your RMSZ(bonds) is around 0.5 for typical resolutions (a bit
lower for low resolution, a bit higher for very high resolution) it
won't affect interpretation of maps etc.

Cheers

-- Ian

On Fri, Oct 14, 2011 at 9:37 AM, Ian Tickle  wrote:
> It must be the same complete model that you refined previously, I
> doubt that it will give the correct answer if you leave out the waters
> for example.
> 
> You say "there was quite a difference".  Could you be more specific:
> what were the values of the weights, R factors and RMSZ(bonds/angles)
> before and after weight optimisation?
> 
> Cheers
> 
> -- Ian


----------
From: Ian Tickle


Hi your X-ray weight of .08 seems very small, the optimal value is
normally in the range 1 to 4 (I usually set it initially at the
median, i.e. 2.5).  But which weight keyword did you use "WEIGHT
MATRIX .08" or "WEIGHT AUTO .08" (the latter is I think undocumented,
so I'm guessing the first)?  Anyway I would strongly advise the
latter: the difference is that the MATRIX weight is on a completely
arbitrary scale, whereas the AUTO weight is at least relative to the
theoretical value of 1 (even though the optimal value may not be 1 in
practice, at least your initial guess will be in the same ball park).
Note that what Refmac calls "automatic weighting" is not the same as
what X-PLOR, CNS & phenix call "automatic weighting" (at least that's
my understanding).  "WEIGHT AUTO" in Refmac is the same as "WEIGHT
AUTO 10", whereas auto-weighting in X-PLOR corresponds to "WEIGHT AUTO
1" in Refmac.  Not surprisingly these give quite different results!

The optimal B factor weight is also around 1, see the paper for typical values.

I'm still not clear precisely what you meant by ""there was quite a
difference".  I don't see that big a difference between the 2 runs,
just a slight tightening up of the geometry.  Are you saying you see
big differences in the refined co-ordinates?  That would be a cause
for concern.

Cheers

-- Ian




From: ‪<kavya‬
Date: 14 October 2011 12:01


Respected Sir,

Yes, the weight mentioned in the paper was
weight matrix, but the one i used was the
option under "Refinement parameters- weighing
term (when auto weighing is turned off)".
But If I really wasnt to change the weight matrix
where should I change (in the code?)?

No, I dint mean a big difference, not in the
coordinates, but the values of R-factors and
other terms. I thought it was quite different.
So you mean that it is not of much concern?


Thanking you
With Regards
M. Kavyashree


----------
From: Ian Tickle
Date: 14 October 2011 12:03



No, the weights referred to in the paper are definitely the ones given
as "WEIGHT AUTO x".  I can say that with confidence because I never
use "WEIGHT MATRIX x" for reasons I explained.  I think what I said is
that it's _related_ to the matrix weight, which it obviously is by
some constant but unknown factor.

You don't have to change any code (that has been done for you!), but
if you're using CCP4I (sorry I don't so I can't give you precise
instructions), you probably have to edit the script before submission
(there should be a button in the "Run" menu for that).

Cheers

-- Ian
I would say that it's not a big difference, just tightening up of the
geometry, as I said.

Cheers

-- Ian








From: ‪<kavya
Date: 14 October 2011 08:42


Respected Sir,

Thank you for your clarification. I had adopted this
method recently. My doubt was if we have to optimize
these two parameters during refinement, should we have
the whole model along with water and ligands or only
protein with few water positioning is enough. The reason
why I am asking because there was quite a difference
when I refined the same structure without the optimization
and with optimization of these two parameters.

Thanking you
With regards
M. Kavyashree



  
   From: Ian Tickle
   Sent by: CCP4 bulletin board
   Date: 10/14/2011 12:34PM
   Subject: Re: [ccp4bb] Optimisation of weights

   Hi Kavya

   The resolutions of the structures mentioned in the paper were only
   examples, the Rfree/-LLfree minimisation method (which are actually
   due to Axel Brunger & Gerard Bricogne respectively) does not depend on
   resolution.

   If the structures are already solved & refined, you don't need to do
   any model building, it should be within the radius of convergence with
   the new weights - it's only a small adjustment after all.

   Cheers

   -- Ian

   On Fri, Oct 14, 2011 at 6:12 AM,  <kavya@ssl.serc.iisc.ernet.in> wrote:
   > Dear users,
   >
   > Can the optimization of the X-ray weighing factor
   > and B-factor (overall wt) as mentioned in the paper
   > Acta Cryst. (2007). D63, 1274–1281 by Dr.Ian Tickel,
   > be used for the refinement of the data sets beyond
   > the resolution range mentioned in the paper: 1.33 -
   > 2.55 Ang?
   >
   > Also the structures that were used to optimize these
   > parameters were already solved and refined, so when
   > we are solving a new structure to what extent does the
   > model has to be built before starting the optimization?
   >
   > Thanking you
   > With Regards
   > M. Kavyashree
   >
   >
   > --
   > This message has been scanned for viruses and
   > dangerous content by MailScanner, and is
   > believed to be clean.
   >



----------
From: Ian Ticklek


It must be the same complete model that you refined previously, I
doubt that it will give the correct answer if you leave out the waters
for example.

You say "there was quite a difference".  Could you be more specific:
what were the values of the weights, R factors and RMSZ(bonds/angles)
before and after weight optimisation?

Cheers

-- Ian


----------
From: Ian Tickle


Sorry I just re-read your last email and realised and didn't read it
properly the first time.  But what I said still stands: you can of
course try to optimise the weights at an early stage (before adding
waters say), there's no harm doing that, but there's also not much
point since you'll have to do it all again with the complete model,
since adding a lot of waters will undoubtedly change the optimal
weights.  So I just leave the weight optimisation until the model is
complete.  As long as the initial weights are "in the same ball park",
so that your RMSZ(bonds) is around 0.5 for typical resolutions (a bit
lower for low resolution, a bit higher for very high resolution) it
won't affect interpretation of maps etc.

Cheers

-- Ian


From: ‪<kavya
Date: 14 October 2011 12:34
Subject: [ccp4bb]

Respected Sir,

I am sorry I wrote it wrongly, its resolution-
independent X-ray weight rather. I use ccp4i
so the input for the weight is what i mentioned
previously-
"Refinement parameters- weighing term (when
auto weighing is turned off)" in refmac.

Thanking you
With Regads
M. Kavyashree