The equations used were as follows:

where J = contact rate, “d is the spherical diameter of the average cell (cm), D_v the viral diffusivity (cm² s^-1), and V and B the [in situ] concentrations of viruses and bacteria respectively (ml^-1 [brine or seawater]).”

“where k is Boltzmann’s constant, T the temperature (Kelvin), the viscosity (g cm^-1 s^-1), and dv the spherical diameter of the average virus (cm)”. D_v can be estimated with the following equation (determined empirically from Figure 1) where t is temperature (°C).

The authors provide the following values for constants:

but they don’t provide for the calculation of , the viscosity in the ice, referring to a 1975 paper by George Cox (which references a 1960 paper by Dale Kaufmann [which itself references a 1929 paper by Stakelbeck and Plank]).

The following multiple linear equation can be used to estimate the viscosity (in centipoise = 0.01 * g cm^-1 s-1) as a function of temperature (T) and brine salinty (S) in the ice, but it is not very good:

[The raw data and R script to calculate the multiple linear regression are available here]

A better empirical equation was determined using ZunZun.com, an amazingly useful site for curve fitting. I used the Function Finder, which identified a Reciprocal Polynomial as the best available curve. The simplified equation for that curve is (mu in centipoise= 0.01 * g cm^-1 s^-1):

Finally, to calculate the relative contact rates between seawater and sea ice, given concentrations of bacteria and viruses (per volume brine or seawater):

which can be generalized to:

where V_br is the brine volume fraction (calculator available here), “the subscripts i and w indicate sea ice and water column respectively. The terms f_B and f_V represent the fraction of bacteria and viruses retained in the brine and serve as a correction to account for possible partitioning within the solid phase … as well as for two major mechanisms of loss: destruction due to impinging ice crystals or osmotic stress and release with rejected brine.

If passive entrainment into the ice (proportional to salts) is expected for both viruses and bacteria, then , where S is the bulk salinity of the ice or water.

If active entrainment into the ice is expected (complete/active concentration of bacteria and viruses into ice), then

If the concentration of bacteria (or viruses) in the ice is 0 then f_B = 0.

Another enrichment index has been used by others, including Riedel (2006), originally from Gradinger and Ikalvko (1998). Their index (I_s) is 0 when the concentration in ice is 0 (I_s = 0 when C_i = 0) and is 1 when the concentration in ice is proportional to the salt retained in the ice (I_s = 0 when C_i/C_w =S_i/S_w).

A third index can be created such that at a value of 0 indicates passive enrichment and a value of 1 indicates complete/active enrichment. A value less than zero indicates loss or mortality in the ice (-1 indicates an in situ concentration of 0). Any value greater than 1 indicates production or growth within the ice.

temperature bulk salinity brine concentrating factor

You can see that most of the signal in this sample is contained within a few peaks. Sometimes those peaks saturate (max-out, overblow) the detector, which is bad if I am interested in comparing the heights of the peaks (a controversial subject, I should note I am only doing bulk, not individual, comparisons). Of course, I could just add less DNA and run it again, except that then I would be liable to lose some of the smaller peaks (also, it’s not practical for me to re-run these specific samples). So I’ve written a script in the open-source statistical package R to estimate the heights of the saturated peaks by fitting a Gaussian function of the form

where ‘y_0′ is the y-minimum, ‘x_0′ is the center of the peak, ‘b’ is a scaling factor, and ‘d’ is related to the standard deviation of the distribution.

You can download the script here: gaussfit.r

The figures below show (A) a fitted regular-sized peak, and (B) a fitted saturated peak. In my case, the fitted function has a maximum that is 1.6 ± 2.5% of the observed maximum for regular-sized peaks.

Briefly, the way it works is that you set up a central repository for your files, preferably on some computer that is connected to the internet all the time, even better if it has a static domain name. Into this repository you place the files you want to be version controlled. This works best for plain text files (like LaTeX source files) because it is simple to compare versions if necessary, but it will also work for binary files like OpenOffice documents (which have built-in version control, if you didn’t know) and images. If you are working on the computer with the central repository, great, just make sure to update the files each time before you work on them and commit them each time you are done. You could probably write a cron job to do this for you if you are liable to forget. If you are working on a different computer, you just have to ask the central repository for the files and it will give you the latest versions. After you edit them you have to commit the changes to a local repository, which can then be merged with the central repository.

