some questions about the usage of 'split_dis'

[bitcometz]

Hello,

I think 'split_dis' is a great idea and I want to use it to help me get better genome assembly, for example, to generate more complete repeat region, but I have some question about the usage of 'split_dis':

I know cons.fasta contains the "corrected" fasta. But I am not sure:
the reads of "in.las" or "in.db" refer to "corrected" reads or "raw(uncorrected)" reads?

Thanks!

split_dis
split_dis performs disagreement based read pile splitting for haplotypes and repeats. It expects four arguments

out.las: the name of the output file, which will be written in the LAS file format
cons.fasta: a read consensus file for the reads in the input database in FastA format as produced by daccord
in.las: alignments for in.db as generated by DALIGNER
in.db: input read database

[bitcometz]

Hello,

And I used the daccord corrected reads as input: in.fasta to run daligner to generate
raw_data.1.las
and use this alignment to run with daccord to generate preads.1.fasta
Then I try to run split_dis:

bin/split_dis -t5 -d30 -D200 out1.las ./preads.1.fasta ./raw_data.1.las ./raw_data.dam

and stop in the log file like this and it continue to run without outputting more information:

DC[186]=0 1333
DC[187]=0 1270
DC[188]=0 1270
DC[189]=0 1331
DC[190]=0 9393
DC[191]=0 1270
DC[192]=0 9094
DC[193]=0 1413
DC[194]=0 8424
DC[195]=0 6801
DC[196]=0 1331
DC[197]=0 1283
DC[198]=0 1331
[V] keep 9 106;120;146;150;188;230;239;315;321;340;370;444;447;459;465;511;574;575;636;654;762;763;767;791;798;881;905;910;913;969;983;
[V] drop 9
[V] read id 9 time 77478400

[bitcometz]

And I try this:
bin/computeextrinsicqv in.fasta preads.1.fasta raw_data.dam 1

the memory surge up to 100G. It was hard to believe because the fasta is only 33Mbp.

[gt1]

Hi,

concerning computeextrinsicqv: I forgot to update the documentation concerning the arguments expected. This is updated now, please try again with the most recent README.md hints.

about split_dis: this is so far mainly a proof of concept program. While it works as a general idea, it does not really cope yet with high depth or a large number of repeat instances. I have used it to separate up to 7 or 8 copies at depth 20 each, but this is already pretty slow. Anything more will probably take forever with the current implementation.

Best,
German

[bitcometz]

Thanks very much for your help