BED file did not store the same information as BAM

Question

BED file did not store the same information as BAM

Closed this issue 2 months ago · 10 comments

gotouerina commented 6 months ago

Operating System

CentOS 7

Other Linux

No response

Workflow Version

v1.1.0

Workflow Execution

EPI2ME Desktop application

EPI2ME Version

No response

CLI command run

nextflow run /home/106public/software/wf-pore-c --fastq A4Mpass.fq.gz --ref xxx.fasta --cutter NlaIII -c increase_memory.config --threads 60 --paired_end_minimum_distance 100 --paired_end_maximum_distance 200 --chunk_size 10000 --paired_end --bed

Workflow Execution - CLI Execution Profile

standard (default)

What happened?

I got a 700GB pair-end bam and 13 GB bed files. I used yahs for anchor but I get different results for bam and bed. I think the bed files did not stored the same information as bam files.

In addiation, .hic file produced by the BED file was too small (about 900MB when anchoring by yahs).

Relevant log output

no error log files

Application activity log entry

No response

Were you able to successfully run the latest version of the workflow with the demo data?

yes

Other demo data information

none

Answer 1 · 2024-03-12T10:59:07.000Z

Hi, thanks for the feedback - we will look in to this. are you using the BAM from within the paired_end folder of the output?

I am not sure what you mean by the .hic file produced with the bed file? We generate a hic file from the workflow using the juicer tool.

Answer 2 · 2024-03-12T11:08:39.000Z

Hi, thanks for the feedback - we will look in to this. are you using the BAM from within the paired_end folder of the output?

I am not sure what you mean by the .hic file produced with the bed file? We generate a hic file from the workflow using the juicer tool.

Yes. I used BED files produced by add --bed parameter but get very bad anchoring results (see picture 1)
Then I used pair-end bam for yahs anchoring and get different results. (see picture 2)

What I care is, it produced different results from different output file. And I think it is not recommanded to use the bed format file in yahs now.

We used juicerbox to correct the scaffloding results, and it need .assemble and .hic file produced by juicer pre. The .hic file was not produced by your pipeline (It is produced after yahs anchoring).

Answer 3 · 2024-03-12T11:11:49.000Z

I do not think it is problem of yahs. I think it is fault in wf-pore-c. The output Bed format file may be incorrect?

Answer 4 · 2024-03-12T11:26:33.000Z

I checked code and found "monomers.mm2.ns.bam" was used to create bed file.

Is this a single-end bam or a pair-end bam?

Answer 5 · 2024-03-12T12:07:33.000Z

Ah ok thanks for the feedback, we will check it and update it. monomers.mm2.ns.bam - this is a single-end BAM.

Answer 6 · 2024-03-12T12:34:34.000Z

Ah ok thanks for the feedback, we will check it and update it. monomers.mm2.ns.bam - this is a single-end BAM.

As I know, yahs could not access single end bam. This may lead to wrong results. Please check it.

Answer 7 · 2024-03-12T13:04:47.000Z

Hi Dear Sarah,

I think I know what happened.

Most scafflding software only identified pair-end reads by /1 and /2. And your bed file did not contained it, which could lead to the terrible results.

Answer 8 · 2024-03-12T14:20:40.000Z

Thanks, we will get this amended soon

Answer 9 · 2024-06-10T13:58:53.000Z

Hi - this is now updated in the pre-release

Answer 10 · 2024-07-29T15:45:34.000Z

Closing through lack of response and this is now in the tagged version.