FLAMES path

[vsuppiyar]

Hi all,

I am new to FLAMES and try to run it on the test data on the cluster. I have minimap2, k8 and samtools installed in a separate conda environment called flames.

In a bash script, I activate the conda environment "flames" first and submit the RScript as described in the bioconductor vignette (https://bioconductor.org/packages/release/bioc/vignettes/FLAMES/inst/doc/FLAMES_vignette.html) as a job to the cluster.

However, when the function

sce <- sc_long_pipeline(annotation = annot, fastq = fastq, genome_fa = genome_fa, outdir = outdir, config_file = config_file, expect_cell_number = 10)

is called the pipeline fails with the message

[1] "/home/user/.cache/R/basilisk/1.16.0/FLAMES/1.10.0/flames_env/bin"
NULL

Error in path.expand(path) : invalid 'path' argument

I assume it's related to how the flames_env is created on the cluster as described here https://github.com/mritchielab/FLAMES/blob/devel/R/basilisk.R or how it's used as in here https://github.com/mritchielab/FLAMES/blob/d4727af4138ccc014d0a13f5b9ea91d1083016db/R/BLAZE_demultiplexing.R#L68

Any ideas how to solve the issue?

Thanks!

[ChangqingW]

basilisk also creates a conda environment, but I thought nested conda environments are fine. If you do BiocManager::install("mritchielab/FLAMES"), and instead of running from within a conda env, just supply path to minimap2 as an argument sc_long_pipeline(..., minimap2 = '...', k8 = '...') (leave out samtools for now), that should rule out problems of nested conda envs.

[ChangqingW]

Could you also post output of traceback() after the error? Might also help if you do debug(path.expand) or debug(reticulate::import) and see what the path value is.

[vsuppiyar]

@ChangqingW Hi, thanks for your reply. Much appreciated. Your suggested workaround worked. I've just reinstalled the FLAMES package and removed any locked libraries. However it stops now after the alignment at the "Reading Gene Annotations" step.

*** Error in `/software/r/4.4.0/lib64/R/bin/exec/R': free(): invalid pointer: 0x0000000037a30d78 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x81329)[0x2b167f785329]
/home/user/r_libs/FLAMES/libs/FLAMES.so(_Z31exception_to_condition_templateISt9exceptionEP7SEXPRECRKT_b+0x1da)[0x2b16abe49230]
/home/user/r_libs/FLAMES/libs/FLAMES.so(_Z24exception_to_r_conditionRKSt9exception+0x1d)[0x2b16abe47827]
/home/user/r_libs/FLAMES/libs/FLAMES.so(_FLAMES_find_isoform_multithread+0x513)[0x2b16abe44287]
/software/r/4.4.0/lib64/R/lib/libR.so(+0x105f63)[0x2b167ed3bf63]
/software/r/4.4.0/lib64/R/lib/libR.so(+0x14a0ab)[0x2b167ed800ab]
/software/r/4.4.0/lib64/R/lib/libR.so(+0x1569de)[0x2b167ed8c9de]
/software/r/4.4.0/lib64/R/lib/libR.so(Rf_eval+0x173)[0x2b167ed8cca3]
/software/r/4.4.0/lib64/R/lib/libR.so(+0x158bab)[0x2b167ed8ebab]
/software/r/4.4.0/lib64/R/lib/libR.so(+0x15987d)[0x2b167ed8f87d]
/software/r/4.4.0/lib64/R/lib/libR.so(+0x15f623)[0x2b167ed95623]
/software/r/4.4.0/lib64/R/lib/libR.so(Rf_eval+0x299)[0x2b167ed8cdc9]
/software/r/4.4.0/lib64/R/lib/libR.so(+0x15c76a)[0x2b167ed9276a]
/software/r/4.4.0/lib64/R/lib/libR.so(Rf_eval+0x51d)[0x2b167ed8d04d]
/software/r/4.4.0/lib64/R/lib/libR.so(Rf_ReplIteration+0x252)[0x2b167edc40e2]
/software/r/4.4.0/lib64/R/lib/libR.so(+0x18e451)[0x2b167edc4451]
/software/r/4.4.0/lib64/R/lib/libR.so(run_Rmainloop+0x48)[0x2b167edc44e8]
/software/r/4.4.0/lib64/R/bin/exec/R(main+0x1b)[0x40075b]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x2b167f726555]
/software/r/4.4.0/lib64/R/bin/exec/R[0x40078b]

[ChangqingW]

Might be issues with our new C++ implementation for isoform identification. @OliverVoogd You could use the legacy python implementation by setting multithread_isoform_identification to false in the config file.