User: Frederik Ziebell
Frederik Ziebell • 0
- Reputation:
- 0
- Status:
- New User
- Location:
- EMBL Heidelberg
- Website:
- http://www.huber.embl.de/
- Last seen:
- 1 month, 2 weeks ago
- Joined:
- 6 months, 3 weeks ago
- Email:
- f********@web.de
Posts by Frederik Ziebell
<prev
• 10 results •
page 1 of 1 •
next >
0
votes
1
answers
204
views
1
answers
... Hi Mike,
thank you for having a look at my data! I'm also aware of the problem of "almost" confounding, but thought I could get away with it, since most runs share two conditions with other runs. We are currently setting up new runs to re-measure previous conditions and de-confound the design.
How ...
written 8 weeks ago by
Frederik Ziebell • 0
0
votes
1
answers
204
views
1
answers
... Here is the plot when setting n to the samples in a condition, which makes up a biological group:
Even when I use a more aggressive filter and set n to the number of samples in a run (48), the problem still remains:
...
written 9 weeks ago by
Frederik Ziebell • 0
0
votes
1
answers
204
views
1
answers
... Hi Mike,
I tried several filtering methods but none seemed to resove the problem. I made the problem smaller by just keeping two genes in the data with similar baseMean and variance. If I use ~condition+run as design, one gene gets a very low dispersion estimate and the other a very high one (upper ...
written 9 weeks ago by
Frederik Ziebell • 0
0
votes
1
answers
204
views
1
answers
... Hi Mike,
I followed up with your suggestion and figured out the source of the batch effect. It was a different read-length that affected the mapping, since I was using STAR with splice junction overhang equal to read length minus 1. After trimming all reads to the same length, the effect is gone:
...
written 9 weeks ago by
Frederik Ziebell • 0
0
votes
1
answers
204
views
1
answers
... Hi Mike,
indeed there are batch effects in the data. The way samples are processed is that 48 samples are always multiplexed together. So for these samples, library prep is performed, followed by sequencing and the combination of both is encoded as a "run". Here is a PCA of the vst-transformed coun ...
written 3 months ago by
Frederik Ziebell • 0
0
votes
1
answer
204
views
1
answer
... I have a RNASeq data set with ~650 samples. When I run DESeq2, I get a very poor fit of the mean-dispersion trend:
Here is also a plot of the original trend (without final dispersion estimates), and color coded the number of dispersion iterations:
This is the output of DESeq:
In DESeqDataSe ...
written 3 months ago by
Frederik Ziebell • 0
0
votes
1
answers
224
views
1
answers
... Hi Mike,
thank you for your explanations. The reason I like to use rlog() over vst() is that it achieves almost equal within-sample distributions of counts across all samples, which may be connected to the size factor issue you were mentioning. Do you see potential future improvements of rlog() usi ...
written 5 months ago by
Frederik Ziebell • 0
0
votes
1
answer
224
views
1
answer
... I have a data set in which the rlog transformation produces in one condition a few genes with very high log-transformed counts. Here is a mimimal example (the real data set has more gene but the same problems):
library("DESeq2")
library("tidyverse")
# load data
load(url("https://github.com/freder ...
written 5 months ago by
Frederik Ziebell • 0
0
votes
2
answers
233
views
2
answers
... I figured out the problem.
It was not the missing sashimiFilterTolerance argument (which I used already), but the introns specified in the sashimiFilter argument. It contained the same intron multiple times and I suppose GViz draws a sashimi for each specified intron, if there are reads stretching ...
written 6 months ago by
Frederik Ziebell • 0
1
vote
2
answers
233
views
2
answers
... Visualizing my RNAseq data, I find many instances of multiple sashimis stretching over the same inton, see for example: https://i.imgur.com/rEK7bQM.png
Is this a bug? If not, is there a way to combine those into one sashimi?
...
written 6 months ago by
Frederik Ziebell • 0
Latest awards to Frederik Ziebell
No awards yet. Soon to come :-)
Use of this site constitutes acceptance of our User
Agreement
and Privacy
Policy.
Powered by Biostar
version 2.2.0
Traffic: 366 users visited in the last hour