Updating FCS/FCSGX #52
Comments
|
Mahesh has done this and also included code for generating a ramdisk for the database. Spoken to @muffato about how we can best utilise this. |
|
Here is how I suggest patching the fcs-gx nf-core module now that we have the database on all nodes (under diff --git a/modules/nf-core/fcsgx/rungx/main.nf b/modules/nf-core/fcsgx/rungx/main.nf
index af6411aeb..0dd27084f 100644
--- a/modules/nf-core/fcsgx/rungx/main.nf
+++ b/modules/nf-core/fcsgx/rungx/main.nf
@@ -25,12 +25,8 @@ process FCSGX_RUNGX {
script:
def args = task.ext.args ?: ''
def prefix = task.ext.prefix ?: "${meta.id}"
- def mv_database_to_ram = ramdisk_path ? "rclone copy $gxdb $ramdisk_path/$task.index/" : ''
- def database = ramdisk_path ? "$ramdisk_path/$task.index/" : gxdb // Use task.index to make memory location unique
+ def database = ramdisk_path ?: gxdb
"""
- # Copy DB to RAM-disk when supplied. Otherwise, the tool is very slow.
- $mv_database_to_ram
-
export GX_NUM_CORES=${task.cpus}
run_gx.py \\
--fasta ${fasta} \\ |
|
@DLBPointon : on the tol22 farm, on all the nodes named |
|
Thanks muffato, I have it running pretty happily on my end now. Only warning I'm getting is: These are Ram disk alternatives, I wonder if internally it doesn't draw a distinction between solid-state and spinning-rust? and solid-state is ok really. |
|
Since the migration to tol22/farm22, |
|
Ah i see ok, Yes it uses vmtouch to load into memory. However, that doesn't seem to happen unless I'm reading this wrong. This is perhaps a question for the FCSGX team though |
|
Oh, that's weird. I'll run some tests as well |
|
Hi @muffato |
Description of feature
I'm updating the fcs/fcsgx module on nf-core.
This will move it from v0.4.0 to v0.5.4
See: nf-core/modules#6036
The text was updated successfully, but these errors were encountered: