Hi @ldawson and thanks for the ping @igor !!
I reviewed the history and noticed two problems, and can explain the cryptic error message:
- MACS2 callpeak
The parameters for calling peaks was set for single-end instead of paired-end. This will have scientific implications, too, and should be corrected, since it is a mismatch for the input BAM/BED data. Sometimes this will trigger an error at this step, but not always, and the issue shows up in downstream data reduction step errors, or even just odd scientific “results” that are not so easy to detect. Later on you’ll be using workflows to avoid manual entry problems.
For now, you can review the Job Details for upstream jobs and maybe spot the problems (eye or pencil icon on a dataset, then toggle into the tab).
- wigtobigwig
MACS2 will sometimes create peaks that “overhang” the chromosome ends (known behavior, anywhere it is used). Using wigtobigwig with an advanced option to clip these off is a good idea to avoid problems.
The default is to not clip since it can be an important warning that the reference genome assembly versions used were maybe mixed up in earlier steps, as discussed already). You have the correct assemblies from what I saw with a quick review, so clipping can be applied. More details → Reference genomes at public Galaxy servers: GRCh38/hg38 example and example of a mismatch here → ATAC-Seq Analysis Using MACS2 Callpeak
Toggle open the advanced parameters here
Prior discussion, as a reference → ATAC-seq data analysis tutorial: troubleshooting - #5 by jennaj (includes a link to the MACS2 forum where the same situation is discussed with the base tool) and → tools that require bigwig input cannot use bedgraph (as bigwig) file - #15 by jennaj (I think this one was already seen, so I’m linking it all together for anyone else who may run into this little wrinkle in the future!)
- DUE TO TIME LIMIT error
For this error, the reason can be some problem with the data/parameters that create a job that executes for longer than the maximum time limit on our clusters (varies by tool, but tends to be about 48 hours).
I was able to reproduce this when testing with the clipped chromosomes. Adjusting the paired versus single end status will likely correct this. Even if the result was putatively “successful” at the AU server, I would be cautious about using the result. As an additional exercise in understanding how MACS2 calls peaks, maybe explore the result with the parameters set correctly against not and see if you can notice the differences?
Actually large analysis can trigger this situation too, and trying at a different server is certainly a good option since the clusters resources can differ (and you might get interesting job logs if the tool can process far enough along to report them before crashing out), but still consider any error/log a warning. Confirming that you understand why the job is unexpectedly long running might matter eg are the parameters optimal? is there another way to organize the data for the same result? are there scientific reasons for the error, not just technical? those kinds of considerations. You’ll learn how to recognize these situations the more you work with specific tools and/or a particular class of data sample.
Explanation → FAQ: Understanding walltime error messages
Hope this helps! 
