CRAM files won't load (local deployment)

[jemunro]

Describe the bug
We have a local deployment of seqr on our HPC which is working well overall, however I can't get CRAM files to load for read visualization. BAM files work fine.

I've tested the same CRAM files on the IGV JS web app and they work fine there, so I'm not sure what the issue is. I'm using the GATK reference genome (Homo_sapiens_assembly38.fasta) to create the BAMs and CRAMs.

The error message is:
"BAM header error: bad magic number. This could be caused by either a corrupt or missing file."

Screenshots

[hanars]

This is most likely caused by providing an invalid file path to seqr. Make sure your file path is given to seqr relative to the /readviz mounted volume (or whichever mounted volume you are using). To confirm that seqr has access to the file, try running docker-compose exec seqr ls <file_path> and confirm that the path is valid

[jemunro]

Thanks for the suggestion.

I have confirmed that the file paths are correct. In fact, it seems like the "Add IGV Paths" dialogue will check that the files exist anyway, as if you give a path that doesn't exist you get an error: Error updating <SAMPLE>: Error accessing "/readviz/<...>/<SAMPLE>.cram"

Any other suggestions? FYI I'm running with singularity instead of docker, but everything else is working fine except for the cram files.

[jemunro]

From the stdout from seqr I see the following when a file is attempted to be loaded:

{"timestamp": "2023-02-24 13:29:24,957", "severity": "INFO", "httpRequest": {"requestMethod": "GET", "requestUrl": "http://<HOST>:4040/api/project/R0001_udp/igv_track//readviz/readviz_udp_full/S35152_1.readviz.cram?file=/placeholder.cram&options=-b,-H", "status": 200, "responseSize": null, "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36 Edg/<IP>", "remoteIp": "<IP>", "referer": "http://<HOST>:4040/variant_search/results/3be51ca9665afebabdac6cb82b005f1b?page=1&sort=pathogenicity", "protocol": "HTTP/1.1"}, "user": "<USER>"}

Is the "file=/placeholder.cram" part an issue or expected?

[hanars]

hmmm looks like there might be a very specific bug with loading non-google storage crams. You mentioned before that you tested the files on the files on the IGV JS web app and they worked - is there any way you can let me know what track configuration you were using? Also, do you have a .crai index file for these crams?

[jemunro]

I'm not 100% sure what you mean by track configuration. The genome was set to hg38 and I didn't touch anything else.

Yes, the crams have corresponding .crai in the same location.

[jemunro]

I'm wondering if it is related to these sections of code:

seqr/ui/shared/components/panel/family/FamilyReads.jsx

Lines 71 to 86 in da32a7d

	const track = getTrackOptions(type, sample, individual)
	if (type === ALIGNMENT_TYPE) {
	if (sample.filePath.endsWith('.cram')) {
	if (sample.filePath.startsWith('gs://')) {
	Object.assign(track, {
	format: 'cram',
	indexURL: `${track.url}.crai`,
	})
	} else {
	Object.assign(track, CRAM_PROXY_TRACK_OPTIONS)
	}
	} else {
	Object.assign(track, BAM_TRACK_OPTIONS)
	}
	} else if (type === JUNCTION_TYPE) {

seqr/ui/shared/components/panel/family/constants.js

Lines 15 to 19 in da32a7d

	export const CRAM_PROXY_TRACK_OPTIONS = {
	sourceType: 'pysam',
	alignmentFile: '/placeholder.cram',
	referenceFile: '/placeholder.fa',
	}

It seems like the format is never set to cram (not sure if that is needed for sourceType: 'pysam'), and also the index url is not set.

[hanars]

getTrackOptions sets the format correctly, the code on line 77 to set the format is actually not needed. The index URl might be an issue though, and I don't think the placeholders are needed anymore. I will try updating the options and see if that fixes it for you

[hanars]

The latest docker image should fix this issue, please update and let me know if that fixes it

[jemunro]

Thanks for trying to fix. I'm getting a different error message now: "incorrect data check". Still works fine with BAMs.

[hanars]

😢