To get started:

• Install bzr
• Make a new directory and copy the files you’ll be starting with into it. If you’re using LaTeX, you’ll probably only want the files that are not compiled, e.g. *.tex, *.bib, *.bst and NOT *.aux, *.log, etc.
• Tell bzr who you are:
  bzr whoami "me <me@me.com>"
• Initialize tracking in this directory:
  bzr init
• Add all the files in the directory, recursively:
  bzr add
• Commit the files to the first revision. Make sure to add a message (-m), or you might find yourself in ‘vi’ (shudder). Do this after every work session.
  bzr commit -m "very important message"
• Next time you work from this computer with the central repository, make sure you are using the most recent version:
  bzr update
• The first time you work on your project from a different computer, pull a new copy via ssh from that computer:
  bzr branch sftp://user@host.domain:port/location/to/remote/files /new/local/location
• In future sessions, pull new edits from the central repository before working on them:
  bzr merge sftp://user@host.domain:port/location/to/remote/files
  bzr commit -m "merge from parent"
• To submit edits to the central repository, first commit them locally, then push edits via ssh to that computer:
  bzr commit -m "local changes"
  bzr push sftp://user@host.domain:port/location/to/remote/files

Some further usage, much of which is intuitive because it works just like regular unix commands:

• Clean up a directory by deleting non-versioned files and reloading the last commit:
  bzr commit
   rm *
  bzr revert
• Make a new versioned subdirectory:
  bzr mkdir ./newdirectory
• Add a new file to the repository:
  bzr add ./newfile.txt
• Remove a file from the repository:
  bzr rm ./oldfile.txt
• Rename or move a file or directory in the repository:
  bzr mv oldfile.txt newfile.txt

and installed the packages arb (base installation), transfig (something to do with LaTeX), xfig (for exporting trees), and libmotif3 (for library libXm.so.3)

More info here: http://techno.mikro.biologie.tu-muenchen.de/

1. get sequences into ARB, via e.g. greengenes or SILVA or RDP. If importing an alignment in FASTA format you may need to use the following IFT (save with rest of arb .ift files, e.g. usr/arb/lib/import/fasta_wgap.ift):
   AUTODETECT      ">*"
           #Global settings:
   KEYWIDTH        1
   BEGIN   ">??*"
   MATCH   ">*"
           SRT "* *=*1:*\t*=*1"
           WRITE "name"
   MATCH   ">*"
           SRT "*|*=*1"
           WRITE "full_name"
   SEQUENCEAFTER   "*"
   SEQUENCESRT     ""
   SEQUENCECOLUMN  0
   SEQUENCEEND     ">*"
   # DONT_GEN_NAMES
   CREATE_ACC_FROM_SEQUENCE
   END     "//"
2. in ARB: prune tree to closest isolates, closest clones/from environment, and enough internal branches for context. make a copy for each tree you work on.
3. in ARB: mark all in tree, look at alignment, unselect those not full length/long enough, note start and end of full length section by position.
4. in ARB: export sequence to fasta (File–>Export–>Export to foreign format). You may want to use a simple export file (EFT) like the following (save it with the others e.g. usr/arb/lib/import/fasta_simple.eft or wherever) :
   SUFFIX          fasta
   BEGIN
   >*(name)
   *(|export_sequence)

   During the export use a hypervariable SAI (made by parsimony) to filter by quality (Lane 1991 mask) “-=.0123456″ and region to export, using the starting and ending positions you determined previously

5. in SEAVIEW, open exported FASTA file and save as NEXUS file (the export filter from ARB to PAUP doesn’t seem to work very well)
6. PAUP may get grouchy if you have digit-only sequence names, so you can run the following script to temporarily change the names.
   s/'\([0-9]\{4,\}\)'/'\1tmpname'/g

   Save the script as ‘fromdigits.sed’ (it’s easier as a file because the apostrophes in the regular expression complicate things on the command line) and run

   sed -f fromdigits.sed [filename.nexus] > [filename.converted.nexus]

   After running PAUP you can change the names back in the PHYLIP tree files by using the following sed script:

   sed -e 's/\([0-9]\{4,\}\)tmp[name]*/\1/g' [treefile.phy] > [treefile.converted.phy]

   Or, from NEXUS tree files:

   sed -e 's/\([0-9]\{4,\}\)tmp[name]*/\1/g' [treefile.nexus] > [treefile.converted.nexus]
