Currently, the process CHECK_FASTQ_TYPE() is a precursor to trimming/denoising steps. This would be fine, only it funnels the data in an inelegant way: it takes as input a FASTQ artifact, and outputs both the same input artifact (effectively giving it a throughway) and analysis performed on the artifact.
It would be far better to duplicate the FASTQ artifact into two processes instead -- though in this case the issue would be that an artifact failing this check would not stop in the other arm.
Currently, the process
CHECK_FASTQ_TYPE()is a precursor to trimming/denoising steps. This would be fine, only it funnels the data in an inelegant way: it takes as input a FASTQ artifact, and outputs both the same input artifact (effectively giving it a throughway) and analysis performed on the artifact.It would be far better to duplicate the FASTQ artifact into two processes instead -- though in this case the issue would be that an artifact failing this check would not stop in the other arm.