Brass produces output but returns code 255

[edawson]

I ran brass.pl on the hcc test data provided here and the CGP bundle for BRASS >= v6. I get the following files back:

HCC1143.insert_size_distr 
HCC1143_vs_HCC1143_BL.inversions.pdf
HCC1143_vs_HCC1143_BL.r2
HCC1143_vs_HCC1143_BL.groups
HCC1143_vs_HCC1143_BL.is_fb_artefact.txt
HCC1143_vs_HCC1143_BL.r3
HCC1143_vs_HCC1143_BL.groups.filtered.bedpe
HCC1143_vs_HCC1143_BL.ngscn.abs_cn.bg
HCC1143_vs_HCC1143_BL.r4
HCC1143_vs_HCC1143_BL.groups.filtered.bedpe.preclean
HCC1143_vs_HCC1143_BL.ngscn.diagnostic_plots.pdf  tmpBrass
HCC1143_vs_HCC1143_BL.groups.filtered.bedpenohead
HCC1143_vs_HCC1143_BL.ngscn.segments.abs_cn.bg

but the return code that gets sent to the workflow engine is 255, indicating some sort of failure.

Are there any docs I missed on the correct full set of outputs? I'm having trouble debugging what failed because there's no stdout/stderr output.

[keiranmraine]

Do you need to use the pcawg version? We don't really support that as it's about 3 years old, its provided frozen for legacy reasons. Nor is it compatible with the brass v6 ref files.

Anyway, for the current versions, and IIRC pcawg too, the BRASS output folder should contain a logs folder containing all of the brass stdout/stder for the processes executed within the master, ordering this by time should help you find the error.

FYI unless you need to use the HCC cell line data you will find COLO-829 a more representative sample for testing with:

ftp://ngs.sanger.ac.uk/production/cancer/dockstore/cgpwgs/

[edawson]

I don't need the PCAWG version - I just need a dockerized version I can call in WDL. I started working on one but figured it was good to use a community-standard one. The docker image I'm using is from CGP-Docker (quay.io/wtsicgp/dockstore-cgpwgs:1.1.3) and contains BRASS Version: 6.0.4.

[keiranmraine]

I'd be very happy to accept a WDL PR for dockstore-cgpwgs, we plan to start splitting out the individual tools soon.

[edawson]

I'd be very happy to work on that with y'all. I've got panel of normals ("filter") generation split into a few WDL workflows and a brass.pl WDL as well. All my WDL lives at https://github.com/edawson/firecloud-tools/tree/master/brass.

Could we maybe make a brass-wdl repo for the cancerit/CGP organization that we could collab in, then submodule it to a pan-CGP repo?

[keiranmraine]

That sounds good. I'll have to get a quick approval to create a new collaborator group for workflows but I'll ping you back as soon as I can. We've not worked with WDL but it makes sense to have it around for those what want it.

[keiranmraine]

Ready for you to work with here: https://github.com/cancerit/BRASS-wdl

[edawson]

The bad return code does show up in the logs:

FAILED: /opt/wtsi-cgp/bin/blat all_ncbi_bacteria.1.fa.2bit /cromwell-executions/brassMainWorkflow/0b126397-f79d-47a2-bab1-1bc1ffee85ee/call-brassMainTask/execution/results/tmpBrass/remap_micro/allreads_bB8yVh -maxIntron=20 /cromwell-executions/brassMainWorkflow/0b126397-f79d-47a2-bab1-1bc1ffee85ee/call-brassMainTask/execution/results/tmpBrass/remap_micro/allreads_bB8yVh.blat
Command exited with non-zero status 255

The file it's trying to BLAT (allreads_bB8yVh) doesn't seem to exist. Any ideas on why this might be the case?

[keiranmraine]

@edawson the allreads_* files are tmp files generated by the parent perl process so will be deleted when the process exits:

https://github.com/cancerit/BRASS/blob/0c1899c0bccecde0d61b7311bf689cf52ba6994a/perl/bin/filter_with_microbes_and_remapping.pl#L145

It would be possible to change this to accept a flag to retain files on failure for debugging purposes (other steps have it) but I'll have to mark it for the back-log (we do have a block of time scheduled for issues in this repo).

@sb43 when you get to this block of work, can you grab me for a discussion about how best to handle this?

[sb43]

@keiranmraine Added UNLINK=>0 if --noclean flag is set