7. in a text editor, open NEXUS file and append PAUP block to end, save as new file. for bootstrapping, the PAUP block may come from MODELTEST (NOTE bug in PAUP 4.10b means you have to add an extra command to MODELTEST input block: “default lscores longfmt=yes”). for ratcheting the PAUP block may come from PRAP2
8. run in PAUP to get parsimony/likelihood trees, save trees in phylip format. if you only have a NEXUS tree, open it in a texteditor and delete the introductory NEXUS block. keep only what is between the outermost parentheses.
9. in ARB: input consensus tree with bootstraps back into arb using Tree–>TreeAdmin–>Import. make sure to remove the period (.) from the tree name or it won’t import.
10. in ARB: save distance matrix to ‘infile’ by doing Tree–>Build Tree–>Distance Methods–>Phylip Distance Matrix, then use the same filter as above for trees. Hit ‘y’ and try to save the file that opens up as ‘/tmp/infile’. If no file pops up, make sure you’ve installed ‘xedit’ or make a soft link from e.g. /usr/bin/xedit to some other text editor e.g. gedit, kedit. If you can’t save the file anywhere, copy it from the ~/.arb_tmp directory in your home folder.
11. in ARB: save tree to /tmp/arbtree (Tree–>Tree Admin–>Export).
12. here is a script that does the following 3 steps:
    #
    # Script file for automating the process of adding distances to likelihood tree
    # REC
    
    # turns tree from arb ('arbtree') and distance matrix from dnadist ('distmatrix') into arb tree plus distances ('arbtree.fitch.outtree')
    
    filedate=`date +%s`
    
    mkdir tmp$filedate
    cd tmp$filedate
    
    # clean up tree file
    # the sed '1d' removes the notes line -- if you have zero or more than one you'll need to change this or do it manually
    # the tr -d [:space:] gets rid of all the whitespace
    sed '1d' < ./../arbtree | tr -d [:space:] > intree
    
    # unroot tree file
    (echo y; echo w; echo u; echo q)|(retree)
    mv intree arbtree.retree.intree
    mv outtree intree
    
    # run fitch to add the distances to the tree we've supplied
    cp ./../distmatrix infile
    (echo d; echo u; echo -; echo y)|(fitch)
    mv intree arbtree.fitch.intree
    mv infile arbtree.fitch.infile
    mv outtree arbtree.fitch.outtree
    mv outfile arbtree.fitch.outfile
    cd ..

to do it manually: in a text editor: delete first line and despace tree for phylip, or do the following on the command line:

sed '1d' < arbtree | tr -d [:space:] > intree

with PHYLIP: run retree –> write unrooted tree, then mv outtree intree

with PHYLIP: run fitch, choose options D –> minimum evolution, U –> input file, – –> no negative lengths

13. in ARB: import outtree with Tree–>Tree Admin–>Import
14. get NDS info organized and displayed correctly, e.g.
    • –to rename accession numbers to accession numbers from greengenes
      copy full_name to acc
      :*=*(full_name)

      then get rid of extraneous info:

      /[0-9][0-9]* [A-Z][A-Z]*[0-9]*\.*[0-9]* //
      /\..*//
    • –to rename full_name by sequence info
      copy full_name to tmp and to backup (just in case)
      :*=*(full_name)

      then get rid of extraneous info:

      /[0-9][0-9]* [A-Z][A-Z]*[0-9]*\.*[0-9]* //
    • then copy tmp to full_name
      :*=*(tmp)
