[mira_talk] Re: PacBio thread
- From: Chris Hoefler <hoeflerb@xxxxxxxxx>
- To: mira_talk@xxxxxxxxxxxxx
- Date: Tue, 6 Aug 2013 20:27:50 -0500
>We have had some good luck with PacBio assembly so I can share some of my
experiences with you if you like
Please do. I think people would be most interested in things like your
coverage levels, genome size, read lengths, and performance around
repetitive regions. Any challenges in particular?
On Tue, Aug 6, 2013 at 5:19 PM, Shane Brubaker <sbrubaker@xxxxxxxxxxxx>wrote:
> I am picking up on this thread a bit late so sorry if I am commenting on
> the wrong thing.****
>
> ** **
>
> I believe it is known that the polymerase can back-track and create an
> insertion which will probably match a preceding sequence although sometimes
> I think I saw other sequence. This should only happen in one or a small
> fraction of the reads and so could be removed or ignored during assembly.
> We have seen this quite a bit.****
>
> ** **
>
> We have had some good luck with PacBio assembly so I can share some of my
> experiences with you if you like. We also had to deal with diploidy which
> is a big problem for assemblers. We ended up using PacBio long reads and
> CCS reads, and we corrected with the CCS reads using SmrtPipe. We used the
> Allora assembler and managed to get a good collapsed “haploid” assembly.
> We had also done extensive 454 and Illumina sequencing beforehand and the
> assemblies were far, far more fragmented compared to the PacBio assembly.*
> ***
>
> ** **
>
> ** **
>
> Sincerely,****
>
> ** **
>
> Shane Brubaker****
>
> Director of BioInformatics****
>
> Solazyme, Inc.****
>
> 225 Gateway Blvd.****
>
> S. San Francisco, CA 94080****
>
> ** **
>
> *From:* mira_talk-bounce@xxxxxxxxxxxxx [mailto:
> mira_talk-bounce@xxxxxxxxxxxxx] *On Behalf Of *Chris Hoefler
> *Sent:* Tuesday, August 06, 2013 3:12 PM
>
> *To:* mira_talk@xxxxxxxxxxxxx
> *Subject:* [mira_talk] Re: PacBio thread****
>
> ** **
>
> >The insertion errors are more often extra base from the neighborhood as
> shown in the highlighted area – so it is not a random pick of AGCT.
>
> Ah, you did mean something different from what I thought you meant. ;) You
> are saying that, in the case of an inserted base, the spurious insertion is
> not a random selection of ACGT. That very well may be the case; I'm not
> sure if it has been looked at in detail. What is commonly meant by the
> random error distribution in PacBio, though, is that the indel itself is
> randomly distributed. In other words, the indel is just as likely to occur
> in a d{AT} repeat as it is to occur in a string of dG or the middle of YFG
> (your favorite gene), whether at the start of the read or the end of the
> read. I believe your screenshot illustrates that quite well. What the
> nature of the insertion is does not matter so much, I don't think, at least
> not for purpose of calling a consensus.
>
> >See the transition in the middle of the sequence, presumably they all
> passed base call quality.
>
> Very odd. Those do definitely look like sequencing errors. Seeing that, I
> would be suspecting the library or the sequencing. How does it look when
> you try to align that read with others from the same cell? Was it just a
> bad cell? I can't say that I have seen that. Maybe a stretch of inserted
> bases here and there, but nothing like what you are showing in that
> screenshot.
>
> >Given the same data set, HGAP and Quiver can assemble more or less
> complete contigs
>
> I meant more the "I'm not sure they can do de novo at single base
> resolution" comment. You are correct, the PacBio tools have improved a lot
> in the last year.****
>
> ** **
>
> On Tue, Aug 6, 2013 at 3:56 PM, Dang, Hong <dangh@xxxxxxxxxxxxx> wrote:***
> *
>
> >>As Bastien pointed out earlier, the errors are evenly distributed but
> there is a pattern (so I would not call it random) to them, in that they
> are often indels within the surrounding context.****
>
> ****
>
> >Can you elaborate on this point? Because that contradicts a number of
> PacBio and non-PacBio papers that have examined the error profile of PacBio
> reads. Unless you mean something different from what I think you mean.... ;)
> ****
>
> ****
>
> I should have narrow it specifically to insertions, and here’s example of
> a SNP and errors in a screenshot. The insertion errors are more often extra
> base from the neighborhood as shown in the highlighted area – so it is not
> a random pick of AGCT.****
>
> ****
>
> ****
>
> >>Imagine the polymerase incorporating certain base much quicker due to
> sequence context, that the recording movie did not capture the blip
> resulting in an apparent deletion****
>
> ****
>
> >Yes, it is hard to argue that there isn't at least some context bias, but
> the question is how much? Is it enough to say that there is a definite
> systematic error in the read distribution? I'm not sure about that. I think
> a proper statistical analysis is needed.****
>
> ****
>
> Sorry, this was meant to be a hypothetical scenario, which they may be
> able to improve through polymerase engineering. I don’t really how to
> formulate these into statistical models.****
>
> ****
>
> >>If you look at the sequence reads, quite frequently you will notice the
> complexity of the sequences drop in the middle and onward as if the
> polymerase was damaged by UV zap but not completely killed, so just
> stuffing mono- or di-base repeats until everything fall apart.****
>
> ****
>
> >I have not seen this problem. Do you filter the reads? The polymerase is
> susceptible to oxidative/UV damage (especially older versions), but in such
> cases, those stretches of bases should be marked with low quality scores
> and easily filtered out before error correction and assembly. ****
>
> ****
>
> These are from filtered sub-reads, in the top few long reads, I could see
> ~ 20% sequences as such:****
>
> ****
>
> See the transition in the middle of the sequence, presumably they all
> passed base call quality. But I have a hard time to think they are real.**
> **
>
> ****
>
> >>PacBio tools have improved a lot, although I'm not sure they can do de
> novo at single base resolution.****
>
> ****
>
> >I'm not sure what you mean by this....****
>
> ****
>
> Given the same data set, HGAP and Quiver can assemble more or less
> complete contigs with just a few frameshift errors, while before Allora
> could not.****
>
> Thanks,****
>
> Hong****
>
> ****
>
> *From:* mira_talk-bounce@xxxxxxxxxxxxx [mailto:
> mira_talk-bounce@xxxxxxxxxxxxx] *On Behalf Of *Chris Hoefler
> *Sent:* Tuesday, August 06, 2013 12:55 PM****
>
>
> *To:* mira_talk@xxxxxxxxxxxxx
> *Subject:* [mira_talk] Re: PacBio thread****
>
> ****
>
> >As Bastien pointed out earlier, the errors are evenly distributed but
> there is a pattern (so I would not call it random) to them, in that they
> are often indels within the surrounding context.****
>
> ****
>
> Can you elaborate on this point? Because that contradicts a number of
> PacBio and non-PacBio papers that have examined the error profile of PacBio
> reads. Unless you mean something different from what I think you mean.... ;)
> ****
>
> ****
>
> >Imagine the polymerase incorporating certain base much quicker due to
> sequence context, that the recording movie did not capture the blip
> resulting in an apparent deletion****
>
> ****
>
> Yes, it is hard to argue that there isn't at least some context bias, but
> the question is how much? Is it enough to say that there is a definite
> systematic error in the read distribution? I'm not sure about that. I think
> a proper statistical analysis is needed.****
>
> ****
>
> >If you look at the sequence reads, quite frequently you will notice the
> complexity of the sequences drop in the middle and onward as if the
> polymerase was damaged by UV zap but not completely killed, so just
> stuffing mono- or di-base repeats until everything fall apart.****
>
> ****
>
> I have not seen this problem. Do you filter the reads? The polymerase is
> susceptible to oxidative/UV damage (especially older versions), but in such
> cases, those stretches of bases should be marked with low quality scores
> and easily filtered out before error correction and assembly. ****
>
> ****
>
> >PacBio tools have improved a lot, although I'm not sure they can do de
> novo at single base resolution.****
>
> ****
>
> I'm not sure what you mean by this....****
>
> ****
>
> >Nearly****
>
> all workflow tasks (except initial filtering and pre-assembly) still
> run as single-threaded applications.****
>
> ****
>
> CA can be multi-threaded in a few of the stages (ex: the overlapper). You
> just have to tweak the spec file. Have a look at this example,****
>
> http://www.cbcb.umd.edu/software/PBcR/data/sampleData/asm.spec****
>
> ****
>
> ALLORA is not multi-threaded, but I don't see a strong reason to use it
> with many better options out there. For your fungal genome, you might try
> boosting up the memory usage. That will give some speed improvements as
> well.****
>
> ****
>
> On Mon, Aug 5, 2013 at 8:44 PM, Dang, Hong <dangh@xxxxxxxxxxxxx> wrote:***
> *
>
> This is a great discussion thread, and I'd like to add our experience with
> targeted sequencing of human mucin gene (MUC5AC) through a large repeat
> (VNTR) exon. We are in the process of revising our manuscript and it is our
> intention to deposit the data into SRA as soon as possible, when the
> collaborating PIs are comfortable with the manuscript accepted (should be 1
> or 2 months).
> 1) The problem: many mucin genes contain a large polymorphic central exon
> (10 - 12 kb) containing large segments of repeats (2 - 4 kb of 24 bp
> units), separated by several (most commonly 9) conserved domains (300 bp, ~
> 100 Cys rich). The fact that there is still a gap in the current reference
> genome suggested to us that this is a problem waiting for the right (niche)
> technology, and we were fortunate to have interested people at PacBio to
> collaborate on the project (making it affordable to us). We did not try
> short read correction, or moleculo (not available at the time) since we
> could not see them handling repeats.
> 2) What worked: we did long PCR (10 -12 kb) which were difficult and with
> many truncated short products (part of the reason for high coverage
> requirement), did 1-2 SMRT cells worth of sequencing for each sample, got ~
> 20,000x to 40,000x coverage from 3 patients, and de novo assembly with
> MIRA3.4. Seems pretty crazy, but we had arrived at 2 consensus contigs for
> each diploid patient genome at single nucleotide resolution - one can tell
> a SNP (close to 50:50 alleles in het) from error given sufficient coverage
> (>30x "effective" at every single base). By "effective", I mean reads
> aligned in the assembly and supporting a contig. Since this is pretty much
> over a large exon of ~ 10 kb, we can estimate that there is < 1
> frame-shifting error in ~10 kb (or Phred score > 40) in the final contigs.
> We could not accurately assess the real coverage, but mixed PCR products,
> repeats and reads length/position, and the error rate all can be expected
> to bump up the coverage requirement.
> 3) Error characteristics: I have manually sampled the error, and they are
> > ~90% indels and 10% substitutions, probably a little more deletions than
> insertions for indels. As Bastien pointed out earlier, the errors are
> evenly distributed but there is a pattern (so I would not call it random)
> to them, in that they are often indels within the surrounding context. In
> fact, I use it in my manual review of the assembly to distinguish real
> indels (if they don't seem to arise from context, and there is another
> indel nearby to re-adjust reading frame), from errors (sequence context).
> 4) Other thoughts (biases) on source of errors and nature of single
> molecule behavior: I tend to agree that there may be a limit, and we are
> already close, on accuracy at single molecule (read) level, but they are
> still trying to engineer the polymerase, and (probably) use machine
> learning to improve base calling. Imagine the polymerase incorporating
> certain base much quicker due to sequence context, that the recording movie
> did not capture the blip resulting in an apparent deletion, slowing
> polymerase down through protein engineering may help. If you look at the
> sequence reads, quite frequently you will notice the complexity of the
> sequences drop in the middle and onward as if the polymerase was damaged by
> UV zap but not completely killed, so just stuffing mono- or di-base repeats
> until everything fall apart. But in the end the single molecule is the
> reason (I think) that one can get long reads at all since as long as the
> polymerase is alive, one can read a base incorporation signal.
> 5) Software and assembly strategies: We used MIRA, because at the time
> HGAP was not available, and SMRT portal was not able to handle the repeats
> yet, and MIRA offered an opportunity to try many parameters. We did get a
> lot of help from PacBio bioinformatics group, and the HGAP and PacBio tools
> have improved a lot, although I'm not sure they can do de novo at single
> base resolution. If I'm starting a now project, I'll certainly give PacBio
> tools a try since I expect them to be faster (a MIRA run for us took ~ 1
> week, of course with 20k - 40k coverage, and a moderate machine -16 core,
> 49 GB ram).
>
> So from our experience, we think that long reads from PacBio do help in
> solving certain kind of problems (long repeats), but the high error in raw
> reads is probably not going to get better soon, and one will have to deal
> with them using high coverage (HGAP and Quivar for self correction).
> Hope these helps, and we are grateful to Bastien and all who made MIRA
> available!
> Regards,
> Hong ****
> ------------------------------
>
> *From:* mira_talk-bounce@xxxxxxxxxxxxx [mira_talk-bounce@xxxxxxxxxxxxx]
> on behalf of Chris Hoefler [hoeflerb@xxxxxxxxx]
> *Sent:* Monday, August 05, 2013 3:41 PM
> *To:* mira_talk@xxxxxxxxxxxxx
> *Subject:* [mira_talk] Re: PacBio thread****
>
> Well, I guess I'm responsible for bringing PacBio into the conversation,
> so here's my two cents. ****
>
> ****
>
> PacBio is in a sweet spot for bacterial-sized genomes. With the latest RS
> upgrade, you can get about 220-250 Mb per SMRTcell, which allows you to get
> >100X coverage of a 10 Mb genome for ~$1200. That is expensive relative to
> Illumina technology, but it makes up for it in the long reads. It is the
> long reads that make it a killer technology, in my opinion. Even bacterial
> genomes can have long stretches of near-repeats that are difficult to
> assemble with Illumina/454. In addition, genomes heavily biased in one
> direction or the other (GC-rich or AT-rich) can be problematic with other
> sequencing technologies. PacBio reads are almost completely free of context
> biases. The polymerase will happily read through a region of 100% GC just
> as easily as a region of 50% GC. For our Streptomyces genome (high %GC),
> Illumina/454 could not do the job. The assemblies were highly fragmented
> and repetitive regions were misassembled. It wasn't until we had some nice
> long PacBio reads that we were able to greatly improve the assembly. If
> anybody is interested in assembling bacterial genomes, I recommend this
> recent paper by Koren et al,****
>
> ****
>
> Reducing assembly complexity of microbial genomes with single-molecule
> sequencing****
>
> http://arxiv.org/abs/1304.3752****
>
> ****
>
> It illuminates many of the challenges associated with assembling different
> classes of bacterial genomes and how the long read technology simplifies
> the process. As Adrian mentioned there is Moleculo. Personally, I am not
> too impressed by this offering. For one, it is behind. PacBio can do 10 kb
> reads now, with a very simple library protocol. They are rapidly
> approaching the ability to routinely get >20 kb reads. Second, Moleculo is
> a sequencing service, rather than a sequencing technology. I don't see how
> this can be cheap at all. There is also the ALLPATHS approach. While I do
> think this works well for a large number of genomes, getting the large
> jumping libraries is laborious and tricky. Since you can get the
> long-distance information and additional sequence information from PacBio
> alone, I prefer that approach (did I say the library prep is easy?).****
>
> ****
>
> >The error rate is still the same, about 85%.****
>
> ****
>
> Yes, the error is high. But remember what this is: single-molecule
> sequencing. Each read comes from a polymerase walking down a single DNA
> strand. As with single-molecule pretty-much-everything, there is a high
> degree of stochastic variability. Fortunately, as the single-molecule
> people learned a long time ago, a population distribution of
> single-molecule measurements reflects and encompasses the measurement of
> population ensemble averages. In DNA sequencing terms, single-molecule
> sequencing reads are variable, but can be combined to give you a high
> consensus accuracy (the ensemble average of the population). This is
> effectively what all sequencing technologies do. It's just that PacBio
> gives you the single-molecule reads in addition to the ensemble average,
> which you can do a lot of neat things with.****
>
> ****
>
> >The big thing now though is their HGAP assembly process. Basically****
>
> they take their longest reads (7-10kb) and use them as "seeds" to be
> error-corrected by other reads. By doing this they get highly
> accurate long artificial readsThe big thing now though is their HGAP
> assembly process. Basically
> they take their longest reads (7-10kb) and use them as "seeds" to be
> error-corrected by other reads. By doing this they get highly
> accurate long artificial reads ****
>
> ****
>
> I wouldn't call them "artificial" reads. They are corrected reads.
> Meaning, multiple single-molecule reads have been aligned and "averaged" to
> give a consensus read. The reason I like HGAP the best, of all the
> error-correcting strategies, is it is self-correcting, meaning you won't be
> propagating error from multiple data sets. In the end you will have just
> the PacBio error. Also, at the moment, HGAP is the only way to get long
> error-corrected reads. When you correct with Illumina or 454, it invariably
> truncates the reads, which defeats the purpose of using PacBio in the first
> place.****
>
> ****
>
> > In case of lower PacBio coverage (say 15-30x) and error correction using
> external reads, LSC was better in error correcting compared to PacBioToCA,
> but LSC gives fasta without qualities.****
>
> ****
>
> While LSC was interesting, I could never trust it. There was no way to
> verify the quality of the error correction because they just never gave you
> any of that data (or even the final qualities for that matter). Even
> PacBioToCA will give you nice long error-corrected reads if you ignore the
> qualities.****
>
> ****
>
> > In the end, the best results I got was with a good PacBio coverage
> (around 100) and HGAP in "self-correcting" mode, and the assembly with
> ALLORA was impressive: 1 contig for a 4.4Mb bug (+ 1 gap in an area of few
> kb of crazy nested-tandem repeats). I didn't try MIRA though.****
>
> ****
>
> Did you try CA for the assembly? In all of my tests, CA always performed
> better than ALLORA. Probably the reason why they chose CA for their HGAP
> pipeline. But Mira works pretty well too. If it is tweaked a bit, it will
> probably perform better than CA. Bastien should correct me if I'm wrong,
> but I believe Mira basically treats PacBio reads as long Sanger reads, and
> the standard overlapping algorithms just aren't accustomed to dealing with
> >1 kb overlaps.****
>
> ****
>
> > I got another bug sequenced with PacBio, around 50x, genome size around
> 10Mb. Assembly spits hundreds of contigs. This makes me think a good PacBio
> coverage is rather around 100x than 50x (plus bugs with larger genomes are
> likely having more repeats).****
>
> ****
>
> The error-correction ratio for HGAP depends on the initial
> size-distribution of your reads. Because of this, your ratio is about 1:3
> for high coverage (ie: ~100X raw will yield ~30X corrected), but closer to
> 1:5 for lower coverage. So if you start with only 50X, you will probably
> end up with only about 10X corrected. Another way to use PacBio, if getting
> enough coverage for de novo is problematic, is to use it for scaffolding.
> You can scaffold with raw reads using AHA or error-corrected reads. I think
> the way Mira handles this by default is the best way: short reads plus long
> error-corrected PacBio reads. Then it will use the short-reads for good
> coverage depth across the genome and the long-read information to resolve
> repeats and order contigs.****
>
> ****
>
> >But then I need error correction where I can be sure that repeats do not
> get mangled.****
>
> ****
>
> There are a few different parameters to tweak for the PreAssembler
> error-correction in the PacBio pipeline. The ones you will probably be most
> interested in are "allowPartialAlignments" and "minLongReadLength". The
> allowPartialAlignments can improve coverage of error-corrected reads, but
> can be dangerous if you suspect a lot of repeats. The minLongReadLength
> should be picked to give you ~3X short read coverage over long read
> coverage within your dataset for a good balance between final
> error-corrected coverage and error-corrected read length. If you suspect a
> lot of repeats, you can shift the minLongReadLength up a bit. This will
> reduce your final error-corrected coverage, but you will get longer reads
> in the end and a trustworthy accuracy. This balance between short reads and
> long reads is the reason why the error-correction performs better when you
> pool SMRTcell datasets as opposed to error-correcting each individually and
> combining them. More short reads equals better error-correction, and there
> are proportionally fewer long reads in a given dataset.****
>
> ****
>
> >I got a prototype running just yesterday which shows that the basic idea
> works, maybe even well enough to get something usable out of 15x to 30x
> PacBio.****
>
> ****
>
> Woohoo! Can't wait to see it. ;)****
>
> ****
>
> Ok, maybe that ended up being two dollars instead of two cents. ;) I'm not
> a PacBio sales rep, I promise. I just really like their technology.****
>
> ****
>
> Best,****
>
> Chris****
>
> ****
>
> ****
>
> On Mon, Aug 5, 2013 at 5:18 AM, Bastien Chevreux <bach@xxxxxxxxxxxx>
> wrote:****
>
> On Aug 5, 2013, at 9:32 , Andrej Benjak <abenjak@xxxxxxxxx> wrote:
> > Sorry Adrian for digressing from the original topic…
>
> Well, I started the digression so I'm the one to blame. On the other hand,
> PB is picking up speed altogether, a couple of of posts here gave some
> pretty interesting insights and PB has now some higher priority for me at
> the moment (I'll get to the reasons further down the post).
>
> Therefore I'm doing something evil here, something I normally regard as a
> big no-no in mailing lists: hi-jack the sub-thread … but rename it to gain
> back a little bit of the lost karma.
>
> Feel free to post any remark or observation regarding PacBio (even if MIRA
> may not be involved) in this thread now :-)
>
> > In case of lower PacBio coverage (say 15-30x) and error correction using
> external reads, LSC was better in error correcting compared to PacBioToCA,
> but LSC gives fasta without qualities.
>
> And here ladies and gentlemen we have one of the reasons why I love this
> mailing list and the people on it: LSC went completely past me, I'll have
> to check it out.
>
> > In the end, the best results I got was with a good PacBio coverage
> (around 100) and HGAP in "self-correcting" mode, and the assembly with
> ALLORA was impressive: 1 contig for a 4.4Mb bug (+ 1 gap in an area of few
> kb of crazy nested-tandem repeats). I didn't try MIRA though.
>
> In a first test I did with self-corrected PB data (public E. coli tough,
> i.e. data from PB), it looked like MIRA was doing well enough for a "new"
> type of long reads it didn't really know yet. A bit heavy-handed on the
> clipping perhaps, and I'll need to revise a couple of quality settings.
>
> > I got another bug sequenced with PacBio, around 50x, genome size around
> 10Mb. Assembly spits hundreds of contigs. This makes me think a good PacBio
> coverage is rather around 100x than 50x (plus bugs with larger genomes are
> likely having more repeats).
> >
> > I get the feeling that working with suboptimal PacBio coverages is a
> nightmare. With the sequencing costs being currently quite low, it is worth
> going for a decent coverage, then the error correction is easier/better as
> well as the final assembly.
>
> You are scaring me a bit here, especially in conjunction with the repeat
> gap in your aforementioned bug :-(
>
> One of the reasons I'm getting interested in PB is that at work (I mean:
> in my day job, the one which brings in the money) we have a 454 / Illumina
> sequencing of an organism with an estimated 40 MB which went awfully,
> awfully wrong: we got some 6500 contigs back. Post-mortem analysis showed
> that the bug should be at least diploid ... but it also consists of
> approximately 30% high-copy number repeats which were long enough to not be
> spanned by the 454 800bp library. Although we have different Illumina
> jumping libraries to help scaffolding, we still have a mess: the scaffolds
> span the predicted 40 MB quite well, but we have only 27 MB contigs with
> the rest almost unassemblable.
>
> I feel a bit guilty as I'd been the one to approve the sequencing strategy
> and I had expected to get back with somewhere between 100 and 500 contigs.
> In hindsight, I should have made a cheap Illumina pre-sequencing to asses
> the complexity of the bug, but hindsight is always 20/20. Well, a learning
> for the future.
>
> Anyway: I am currently running a PacBio pre-test on a bacterium we know
> inside out (down to the last base except some rRNA) to find out how well PB
> self-correction will work out at different coverages. The reason being that
> getting PacBio 100x for a 40 MB bug will still represent a very significant
> investment. I am also a bit wary about us having 30% high-copy repeats and
> want to see how well the different correction algorithms work with those …
> the last thing I want are miscorrections.
>
> And lastly, I am experimenting with error-self-correction myself as I
> think it's the only way to go, especially for higher complexity bugs with
> very nasty repeat structures. But then I need error correction where I can
> be sure that repeats do not get mangled. I got a prototype running just
> yesterday which shows that the basic idea works, maybe even well enough to
> get something usable out of 15x to 30x PacBio. It won't be a speed demon
> though … then again, MIRA generally never was :-)
>
> B.
> --
> You have received this mail because you are subscribed to the mira_talk
> mailing list. For information on how to subscribe or unsubscribe, please
> visit http://www.chevreux.org/mira_mailinglists.html****
>
>
>
> ****
>
> ****
>
> --
> Chris Hoefler, PhD
> Postdoctoral Research Associate
> Straight Lab
> Texas A&M University
> 2128 TAMU
> College Station, TX 77843-2128****
>
>
>
> ****
>
> ****
>
> --
> Chris Hoefler, PhD
> Postdoctoral Research Associate
> Straight Lab
> Texas A&M University
> 2128 TAMU
> College Station, TX 77843-2128****
>
>
>
> ****
>
> ** **
>
> --
> Chris Hoefler, PhD
> Postdoctoral Research Associate
> Straight Lab
> Texas A&M University
> 2128 TAMU
> College Station, TX 77843-2128****
>
--
Chris Hoefler, PhD
Postdoctoral Research Associate
Straight Lab
Texas A&M University
2128 TAMU
College Station, TX 77843-2128
Other related posts:
