Trimmomatic implementation error

[jfaberha]

Hi, I'm able to get grenepipe running with example data and the tests are all successful. I'm getting an java-related error however when it gets to the trimmomatic steps with some different fastq inputs. It generates error logs at the trimmomatic step, then gets a little further before the pipeline freezes. These datasets work with grenepipe when swapping the trimming step to cutadapt or other tools. The error logs (hs_err_pid*) are extremely complex and it's hard for me to make heads or tails of it. Forgive me if it's only a memory request issue on my end, but the example data works with the same parameters with a far lower memory allotment. Any idea how to address this, and if these errors are the primary reason grenepipe ends up freezing at step 47 (in this particular run)?

hs_err_pid204918.log
hs_err_pid206680.log
2024-12-19T153218.870860.snakemake.log

[lczech]

Hey @jfaberha,

hm, from just those files, it is not clear to me either, at least not on first glance. New type of error. Could you please do the following:

• Also post the grenepipe snakemake log file here (in logs/snakemake), as that contains additional system information, as well as the trimmomatic logs in logs/trimming. Furthermore, if you are running this on a cluster with slurm, also the slurm log files, both of the main snakemake instance (on the head/login node) and the trimmomatic slurm log. See here for details on that.
• Try running it with more memory, just to see if that is the reason. If you are using slurm, that means editing the slurm config, see here.
• Try running it manually, to see if this is indeed just within trimmomatic itself, or somehow based on interaction with snakemake or conda. The command line for that is at the beginning of the error logs you posted, in Summary. There is a weird memory contraint there (-Xmx164M) which might cause this. Try -Xmx10G or something like that instead.

Let's see if any of that yields any further insights :-)

Cheers and so long
Lucas

[jfaberha]

Hi Lucas, Thanks again for the quick reply. Here are the log files from logs/snakemake and logs/trimming/trimmomatic. Keep in mind, I aborted the run manually since it was hanging at step 47 for over an hour. I attempted to run paired-end fastqs from 4 samples, and the trimming logs from 3/4 samples showed they ran successfully, therefore I only attached the log from the failed sample (this sample was successfully trimmed using other tools available in grenepipe). This run was done on a cluster through a development node, not through the scheduler, but I've gotten similar results when scheduled through slurm. I've scheduled another couple runs with more requested memory, one version with all 4 samples and one version omitting the 1 failed sample. They may be in the queue for a while, but I'll let you know how they work out hopefully early next week. I'll play around with trimmomatic as a standalone step as well. Thanks, Josh [S07T5-1.log](https://github.com/user-attachments/files/18205003/S07T5-1.log) [2024-12-19T153217.635452.log](https://github.com/user-attachments/files/18205004/2024-12-19T153217.635452.log)

…

On Thu, Dec 19, 2024 at 5:18 PM Lucas Czech ***@***.***> wrote: Hey @jfaberha <https://github.com/jfaberha>, hm, from just those files, it is not clear to me either, at least not on first glance. New type of error. Could you please do the following: - Also post the grenepipe snakemake log file here (in logs/snakemake), as that contains additional system information, as well as the trimmomatic logs in logs/trimming. Furthermore, if you are running this on a cluster with slurm, also the slurm log files, both of the main snakemake instance (on the head/login node) and the trimmomatic slurm log. See here <https://github.com/moiexpositoalonsolab/grenepipe/wiki/Cluster-and-Profiles#troubleshooting> for details on that. - Try running it with more memory, just to see if that is the reason. If you are using slurm, that means editing the slurm config, see here <https://github.com/moiexpositoalonsolab/grenepipe/wiki/Cluster-and-Profiles#running-grenepipe-on-a-slurm-cluster> . - Try running it manually, to see if this is indeed just within trimmomatic itself, or somehow based on interaction with snakemake or conda. The command line for that is at the beginning of the error logs you posted, in Summary. There is a weird memory contraint there (-Xmx164M) which might cause this. Try -Xmx10G or something like that instead. Let's see if any of that yields any further insights :-) Cheers and so long Lucas — Reply to this email directly, view it on GitHub <#59 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEHUDFPBZWUSCFPMBCQ2HSD2GNV5LAVCNFSM6AAAAABT6D3ZQKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJWGA3DCMBWGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[lczech]

Hey Josh,

seems that email attachments are not posted on GitHub. Can you please try again here. Thanks!

As for the new runs: Sounds good, let me know how those work out.

Cheers
Lucas

[jfaberha]

Hey Josh,

seems that email attachments are not posted on GitHub. Can you please try again here. Thanks!

As for the new runs: Sounds good, let me know how those work out.

Cheers Lucas

Updated, thanks.

[lczech]

Okay, thanks!

So, the trimmomatic log says:

Exception in thread "pool-1-thread-2" java.lang.AbstractMethodError: Receiver class Ljdk.internal.vm.FillerArray; does not define or inherit an implementation of the resolved method 'abstract java.lang.invoke.MethodType accessModeTypeUncached(java.lang.invoke.VarHandle$AccessType)' of abstract class java.lang.invoke.VarHandle.

which seems very much like this is an error in trimmomatic itself, coming from an implementation bug on their end. Unless I miss something, there is nothing I can do as far as grenepipe is concerned (except for updating trimmomatic once they have fixed this). I'd recommend to post this to the trimmomatic GitHub repo instead.

If you think this is indeed an issue with grenepipe, let me know - we can wait for your current tests before closing this issue.

Cheers
Lucas

[jfaberha]

Good to know, I'll see what I can do from the trimmomatic side of things and keep you posted on these new grenepipe run iterations. Thanks for the help.