15. in ARB: export to XFIG (Tree–>Export to xfig) with no handles, no colors, full tree
16. in XFIG: immediately export to SVG
17. in INKSCAPE: open svg tree file and edit as necessary
18. in INKSCAPE: resize page (File –> document properties –> fit page to selection), resize selection to maximize page, export bitmap 300dpi png
]]> http://staff.washington.edu/rec3141/wordpress/archives/410/feed 0 http://staff.washington.edu/rec3141/wordpress/archives/386 http://staff.washington.edu/rec3141/wordpress/archives/386#comments Tue, 06 Jan 2009 23:35:05 +0000 eric http://staff.washington.edu/rec3141/wordpress/archives/386 Trying to get a Parsimony (and likelihood) Ratchet protocol going I spent a couple hours trying to get PAUPRat working, including compiling an old compiler and finding old versions of libraries and editing Makefiles… then I found a newer Java program that does the same thing: PRAP2. The program includes the Likelihood ratchet protocol described above but not the Parsimony. Here are the settings for the Parsimony ratchet protocol, as described by Sikes et al., which are then replicated by PRAP2 into PAUP* blocks.
[!* startcmd: * * * * * * * * * * * * *  *]  
[!* ----- Parsimony Ratchet  -----*]
[!*       as in PAUPrat               *]                                                                                  
[!*           January, 2009          *]                                                                                  
Time;
Log File=paupratchet.log;                                                                                                    
Set Increase=auto;
hs status=no nrep=1 swap=tbr start=stepwise addseq=random nchuck=1 chuckscore=1;
savetrees file=mydata.tre replace;
savetrees file=mydata.tmp replace;
[!* paupcmd: * * * * * * * * * * * * *  *]
pset mstaxa=uncertain;
hsearch status=no start=1 swap=tbr multrees=no;
[!* rewtdcmd:* * * * * * * * * * * * *  *]  
[!* normcmd:* * * * * * * * * * * * *  *]
savetrees file=mydata.tmp replace;
gettrees file=mydata.tre mode=7;
savetrees file=mydata.tre replace;
gettrees file=mydata.tmp mode=3 warntree=no;
Time;
[!* stopcmd: * * * * * * * * * * * * *  *]
gettrees file=mydata.tre mode=3;
pscores all;
Time;                                
Log Stop;                            
[!* * * * * * * * * * * * * * * * *]
[!* -- THIS SEARCH IS COMPLETE -- *]
[!*  A LOG FILE HAS BEEN WRITTEN  *]
[!* AND ALL TREES HAVE BEEN SAVED *]
[!*    IT IS OKAY TO QUIT PAUP    *]
[!* * * * * * * * * * * * * * * * *]
Quit;

Update: PRAP2 has a built-in parsimony ratchet that is more cleanly written than this one, except I had to remove the command ‘dropmode=execute’ because PAUP* 4b10 wasn’t recognizing it. Using the pre-configured ratchet you can choose the number of runs to code automatically, but using a custom script you can’t. So here’s a bash shell script to automate the script above, after generating some number (here N=20) script files named ’sequences.[1-N].nexus’.

#!/bin/bash
for i in `jot 20 1 20`;
do
 `paup sequences.$i.nexus`
 `mv -f mydata.tmp mydata.$i.tmp`
 `mv -f mydata.tre mydata.$i.tre`
 `mv -f paupratchet.log paupratchet.$i.log`
done

Since the parsimony ratchets run quickly it is fine to do them all on one processor, but I’m starting the likelihood runs separately on each processor. This script will run them one at a time, but if you add ’screen -S like.$i’ to the line before ‘/bin/paup…’ it should start up to 10 simultaneously in separate “screens“, assuming your nexus files are all in the same directory and named ratchet.like.[1-10].nexus

#!/bin/bash
for i in `jot 10 1 10`;
do
 `mkdir like$i`
 `cp ratchet.like.$i.nexus ./like$i/`
  cd like$i
 `/bin/paup4b10-ppc-macosx -n ./ratchet.like.$i.nexus`
 cd ..
done
]]> http://staff.washington.edu/rec3141/wordpress/archives/386/feed 0 http://staff.washington.edu/rec3141/wordpress/archives/351 http://staff.washington.edu/rec3141/wordpress/archives/351#comments Mon, 29 Dec 2008 22:32:30 +0000 eric http://staff.washington.edu/rec3141/?p=351 Have you ever noticed hundreds of crows streaming through the shadows at dusk (probably making a ruckus)? Have you ever watched a crow chase away a bald eagle and wondered at its gumption? Have you ever been dive-bombed by a territorial crow? Have you ever wondered why? Have you ever wanted to tell someone else about your crow encounters? If so, here is your chance. I’ve created an interactive website (http://staff.washington.edu/rec3141/crows) enabling citizen scientists to share their crow observations with scientists and each other using a variety of web technologies. The ultimate goal of this project is to involve citizens in the process of scientific discovery. During this process I hope we will build a useful database of crow happenings in the Puget Sound region and beyond. The backend requirements for the website are open-source and freely available so that creating a similar site to track another species would require minimal effort.

