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
We'd like to be able to install this software on our HPC infrastructure and make it available to all users but as it stands that's not possible, the two hurdles being:
The executable assumes that the two directories input/ and mappability/ are co-located with it, and writeable by the end user(s). This isn't compatible with a multi-user system where typically the executable will be in a read-only bin/ directory and input data location will vary by user.
There's no install target in the top-level makefile so there's no simple method to customize the location of the executable and its libraries, in particular the linked bamtools library
Thank you; our users would be appreciative!
The text was updated successfully, but these errors were encountered:
Since this software is only intended to be run once per organism, we haven't felt the need to install it on HPC infrastructure. Instead, you most users simply download the required BED files from our repository and use them in their own workflows or software pipelines. It may be that those wanting to use the blacklist are just looking for those BED files.
@delocalizer I have a similar use case, where I run it on HPC infrastructure for species without public blacklists. I've had decent luck using conda for managing Umap and ENCODE Blacklist installations.
I'd also advocate for HPC support, as I run it more than once per organism as more data becomes available.
@mrendleman that's pretty much what our users have too - genomes and input datasets that may not be shareable, plus input datasets that may evolve over time. Having them each install their own conda env is a reasonable workaround for now.
We'd like to be able to install this software on our HPC infrastructure and make it available to all users but as it stands that's not possible, the two hurdles being:
input/
andmappability/
are co-located with it, and writeable by the end user(s). This isn't compatible with a multi-user system where typically the executable will be in a read-onlybin/
directory and input data location will vary by user.install
target in the top-level makefile so there's no simple method to customize the location of the executable and its libraries, in particular the linked bamtools libraryThank you; our users would be appreciative!
The text was updated successfully, but these errors were encountered: