Hello - just trying to see if there's any chance I can get metabeat running on my university's shared computing cluster. We are running apptainer which can pull and run docker images. So running this...
module load apptainer/1.2.5
apptainer pull docker://chrishah/metabeat
apptainer exec metabeat_latest.sif /usr/bin/metaBEAT_global.py -h
... gets me the full help documentation. Nice!
However, running a simple test trim fails, and this at least initially seems to be because it is trying to access /usr/bin/user_email.txt (where /usr/bin is a server-level folder that I do not have write access for). I am trying to bypass this by supplying an email address using -@, but even when I do so metabeat still seems to be trying to access the file in /usr/bin, since I get the message:
You have specified: 'xxx@gmail.com'
Traceback (most recent call last):
File "/usr/bin/metaBEAT_global.py", line 1764, in <module>
Entrez.email = check_email(mail = Entrez.email)#mail=Entrez.email)
File "/usr/bin/metaBEAT_global.py", line 638, in check_email
FH = open(os.path.dirname(sys.argv[0])+'/user_email.txt','w')
IOError: [Errno 30] Read-only file system: '/usr/bin/user_email.txt'
This seems unnecessary if I am supplying the email with the -@ flag. If this one instance can be fixed/worked around then it's possible I could get it working on the shared server. However, if other functionalities of metabeat rely on accessing/modifying potentially write-protected files then it might just be impossible to implement on a shared server without gut renovation (in which case I think I should just give up and move on to a different pipeline). Any insight into this would be helpful - thanks!
Hello - just trying to see if there's any chance I can get metabeat running on my university's shared computing cluster. We are running apptainer which can pull and run docker images. So running this...
... gets me the full help documentation. Nice!
However, running a simple test trim fails, and this at least initially seems to be because it is trying to access /usr/bin/user_email.txt (where /usr/bin is a server-level folder that I do not have write access for). I am trying to bypass this by supplying an email address using -@, but even when I do so metabeat still seems to be trying to access the file in /usr/bin, since I get the message:
This seems unnecessary if I am supplying the email with the -@ flag. If this one instance can be fixed/worked around then it's possible I could get it working on the shared server. However, if other functionalities of metabeat rely on accessing/modifying potentially write-protected files then it might just be impossible to implement on a shared server without gut renovation (in which case I think I should just give up and move on to a different pipeline). Any insight into this would be helpful - thanks!