The website is organized around a map of the Puget Sound region, and the majority of the data is geocoded so that sightings can be placed into geographic context. The primary method of data submission is via the website itself, including instructions and guidance on reporting anecdotes, daily migrations, nightly roosts, and crows banded by Prof. John Marzluff (http://www.urbanecology.washington.edu/people/marzluff.htm) at the University of Washington. Additionally, anecdotes can be submitted via Twitter (http://twitter.com), a popular micro-blogging web site, by including the tag #seattlecrows in any posting. Updates to Twitter can be made from mobile phones via SMS text messaging. Finally, geotagged photos labeled with the word ‘crow’ are automatically added from Flickr (http://flickr.com), a popular photo-sharing web site.

The submitted data is incorporated into a database and made available in real-time. It is important that the observations be accessible to those who made them (that is, the public), rather than be potentially lost in the black box of a researcher’s office, only to resurface years later in an relatively-inaccessible scientific journal article. Once submitted, each type of data is plotted on the map using unique icons; clicking on the icons reveals detailed information about each submission. The data is also available as an RSS feed (http://staff.washington.edu/rec3141/crows/crowfeed.rss) which can be read by any news aggregator (e.g. Bloglines, Google Reader). New submissions can be tracked on Twitter by following @seattlecrows (http://twitter.com/seattlecrows).

Crows are all around us — sometimes in staggering numbers — and it seems that everyone has at least one story to tell about crows! Love them or hate them, they’ll be with civilization for a long, long time. Take the chance to get to know your corvid neighbors — you won’t regret it. Submit your crow sightings at http://tinyurl.com/seattlecrows

]]> http://staff.washington.edu/rec3141/wordpress/archives/351/feed 2 http://staff.washington.edu/rec3141/wordpress/archives/241 http://staff.washington.edu/rec3141/wordpress/archives/241#comments Thu, 18 Sep 2008 21:10:03 +0000 eric http://staff.washington.edu/rec3141/?p=241 Clearly, the publishers think there is. “[John] Conyers, a liberal Democrat whom one might expect to be on the other side of this issue, is taking harsh aim at a new National Institutes of Health (NIH) policy requiring NIH-funded scientists to archive their published papers in a publicly accessible database within a year of publication.” A recent Nature Blog post (The Great Beyond: Open access: public good or publishers’ evil?) details a seedy melange of scientific publishing houses, lobbyists, and Congress. Here’s another post at PolITiGenomics: Open access under attack.

So, clearly, we need to do something about it. Here’s one way: write to your Representatives. I did…

Representative McDermott,
As a UW graduate student in the sciences, and a constituent who is strongly in support of the advancement of science, I am writing to urge you to vote against the Fair Copyright in Research Works Act (HR 6845). This bill will revoke the requirement for US taxpayer-funded research to be made accessible to those taxpayers who funded it, for the sole gain of (mostly foreign) publishing houses.  Open access to scientific research advances science in a positive feedback cycle, while limiting access for the sake of profits for a few throttles scientific advancement for many. Open access to government-funded research was a long overdue stance that provides the American taxpayer with the highest return on his or her investment. HR 6845 would undermine science and devalue the government’s investment in science. I strongly urge you to vote against HR 6845, and to consider writing a counter-proposal that would extend the NIH requirement for open access to NSF-funded research as well.  Thank you for your time.

Sincerely,
Eric Collins
School of Oceanography
University of Washington

Here’s another way: Open Access Day – October 14, 2008. I would like to participate but there is nothing yet planned at UW. Shall I begin…?

]]> http://staff.washington.edu/rec3141/wordpress/archives/241/feed 0 http://staff.washington.edu/rec3141/wordpress/archives/198 http://staff.washington.edu/rec3141/wordpress/archives/198#comments Thu, 11 Sep 2008 00:05:57 +0000 eric http://staff.washington.edu/rec3141/?p=198 I received a question today about monosodium glutamate (MSG), in particular the concentration of MSG in yeast and yeast extracts, which are often used as flavorings (Nutritional Yeast) and spreads (e.g. Vegemite and Marmite). As usual, I headed to the web to find the answer, and as usual in these kinds of matters, what I found was a miry mix of science, pseudoscience, bias, and bollocks. (What I didn’t find was the answer to that question…) In particular, two competing sites seem to host a lot of the ‘information’ present on the web about MSG. One group is an industry group called the International Food Information Council, which hosts a ‘review’ of the literature, and find, surprisingly enough, that there are no harmful effects of consuming MSG. In that document they highlight a review of a study by Geha et al., and assure us that “any observed reactions were mild, transient, and not life threatening.” The document doesn’t mention that there were statistically significant increases in reactions to free glutamate in almost 40% of the subjects, a self-selected group of people who thought they had previously had a reaction to MSG.

