You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to the very high IO necessary for trimmomatic's log production, some machines will halt this process to a crawl. A fix has been done in PR #178 but I don't consider this an ideal solution as it does not address the IO issue.
A potential solution is to no save the log file but instead obtain the trimming statistics from the trimmed reads themselves, as it's implemmented in INNUca
The text was updated successfully, but these errors were encountered:
I don't think this is an issue due to the run time of trimmomatic and it was only reported for docker on mac. The fix basically redirected the trimmomatic's log to /tmp and the only problem that can derive from there is using shifter and /tmp not being mapped. As such I don't think you should wait any time solving this. In my opinion , and as I already explained to @miguelpmachado, this is a closed subject for it would be a waste of resources to solve this.
Due to the very high IO necessary for trimmomatic's log production, some machines will halt this process to a crawl. A fix has been done in PR #178 but I don't consider this an ideal solution as it does not address the IO issue.
A potential solution is to no save the log file but instead obtain the trimming statistics from the trimmed reads themselves, as it's implemmented in INNUca
The text was updated successfully, but these errors were encountered: