(October 2001)
Which filter size do you normally use to prepare protein solutions for dynamic light scattering measurements? Is it really necessary to take 0.02 micrometer filters as recommended by ProteinSolutions and found in many papers, or are 0.2 or 0.1 micrometer filters also reliable? In our lab some people made good experiences with 0.2 micron filters. In one case good DLS data (monodisperse solution) and excellent and reproducible crystals afterwards were obtained. However after filtering the same protein solution with 0.02 micron filters the protein was apparently away. At least no DLS signal could be detected any more. Normally this observation itself could be interpretated as an indication of aggregation, but the crystallization results do not support this idea. So is it generally legitimate to swap to 0.2 micron filters if 0.02 micron filters catch away the protein? How are your experiences?
Summary from the enquirer - experiences from others:
• I was using 0.2 um spin-filters (I think they came from Eppendorf) when I ran out of the 0.02 um filters, and the results were alright. Normally, we are using the MicroFilters from Hampton without loss of protein. I would assume that if you loose protein, it's because the protein sticks to the membrane, in which case centrifugation might be a better way to get rid of aggregates in the first place.
• I have used 0.2 micron filters for DLS with no apparent problems.One of the original papers describing this method (Methods in Enzymology Vol. 276 p.157 by Ferre- D'Amare and Burley) use 200 Angstrom pore size ... Also, you should probably check your filtered sample another way to make sure that your protein is being trapped and nothing weirder is going on. Run a gel orUV-Vis spectra ??
• I regularly use a 0.1um filter to filter protein prior to DLS. I use the centrifugal filter from Millipore as this has no dead volume it doesn't waste your precious protein.
• I've found the smaller size filters (0.02) more difficult to use reliably. They seem to break or leak easily under modest pressure. In some cases, however, they seem to be necessary. I always try a larger filter first. With some practice you can recover most of the protein only slightly diluted and filter again with a finer mesh if need be.
• I normally start with 0.2 micron filters and work my way down if needed. As you indicated, sometimes you catch away all the protein which is indicative of lots of small aggregates. You will not be able to make good measurements from these whether you filter or not. You are wrong however to assume that aggregates and crystal gowth are incompatible!
• The folks at Prot.-Sol. say you can sometimes get away without filtering if you spin the sample first.
• We never filter our samples prior to DLS. Instead we centrifuge them in a benchtop centrifuge at maximum speed (the same as we would treat any sample prior to crystallisation). We were actually shown this by the Protein Solutions rep who visited our lab. We have had no problem analysing our samples after treating them this way.
• The golden question here is the size of your protein. If it is too big to go through 0.02 micron filters, you won't see a DLS signal. There is no protein in the solution. The protein is in the filter. Here I do not mean the unit-cell dimensions or contents of the asymmetric unit, but really truly monodisperse particle sizes in solution. That's where the answer is. Find out the true aggregation state of your protein, then you know what size filter cut-off to use.
RedHat7*
(June 2001)
I don't know how many others of you received a similar email from redhat, informing us that the compilers shipped with redhat7.1 were broken - so what's news?! Anyhow I have updated my Redhat _7.0_ system to use the new compiler and the news is .... better.
1. compiling the suite with the standard options (including optimisation level O2) - the compiled code still does not work.
2. compiling the WHOLE suite (not just progs) with the compiler optimisation level O0 - the suite does work!!! Well it compiles and $CEXAM/unix/runnable/run-all works (apart from hbond for some strange reason).
the way I did this was:
a. up2date my Linux redhat 7* system to the new compilers
b. download and unpack the ccp4 package (remember to check the ccp4 problems pages for fixes to some programs)
c. edit and source ccp4.setup as usual
d. run configure --with-your-options linux as usual (shared lib not tested) e. edit $CCP4/config.status - change as below:
f. FOPTIM="-O" COPTIM="-O" g.
h. to
i.
FOPTIM="-O0" COPTIM="-O0"
and re-run the config.status script (this in turn will re-run configure with the altered options)
j. make and install as usual.
I am assuming that the values the programs produce are sensible - I'm just pleased they didn't crash...
some system info:
ccp4h 2:57pm /runnable>45% rpm -q gcc glibc gcc-2.96-85
glibc-2.2-12
If anybody has any other/similar/more experiences please let me know. In turn I will let Kevin know and maybe he can update his excellent summary page.
Summary from the enquirer: I now have the following system:
1. redhat 7.0.
2. upgraded compiler from Redhat (using up2date) to gcc-2.96.85 (and g77 etc) 3. installed gcc(etc) 3.0 in /usr/local/bin - this was straight-forward
following this I had a clean distribution of CCP4 4.1.1. I configured as
.../configure --with-x linux
then edited $CCP4/config.status and changed FC to /usr/local/bin/f77 and
CC to /usr/local/bin/gcc
ran config.status (NB no change to optimization level) make and make install of the suite...
ran the $CEXAM/unix/runnable/run-all script...
AND IT ALL WORKED! again I hasten to add that the programs ran and didn't crash (so I'm assuming they gave sensible answeres)...
so in summary this probably isn't the best way to have your linux box set up but it does at least give a working compiled version of CCP4 for redhat 7* boxes.
I hope this helps. If the demand is really there I will make a web page (or Kevin might update his) with detailed instructions. Though my real current recomendation is - stick with RedHat 6.2.
A while later, Kevin adds to this:
Just to set the record straight, I would like to state here and now that the problems people have been having on RedHat 7.1 and 7.2, and other linux distros, are not the fault of the compilers shipped with 7.1 or 7.2. (either 2.96rh, or 3.0).
There are some assumptions in some ccp4 code, which are technically invalid with the F77 spec, but have been traditionally incorrectly implemented in the majority of Fortran
compilers. g77 is exceptional in interpreting the specifications correctly. To compile ccp4 on Linux, simply add
-fno-automatic
to the XFFLAGS in all the makefiles.
The resulting code will give sensible results using the example refmac scripts. (Of course there may be smaller problems not picked up by this test, if so we now have a chance of finding them.)
To summarise: Redhat did good. We didn't.