TABLE II. Protocol A (n = 130): Frequency of symptoms reported to challenge with 5 g of MSG versus placebo


You'll notice that half of the reactions were reported significantly more after exposure to MSG than to placebo. They also mention that a number of other reactions were reported in the presence of MSG and not placebo, which aren't listed here. Also note that the low level of significance they chose to determine which reactions were statistically more common: alpha = 0.005. Perhaps this is common in medical literature, I don't know, but a much more common level is ten times higher, alpha = 0.05. Their choice of a much lower level means that these 5 reactions were highly significantly more frequent after MSG than not. The authors acknowledge this but then discount these results later because they were not ‘reproducible’ and because of something they term ‘demand bias’. I don’t know what this term means, but it doesn’t appear commonly in the literature. In a search of Google Scholar, many of the papers that came up bearing this term were related to glutamate studies. Oh, did I forget to mention that this study, and most of the others, were funded by various branches of the glutamate industry? oops… This particular papers bears the note “Supported by a grant from the International Glutamate Technical Committee”, which bears some kind of relation to the “The Glutamate Association“.

An explanation of these groups is found on the other website I mentioned before, Truth in Labeling. This consumer advocate site contains, predictably, a lot of anecdotes and ad hominem attacks against the industry (advocates of which are deprecatingly termed ‘Glutes’). It also contains some analyses and fact-checking on the studies and news releases put out by the MSG industry. On the whole, I’m with them. Outspent and out-shouted, they’re doing what they can to understand the true ramifications of this pervasive substance in our food supply, without much help from independent researchers.

Nevertheless, if industry goes too far in denying reactions to MSG, consumer advocates probably go too far in pursuing claims of reactions to MSG. Of course, replace ‘MSG’ in the last sentence with innumerable other chemicals compounds and it will still be just as true. Both the under- and over-interpretation of data can lead to bias and general confusion over the true meaning of the findings. I suspect that MSG really is safe in modest quantities for most people, but that some people can have adverse reactions that can range from discomfiture, to discomfort, to true danger. Unfortunately, I’m doubtful that those on either side of arguments like this are willing to make the kind of intellectual concessions necessary to find the grain of truth amidst the hyperbolic grit.

]]> http://staff.washington.edu/rec3141/wordpress/archives/198/feed 0 http://staff.washington.edu/rec3141/wordpress/archives/169 http://staff.washington.edu/rec3141/wordpress/archives/169#comments Tue, 19 Aug 2008 22:32:45 +0000 eric http://staff.washington.edu/rec3141/?p=169 We use optical density (OD) at a wavelength of 600nm as a quick approximation of cell abundance in liquid bacterial culture in lieu of counting the cells on a microscope. Different bacterial strains can have different relationships between OD and cell abundance depending on the amounts of polysaccharides or other secondary metabolites they might extrude into the culture medium or coat themselves with, which may vary with temperature or growth medium, for example.

A former student in the lab, A. Huston, measured OD600 and microscope counts of Colwellia psychrerythraea strain 34H in Marine Broth 2216 at two temperatures: -1C and its optimal temperature, +8C. Although the growth rate of the bacterium at +8C is several times that at -1C, there appears to be little difference in the relationship between cell abundance and OD at the two temperatures.



Some linear equations were provided to convert from OD to cell abundance, but here I’ve taken the original data and used a logistic function to get a better conversion. The equation below has an r^2 of 0.98 for the combined -1 and +8C temperature data.





(Thanks to Hamline University Physics Department Latex Equation Editor for the online LaTeXing, and to the open source graphing program QtiPlot)

]]> http://staff.washington.edu/rec3141/wordpress/archives/169/feed 2