We have been encountering some issues with the Chromoseq workflow, specifically when to use the compressed vs non-compressed version of the reference fasta. The inconsistencies are due to differences in the underlying setup- while the docker image has the fasta file compressed, there is a wrapper script that first decompresses it, then handles launching Cromwell; on the cluster, this decompression step does not happen, which is why it's necessary to use the gz version if it's not first manually decompressed. This should be noted in the short term as further development occurs and the two workflows diverge, but once the reference is removed from the image and instead stored on Basespace to be used as an input, this problem will disappear.
We have been encountering some issues with the Chromoseq workflow, specifically when to use the compressed vs non-compressed version of the reference fasta. The inconsistencies are due to differences in the underlying setup- while the docker image has the fasta file compressed, there is a wrapper script that first decompresses it, then handles launching Cromwell; on the cluster, this decompression step does not happen, which is why it's necessary to use the gz version if it's not first manually decompressed. This should be noted in the short term as further development occurs and the two workflows diverge, but once the reference is removed from the image and instead stored on Basespace to be used as an input, this problem will disappear.