Yet - I think - the 104 doesn't change the output thing. I have run the 104 on
the same input sequence I sent you yesterday, and this is what I got (only
first few columns shown):
Microsatellites:
name records_id id motif start
chr12:42011465-42047304 0 0 AC 1516
chr12:42011465-42047304 0 1 AC 1534
chr12:42011465-42047304 0 2 AC 22521
chr12:42011465-42047304 0 3 AC 22565
chr12:42011465-42047304 0 4 AT 1240
So all msats have records_id 0 and each msat has id from 0 to 5. All is well
:-) and I expected to have primers for each records_id, id combination. Yet:
Primers (shown only for the msats id 0):
name records_id msats_id primer left left_sequence
Potentially duplicated primers:
chr12:42011465-42047304 0 0 0 1204,2 ACCTGGTCCTTTCATCGGTG
chr12:42011465-42047304 0 0 0 1204,2 ACCTGGTCCTTTCATCGGTG
chr12:42011465-42047304 0 0 0 22323,2 GAGCTGACGTTTCACCAGTC
chr12:42011465-42047304 0 0 0 22323,2 GAGCTGACGTTTCACCAGTC
So here you can see that the same records_id, id combination that in the
previous file uniqely defined each msat, now does not. In the primers output,
records_id 0, msats_id 0 now actually seems to indicate primers for msats
records_id 0, id 0 *or* 1 *and* 2 *or* 3.
What I expected (and think would be clearer) is for example:
name records_id msats_id primer left left_sequence
Potentially duplicated primers:
chr12:42011465-42047304 0 0 0 1204,2 ACCTGGTCCTTTCATCGGTG (-> primer for msat
id 0)
chr12:42011465-42047304 0 1 0 1204,2 ACCTGGTCCTTTCATCGGTG (-> primer for msat
id 1)
chr12:42011465-42047304 0 2 0 22323,2 GAGCTGACGTTTCACCAGTC (-> primer for msat
id 2)
chr12:42011465-42047304 0 3 0 22323,2 GAGCTGACGTTTCACCAGTC (-> primer for msat
id 3... and so on)
This is the 'bug' I complained about and I AFAIK it hasn't change in 104beta.
Original issue reported on code.google.com by brant.fa...@gmail.com on 4 May 2011 at 4:24
Original issue reported on code.google.com by
brant.fa...@gmail.com
on 4 May 2011 at 4:24