Flux simulator: negative coordinates in simulated BED file

[GoogleCodeExporter]

What steps will reproduce the problem?
Happens when simulating 36 and 75 base reads. see par file attached

What is the expected output? What do you see instead?
example:
chr1    -247086421      247086421      
chr1:247071274-247086777C#uc001iev.1#149:113    0       -       0       0 
     0,0,0   1       36      0

What version of the product are you using? On what operating system?
FluxSimulator-v1.2-j1.5-b20090725

Please provide any additional information below.

Original issue reported on code.google.com by julien...@gmail.com on 4 Aug 2009 at 5:35

Attachments:

• test.par

[GoogleCodeExporter]

Original comment by gmicha@gmail.com on 5 Aug 2009 at 2:37

• Added labels: Simulator

[GoogleCodeExporter]

Hi, i got the same problem. Additionally I have lines in the .bed file with
chromEnd==0 && chromStart>0 like:
chrI  599  0  chrI:600-1020W#1#10709:241  0  -  0  0  0,0,0  1  241  0

What steps will reproduce the problem?
using the attached .gtf file with the parameters from the also attached .par 
file.
(probably works also with default parameters, I have not tried that)

What version of the product are you using? On what operating system?
FluxSimulator-v1.2-j1.5-b20090729

Original comment by mun...@gmail.com on 11 Aug 2009 at 2:38

Attachments:

• out.gtf
• mytest.par

[GoogleCodeExporter]

Reproduced, coordinate update problem in existing BEDobject

Original comment by gmicha@gmail.com on 11 Aug 2009 at 8:01

• Changed state: Accepted

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Changed coordinate handling of BEDobject
Also added coordinates relative to length of the sequenced read in artificial 
"polyA"
chromosome in case somebody wants to reproduce these reads.

Fix version:  Simulator build 20090811 
Alpha test:   check bed lines for (start< 0|| end<= 0|| start>= end)

passed, closed.

Original comment by gmicha@gmail.com on 11 Aug 2009 at 8:07

[GoogleCodeExporter]

cool micha thanks

now that you've fixed the bug, do you think the output of the previous releases 
could
be "fixed" just by removing lines with $2<0?

what i mean is: was $2<0 the only symptom of this bug, or just one of them?
thanks

Original comment by mc...@flux.sammeth.net on 11 Aug 2009 at 8:56

[GoogleCodeExporter]

As far as I could reproduce, all (well, most) reads that were sequenced from the
crick strand (strand in the produced bed line is "-") were affected -- which 
incur in
transcripts from BOTH strands. 

Therefore the lines with ($2< 0|| $3<= 0) should make up a quite substantial 
amount
and removing them will probably reduce the experiment size to roughly the half.
However, if you want to do that, bed lines with strand "+" should not have been
affected. 

Original comment by gmicha@gmail.com on 11 Aug 2009 at 9:04