These are chat archives for dereneaton/ipyrad

Jan 2018
Isaac Overcast
Jan 18 2018 18:01
@ivanprates Hey Ivan! This naming scheme is a result of the denovo+reference assembly method. The "GL343210.1" are CHROM names of the unplaced scaffolds in the Anolis assembly, this is a pretty standard naming scheme. The locus_# CHROM names come from all the reads that did not match to the reference. In the denovo+reference assembly method the reads are first mapped to the reference sequence. Then unmapped reads are denovo assembled, and mapped reads are assembled and concatenated to the denovo loci. In the case of the vcf you posted there are only ~1400 unmapped loci, which I assume is a small fraction of the total data. If you don't want unmapped reads you should use the reference assembly method, which will throw out all unmapped reads.
Hope you're having a good time in DC!
Jan 18 2018 19:14
@isaacovercast Hi Isaac. I am still running into the problem regarding ticket #280 with version 0.7.19. When I run step 1 with sorted fastqs (pair3rad setting) the json file only prints the first barcode from the barcode file for each individual, eg "barcodes":{
"AUMS21495":"TTAGGCA", and for each individual it reads "barcode":null, This can be overcome by manually editing the json file prior to running step 2, but would be nice to not have to do this. I noticed that when I run step 1, but forgot to give it the path to the sorted fastqs, it printed both barcodes correctly in the json file but of course stopped after that. Thank you!
Isaac Overcast
Jan 18 2018 21:54
@JStarrett hm. Well i tried to replicate this problem and I can't get it to happen. Part of step 2 should automatically attempt to relink the barcodes if they aren't linked. Are you sure the file format is correct? Can you post your params file to the ticket? Also if you could run step 2 again and include the -d flag this will generate debug output in the ipyrad_log.txt file. If you can email this to me ill check it out.