404
+ +Page not found
+ + +diff --git a/.nojekyll b/.nojekyll new file mode 100644 index 0000000..e69de29 diff --git a/404.html b/404.html new file mode 100644 index 0000000..d09fdb7 --- /dev/null +++ b/404.html @@ -0,0 +1,139 @@ + + +
+ + + + +Page not found
+ + +When developing R scripts for single-cell sequencing data analysis, utilizing Docker containers offers a streamlined and reproducible environment. This documentation outlines the process of developing R scripts within a Docker container, leveraging JupyterLab for efficient coding and visualization.
+If the goal is to develop an R script named sc_singleR.prod.R
, we create two files:
sc_seurat_opt.R # https://github.com/CCRSF-IFX/SF_sc-smk-wl/blob/main/scripts/rna/sc_singleR_opt.R
+sc_singleR.ipynb # https://github.com/CCRSF-IFX/SF_sc-smk-wl/blob/main/scripts/rna/sc_singleR.ipynb
+
+script_path = getwd() # %exclude_jupyterlab%
+script_path # %exclude_jupyterlab%
+
+sc_singleR_opt.R
for command line options Inside the notebook, we use the cell below to utilize sc_seurat_opt.R
to read the command line options and save the information in an RDS file named opt.rds
.
system(paste0('Rscript ', script_path, # %exclude_jupyterlab%
+ '/sc_singleR_opt.R --genome="hg38" --markerList="/Volumes/ccrsf-ifx/Software/scripts/bin/currentsnake/single_cell/gene_lists/human_gene_list.csv" --outdir="/Volumes/ccrsf-static/Analysis/xies4/github_repos/pipeline_dev_test/singleR" --rds="/Volumes/ccrsf-static/Analysis/xies4/github_repos/pipeline_dev_test/test_dir/seur_10x_cluster_object.rds"'), # %exclude_jupyterlab%
+ intern = T) # %exclude_jupyterlab%
+
+After capturing the options, read them using readRDS()
and proceed with the main code:
opt = readRDS("/Volumes/ccrsf-static/Analysis/xies4/github_repos/pipeline_dev_test/singleR/opt.rds") # %exclude_jupyterlab%
+# main code goes here
+
+sc_singleR.prod.R
Combine the necessary scripts and exclude irrelevant lines marked with exclude_jupyterlab
to create the production script:
notebook_prefix = "sc_singleR" # %exclude_jupyterlab%
+notebook_name = paste0(notebook_prefix, ".ipynb") # %exclude_jupyterlab%
+notebook_r = paste0(script_path, "/", paste0(notebook_prefix, ".r")) # %exclude_jupyterlab%
+notebook_path = paste0(script_path, "/", notebook_name) # %exclude_jupyterlab%
+opt_name = paste0(script_path, "/", sub(".ipynb", "_opt.R", notebook_name)) # %exclude_jupyterlab%
+output = paste0(script_path, "/", sub(".ipynb", ".prod.R", notebook_name)) # %exclude_jupyterlab%
+cmd1 = paste0("jupyter nbconvert --to script --output ", # %exclude_jupyterlab%
+ notebook_prefix, ' ', notebook_path, "> /dev/null 2>&1 ") # %exclude_jupyterlab%
+cmd1 # %exclude_jupyterlab%
+system(cmd1, intern = TRUE) # %exclude_jupyterlab%
+cmd2 = paste0('cat ', opt_name, ' ', notebook_r, # %exclude_jupyterlab%
+ ' |grep -v exclude_jupyterlab > ', output, ' 2>&1') # %exclude_jupyterlab%
+cmd2 # %exclude_jupyterlab%
+system(cmd2, intern = T) # %exclude_jupyterlab%
+system(paste0("rm ", notebook_r)) # %exclude_jupyterlab%
+
+
+ Docker is not available on FRCE (or any HPC) for a user because docker requires sudo permission.
+But we can run use docker on our own laptop or VM in which we have been granted the root access.
+Common command lines used to create and test an image:
+## passwd is the same as FRCE password
+docker login -u ccrsfifx
+docker build
+docker tag
+docker push
+docker run
+docker images
+docker container ls
+
+Command lines for creating and pushing images to Docker hub
+docker build -t sc-smk-wl -f Dockerfile .
+docker tag sc-smk-wl:latest ccrsfifx/sc-smk-wl:r1.0.0
+docker push ccrsfifx/sc-smk-wl:r1.0.0
+
+To test the image, we can create a container using the image we have built above:
+docker run -p 8888:8888 -v /Volumes/:/Volumes/ -t -d --name Renv sc-smk-wl:latest
+
+Because the image above is built for processing single cell RNA-seq data, we included all the R packages needed:
+Seurat
+SingleR
+celldex
+scater
+etc
+
+Then we can aunch a Bash shell inside the container:
+docker exec -it Renv bash
+
+In the container, we can lauch jupyter lab and test the R code.
+ +A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings.
+Docker containers are built from images, which are read-only templates containing the application and its dependencies. Images are defined using a Dockerfile, which specifies the configuration and steps needed to create the image.
+Once an image is created, it can be instantiated into one or more containers. Each container runs in its own isolated environment but shares the same underlying host operating system with other containers. This allows for efficient resource utilization and easy scaling of applications.
+A container is a technology that provides a consistent computational environment and enables reproducibility, scalability, and security when developing NGS bioinformatics analysis pipelines. Containers can increase the bioinformatics team's productivity by automating and simplifying the maintenance of complex bioinformatics resources, as well as facilitate validation, version control, and documentation necessary for clinical laboratory regulatory compliance.
+VMs are great at providing full process isolation for applications: there are very few ways a problem in the host operating system can affect the software running in the guest operating system, and vice-versa. But this isolation comes at great cost — the computational overhead spent virtualizing hardware for a guest OS to use is substantial.
+Containers take a different approach: by leveraging the low-level mechanics of the host operating system, containers provide most of the isolation of virtual machines at a fraction of the computing power.
+ +SF_biocontainer is a github repo with the Dockerfile used to build containers for CCRSF pipelines.
+Many of the popular tools have been containerized by the community, including Biocontainer community and different institutes. These resources can be found either on Docker hub or Quay
+If the tool we want to use is not containerized before, we can build the container ourselves and deposite the image on Docker hub. Here is a diagram to show the current workflow used for containerization:
+ +CCRSFIFX maintained images can be found here.
+ +To be added
+ +To use container in the snakemake pipeline, we can define a container for each rule to use:
+rule seurat_proc:
+ input:
+ h5 = rules.count.output
+ params:
+ fil_mtx = os.path.join(analysis, "{sample}/outs/filtered_feature_bc_matrix/"),
+ outdir = os.path.join(analysis, "{sample}/seurat/"),
+ log:
+ os.path.join(analysis, "{sample}/seurat/seurat.log")
+ output:
+ seur = os.path.join(analysis, "{sample}/seurat/seur_10x_cluster_object.rds")
+ container:
+ "docker://ccrsfifx/sc-smk-wl:r1.0.0"
+ shell:
+ """
+Rscript {analysis}/workflow/scripts/rna/sc_seurat.prod.R --genome={config.ref} --data.dir={params.fil_mtx} --outdir={params.outdir} > {log} 2>&1
+"""
+
+
+ ' + escapeHtml(summary) +'
' + noResultsText + '
'); + } +} + +function doSearch () { + var query = document.getElementById('mkdocs-search-query').value; + if (query.length > min_search_length) { + if (!window.Worker) { + displayResults(search(query)); + } else { + searchWorker.postMessage({query: query}); + } + } else { + // Clear results for short queries + displayResults([]); + } +} + +function initSearch () { + var search_input = document.getElementById('mkdocs-search-query'); + if (search_input) { + search_input.addEventListener("keyup", doSearch); + } + var term = getSearchTermFromLocation(); + if (term) { + search_input.value = term; + doSearch(); + } +} + +function onWorkerMessage (e) { + if (e.data.allowSearch) { + initSearch(); + } else if (e.data.results) { + var results = e.data.results; + displayResults(results); + } else if (e.data.config) { + min_search_length = e.data.config.min_search_length-1; + } +} + +if (!window.Worker) { + console.log('Web Worker API not supported'); + // load index in main thread + $.getScript(joinUrl(base_url, "search/worker.js")).done(function () { + console.log('Loaded worker'); + init(); + window.postMessage = function (msg) { + onWorkerMessage({data: msg}); + }; + }).fail(function (jqxhr, settings, exception) { + console.error('Could not load worker.js'); + }); +} else { + // Wrap search in a web worker + var searchWorker = new Worker(joinUrl(base_url, "search/worker.js")); + searchWorker.postMessage({init: true}); + searchWorker.onmessage = onWorkerMessage; +} diff --git a/search/search_index.json b/search/search_index.json new file mode 100644 index 0000000..1b0db85 --- /dev/null +++ b/search/search_index.json @@ -0,0 +1 @@ +{"config":{"indexing":"full","lang":["en"],"min_search_length":3,"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"SF_biocontainer SF_biocontainer is a github repo with the Dockerfile used to build containers for CCRSF pipelines. Publicly available images Many of the popular tools have been containerized by the community, including Biocontainer community and different institutes. These resources can be found either on Docker hub or Quay CCRSF maintained images If the tool we want to use is not containerized before, we can build the container ourselves and deposite the image on Docker hub. Here is a diagram to show the current workflow used for containerization: CCRSFIFX maintained images can be found here .","title":"Containerization"},{"location":"#sf_biocontainer","text":"SF_biocontainer is a github repo with the Dockerfile used to build containers for CCRSF pipelines.","title":"SF_biocontainer"},{"location":"#publicly-available-images","text":"Many of the popular tools have been containerized by the community, including Biocontainer community and different institutes. These resources can be found either on Docker hub or Quay","title":"Publicly available images"},{"location":"#ccrsf-maintained-images","text":"If the tool we want to use is not containerized before, we can build the container ourselves and deposite the image on Docker hub. Here is a diagram to show the current workflow used for containerization: CCRSFIFX maintained images can be found here .","title":"CCRSF maintained images"},{"location":"dev_w_docker/","text":"When developing R scripts for single-cell sequencing data analysis, utilizing Docker containers offers a streamlined and reproducible environment. This documentation outlines the process of developing R scripts within a Docker container, leveraging JupyterLab for efficient coding and visualization. If the goal is to develop an R script named sc_singleR.prod.R , we create two files: sc_seurat_opt.R # https://github.com/CCRSF-IFX/SF_sc-smk-wl/blob/main/scripts/rna/sc_singleR_opt.R sc_singleR.ipynb # https://github.com/CCRSF-IFX/SF_sc-smk-wl/blob/main/scripts/rna/sc_singleR.ipynb Record the script path: script_path = getwd() # %exclude_jupyterlab% script_path # %exclude_jupyterlab% Invoke sc_singleR_opt.R for command line options Inside the notebook, we use the cell below to utilize sc_seurat_opt.R to read the command line options and save the information in an RDS file named opt.rds . system(paste0('Rscript ', script_path, # %exclude_jupyterlab% '/sc_singleR_opt.R --genome=\"hg38\" --markerList=\"/Volumes/ccrsf-ifx/Software/scripts/bin/currentsnake/single_cell/gene_lists/human_gene_list.csv\" --outdir=\"/Volumes/ccrsf-static/Analysis/xies4/github_repos/pipeline_dev_test/singleR\" --rds=\"/Volumes/ccrsf-static/Analysis/xies4/github_repos/pipeline_dev_test/test_dir/seur_10x_cluster_object.rds\"'), # %exclude_jupyterlab% intern = T) # %exclude_jupyterlab% Write the main code After capturing the options, read them using readRDS() and proceed with the main code: opt = readRDS(\"/Volumes/ccrsf-static/Analysis/xies4/github_repos/pipeline_dev_test/singleR/opt.rds\") # %exclude_jupyterlab% # main code goes here Generate production script: sc_singleR.prod.R Combine the necessary scripts and exclude irrelevant lines marked with exclude_jupyterlab to create the production script: notebook_prefix = \"sc_singleR\" # %exclude_jupyterlab% notebook_name = paste0(notebook_prefix, \".ipynb\") # %exclude_jupyterlab% notebook_r = paste0(script_path, \"/\", paste0(notebook_prefix, \".r\")) # %exclude_jupyterlab% notebook_path = paste0(script_path, \"/\", notebook_name) # %exclude_jupyterlab% opt_name = paste0(script_path, \"/\", sub(\".ipynb\", \"_opt.R\", notebook_name)) # %exclude_jupyterlab% output = paste0(script_path, \"/\", sub(\".ipynb\", \".prod.R\", notebook_name)) # %exclude_jupyterlab% cmd1 = paste0(\"jupyter nbconvert --to script --output \", # %exclude_jupyterlab% notebook_prefix, ' ', notebook_path, \"> /dev/null 2>&1 \") # %exclude_jupyterlab% cmd1 # %exclude_jupyterlab% system(cmd1, intern = TRUE) # %exclude_jupyterlab% cmd2 = paste0('cat ', opt_name, ' ', notebook_r, # %exclude_jupyterlab% ' |grep -v exclude_jupyterlab > ', output, ' 2>&1') # %exclude_jupyterlab% cmd2 # %exclude_jupyterlab% system(cmd2, intern = T) # %exclude_jupyterlab% system(paste0(\"rm \", notebook_r)) # %exclude_jupyterlab%","title":"Develop R scripts in the container"},{"location":"docker/","text":"Create images using Docker Docker is not available on FRCE (or any HPC) for a user because docker requires sudo permission. But we can run use docker on our own laptop or VM in which we have been granted the root access. Common command lines used to create and test an image: ## passwd is the same as FRCE password docker login -u ccrsfifx docker build docker tag docker push docker run docker images docker container ls An example of creating customized image for single cell data Command lines for creating and pushing images to Docker hub docker build -t sc-smk-wl -f Dockerfile . docker tag sc-smk-wl:latest ccrsfifx/sc-smk-wl:r1.0.0 docker push ccrsfifx/sc-smk-wl:r1.0.0 To test the image, we can create a container using the image we have built above: docker run -p 8888:8888 -v /Volumes/:/Volumes/ -t -d --name Renv sc-smk-wl:latest Because the image above is built for processing single cell RNA-seq data, we included all the R packages needed: Seurat SingleR celldex scater etc Then we can aunch a Bash shell inside the container: docker exec -it Renv bash In the container, we can lauch jupyter lab and test the R code.","title":"Create image/container"},{"location":"docker/#create-images-using-docker","text":"Docker is not available on FRCE (or any HPC) for a user because docker requires sudo permission. But we can run use docker on our own laptop or VM in which we have been granted the root access. Common command lines used to create and test an image: ## passwd is the same as FRCE password docker login -u ccrsfifx docker build docker tag docker push docker run docker images docker container ls","title":"Create images using Docker"},{"location":"docker/#an-example-of-creating-customized-image-for-single-cell-data","text":"Command lines for creating and pushing images to Docker hub docker build -t sc-smk-wl -f Dockerfile . docker tag sc-smk-wl:latest ccrsfifx/sc-smk-wl:r1.0.0 docker push ccrsfifx/sc-smk-wl:r1.0.0 To test the image, we can create a container using the image we have built above: docker run -p 8888:8888 -v /Volumes/:/Volumes/ -t -d --name Renv sc-smk-wl:latest Because the image above is built for processing single cell RNA-seq data, we included all the R packages needed: Seurat SingleR celldex scater etc Then we can aunch a Bash shell inside the container: docker exec -it Renv bash In the container, we can lauch jupyter lab and test the R code.","title":"An example of creating customized image for single cell data"},{"location":"general-questions/","text":"FAQ What is Docker container? A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings. Docker containers are built from images, which are read-only templates containing the application and its dependencies. Images are defined using a Dockerfile, which specifies the configuration and steps needed to create the image. Once an image is created, it can be instantiated into one or more containers. Each container runs in its own isolated environment but shares the same underlying host operating system with other containers. This allows for efficient resource utilization and easy scaling of applications. Why do we use container? A container is a technology that provides a consistent computational environment and enables reproducibility, scalability, and security when developing NGS bioinformatics analysis pipelines. Containers can increase the bioinformatics team's productivity by automating and simplifying the maintenance of complex bioinformatics resources, as well as facilitate validation, version control, and documentation necessary for clinical laboratory regulatory compliance. What's the difference between container and VM? VMs are great at providing full process isolation for applications: there are very few ways a problem in the host operating system can affect the software running in the guest operating system, and vice-versa. But this isolation comes at great cost \u2014 the computational overhead spent virtualizing hardware for a guest OS to use is substantial. Containers take a different approach: by leveraging the low-level mechanics of the host operating system, containers provide most of the isolation of virtual machines at a fraction of the computing power.","title":"General Questions"},{"location":"general-questions/#faq","text":"","title":"FAQ"},{"location":"general-questions/#what-is-docker-container","text":"A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings. Docker containers are built from images, which are read-only templates containing the application and its dependencies. Images are defined using a Dockerfile, which specifies the configuration and steps needed to create the image. Once an image is created, it can be instantiated into one or more containers. Each container runs in its own isolated environment but shares the same underlying host operating system with other containers. This allows for efficient resource utilization and easy scaling of applications.","title":"What is Docker container?"},{"location":"general-questions/#why-do-we-use-container","text":"A container is a technology that provides a consistent computational environment and enables reproducibility, scalability, and security when developing NGS bioinformatics analysis pipelines. Containers can increase the bioinformatics team's productivity by automating and simplifying the maintenance of complex bioinformatics resources, as well as facilitate validation, version control, and documentation necessary for clinical laboratory regulatory compliance.","title":"Why do we use container?"},{"location":"general-questions/#whats-the-difference-between-container-and-vm","text":"VMs are great at providing full process isolation for applications: there are very few ways a problem in the host operating system can affect the software running in the guest operating system, and vice-versa. But this isolation comes at great cost \u2014 the computational overhead spent virtualizing hardware for a guest OS to use is substantial. Containers take a different approach: by leveraging the low-level mechanics of the host operating system, containers provide most of the isolation of virtual machines at a fraction of the computing power.","title":"What's the difference between container and VM?"},{"location":"license/","text":"To be added","title":"License"},{"location":"pipeline_containerization/","text":"To use container in the snakemake pipeline, we can define a container for each rule to use: rule seurat_proc: input: h5 = rules.count.output params: fil_mtx = os.path.join(analysis, \"{sample}/outs/filtered_feature_bc_matrix/\"), outdir = os.path.join(analysis, \"{sample}/seurat/\"), log: os.path.join(analysis, \"{sample}/seurat/seurat.log\") output: seur = os.path.join(analysis, \"{sample}/seurat/seur_10x_cluster_object.rds\") container: \"docker://ccrsfifx/sc-smk-wl:r1.0.0\" shell: \"\"\" Rscript {analysis}/workflow/scripts/rna/sc_seurat.prod.R --genome={config.ref} --data.dir={params.fil_mtx} --outdir={params.outdir} > {log} 2>&1 \"\"\"","title":"Build Snakemake pipeline with Singularity"},{"location":"ref/","text":"Reference Singularity User Guide: link Uni.lu High Performance Computing (HPC) Tutorials: link Containers in Bioinformatics: Applications, Practical Considerations, and Best Practices in Molecular Pathology: link Docker for beginners: link","title":"Reference"},{"location":"ref/#reference","text":"Singularity User Guide: link Uni.lu High Performance Computing (HPC) Tutorials: link Containers in Bioinformatics: Applications, Practical Considerations, and Best Practices in Molecular Pathology: link Docker for beginners: link","title":"Reference"},{"location":"snakemake_opt4singularity/","text":"The configuration of snakemake command for singularity is recommended to be set up in profile/slurm/config.v8+.yaml : use-singularity: True singularity-args: ' \"--cleanenv --no-home -B /scratch/ccrsf_scratch -B /mnt/ccrsf-static -B /mnt/ccrsf-ifx -B /mnt/ccrsf-raw -B /mnt/ccrsf-active\" ' The option -B is used to bind the corresponding storage space into the container so that the files from scratch/Qumulo can be accessible from inside the container. --no-home : no host $HOME directory mounting. Auto-binding feature: By default, Singularity automatically binds several directories (e.g.: $HOME , $PWD ) and in particular it binds the home folder of the host. This features simplifies the usage of Singularity for the users, however it can also lead to unexpected behaviours and frustration. For example, if you have different python packages installed in your host home directory and in the container the host packages maybe used instead f the container ones. To avoid this issue, --no-home is used. The --cleanenv option is used to exclude passing EBV variables frin the host into the container. Similar to --no-home , --cleanenv is used to disable Singularity passing host environment variables ( $PATH , $LD_LIBRARY_PATH , etc) to the container.","title":"Snakemake options for containerization"},{"location":"troubleshooting/","text":"Troubleshooting Issue with cache folders and temporary folders To make download of layers for build and pull faster and less redundant, singularity use a caching strategy. By default, the Singularity software will create a set of folders in your $HOME directory for docker layers and metadata, respectively: $HOME/.singularity Singularity also uses some temporary directories to build the squashfs filesystem, so this temp space needs to be large enough to hold the entire resulting Singularity image. By default this happens in /tmp but can be overridden by setting SINGULARITY_TMPDIR to the full path where you want the squashfs temp files to be stored. In many HPC platform, limited space is assigned to $HOME . So to make the pipeline more robust, it is recommended to set SINGULARITY_CACHEDIR to make sure enough space can be used. BoltDB Corruption Errors\uf0c1 The library that SingularityCE uses to retrieve and cache Docker/OCI layers keeps track of them using a single-file database. If your home directory is on a network filesystem which experiences interruptions, or you run out of storage, it is possible for this database to become inconsistent. If you observe error messages that mention github.com/etcd-io/bbolt when trying to run SingularityCE, then you should remove the database file: rm ~/.local/share/containers/cache/blob-info-cache-v1.boltdb Here are the discussions useful for this issue: https://github.com/apptainer/singularity/issues/5329#issuecomment-637595826 https://docs.sylabs.io/guides/main/user-guide/build_env.html#boltdb-corruption-errors https://github.com/apptainer/singularity/issues/5329#issuecomment-1062000005 Issue with NIH VPN When the program inside a container needs to connect to a database via API or download some data, the error message below might be threwn out: SSL certificate problem: self signed certificate in certificate chain This is related to VPN setting. Disabling VPN solved the issue. Detailed reason not sure.","title":"Troubleshooting"},{"location":"troubleshooting/#troubleshooting","text":"","title":"Troubleshooting"},{"location":"troubleshooting/#issue-with-cache-folders-and-temporary-folders","text":"To make download of layers for build and pull faster and less redundant, singularity use a caching strategy. By default, the Singularity software will create a set of folders in your $HOME directory for docker layers and metadata, respectively: $HOME/.singularity Singularity also uses some temporary directories to build the squashfs filesystem, so this temp space needs to be large enough to hold the entire resulting Singularity image. By default this happens in /tmp but can be overridden by setting SINGULARITY_TMPDIR to the full path where you want the squashfs temp files to be stored. In many HPC platform, limited space is assigned to $HOME . So to make the pipeline more robust, it is recommended to set SINGULARITY_CACHEDIR to make sure enough space can be used.","title":"Issue with cache folders and temporary folders"},{"location":"troubleshooting/#boltdb-corruption-errors","text":"The library that SingularityCE uses to retrieve and cache Docker/OCI layers keeps track of them using a single-file database. If your home directory is on a network filesystem which experiences interruptions, or you run out of storage, it is possible for this database to become inconsistent. If you observe error messages that mention github.com/etcd-io/bbolt when trying to run SingularityCE, then you should remove the database file: rm ~/.local/share/containers/cache/blob-info-cache-v1.boltdb Here are the discussions useful for this issue: https://github.com/apptainer/singularity/issues/5329#issuecomment-637595826 https://docs.sylabs.io/guides/main/user-guide/build_env.html#boltdb-corruption-errors https://github.com/apptainer/singularity/issues/5329#issuecomment-1062000005","title":"BoltDB Corruption Errors\uf0c1"},{"location":"troubleshooting/#issue-with-nih-vpn","text":"When the program inside a container needs to connect to a database via API or download some data, the error message below might be threwn out: SSL certificate problem: self signed certificate in certificate chain This is related to VPN setting. Disabling VPN solved the issue. Detailed reason not sure.","title":"Issue with NIH VPN"}]} \ No newline at end of file diff --git a/search/worker.js b/search/worker.js new file mode 100644 index 0000000..8628dbc --- /dev/null +++ b/search/worker.js @@ -0,0 +1,133 @@ +var base_path = 'function' === typeof importScripts ? '.' : '/search/'; +var allowSearch = false; +var index; +var documents = {}; +var lang = ['en']; +var data; + +function getScript(script, callback) { + console.log('Loading script: ' + script); + $.getScript(base_path + script).done(function () { + callback(); + }).fail(function (jqxhr, settings, exception) { + console.log('Error: ' + exception); + }); +} + +function getScriptsInOrder(scripts, callback) { + if (scripts.length === 0) { + callback(); + return; + } + getScript(scripts[0], function() { + getScriptsInOrder(scripts.slice(1), callback); + }); +} + +function loadScripts(urls, callback) { + if( 'function' === typeof importScripts ) { + importScripts.apply(null, urls); + callback(); + } else { + getScriptsInOrder(urls, callback); + } +} + +function onJSONLoaded () { + data = JSON.parse(this.responseText); + var scriptsToLoad = ['lunr.js']; + if (data.config && data.config.lang && data.config.lang.length) { + lang = data.config.lang; + } + if (lang.length > 1 || lang[0] !== "en") { + scriptsToLoad.push('lunr.stemmer.support.js'); + if (lang.length > 1) { + scriptsToLoad.push('lunr.multi.js'); + } + if (lang.includes("ja") || lang.includes("jp")) { + scriptsToLoad.push('tinyseg.js'); + } + for (var i=0; i < lang.length; i++) { + if (lang[i] != 'en') { + scriptsToLoad.push(['lunr', lang[i], 'js'].join('.')); + } + } + } + loadScripts(scriptsToLoad, onScriptsLoaded); +} + +function onScriptsLoaded () { + console.log('All search scripts loaded, building Lunr index...'); + if (data.config && data.config.separator && data.config.separator.length) { + lunr.tokenizer.separator = new RegExp(data.config.separator); + } + + if (data.index) { + index = lunr.Index.load(data.index); + data.docs.forEach(function (doc) { + documents[doc.location] = doc; + }); + console.log('Lunr pre-built index loaded, search ready'); + } else { + index = lunr(function () { + if (lang.length === 1 && lang[0] !== "en" && lunr[lang[0]]) { + this.use(lunr[lang[0]]); + } else if (lang.length > 1) { + this.use(lunr.multiLanguage.apply(null, lang)); // spread operator not supported in all browsers: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_operator#Browser_compatibility + } + this.field('title'); + this.field('text'); + this.ref('location'); + + for (var i=0; i < data.docs.length; i++) { + var doc = data.docs[i]; + this.add(doc); + documents[doc.location] = doc; + } + }); + console.log('Lunr index built, search ready'); + } + allowSearch = true; + postMessage({config: data.config}); + postMessage({allowSearch: allowSearch}); +} + +function init () { + var oReq = new XMLHttpRequest(); + oReq.addEventListener("load", onJSONLoaded); + var index_path = base_path + '/search_index.json'; + if( 'function' === typeof importScripts ){ + index_path = 'search_index.json'; + } + oReq.open("GET", index_path); + oReq.send(); +} + +function search (query) { + if (!allowSearch) { + console.error('Assets for search still loading'); + return; + } + + var resultDocuments = []; + var results = index.search(query); + for (var i=0; i < results.length; i++){ + var result = results[i]; + doc = documents[result.ref]; + doc.summary = doc.text.substring(0, 200); + resultDocuments.push(doc); + } + return resultDocuments; +} + +if( 'function' === typeof importScripts ) { + onmessage = function (e) { + if (e.data.init) { + init(); + } else if (e.data.query) { + postMessage({ results: search(e.data.query) }); + } else { + console.error("Worker - Unrecognized message: " + e); + } + }; +} diff --git a/sitemap.xml b/sitemap.xml new file mode 100644 index 0000000..0f8724e --- /dev/null +++ b/sitemap.xml @@ -0,0 +1,3 @@ + +The configuration of snakemake command for singularity is recommended to be set up in profile/slurm/config.v8+.yaml
:
use-singularity: True
+singularity-args: ' "--cleanenv --no-home -B /scratch/ccrsf_scratch -B /mnt/ccrsf-static -B /mnt/ccrsf-ifx -B /mnt/ccrsf-raw -B /mnt/ccrsf-active" '
+
+The option -B
is used to bind the corresponding storage space into the container so that the files from scratch/Qumulo can be accessible from inside the container.
--no-home
: no host $HOME
directory mounting.
++Auto-binding feature: By default, Singularity automatically binds several directories (e.g.:
+$HOME
,$PWD
) and in particular it binds the home folder of the host. This features simplifies the usage of Singularity for the users, however it can also lead to unexpected behaviours and frustration. For example, if you have different python packages installed in your host home directory and in the container the host packages maybe used instead f the container ones. To avoid this issue,--no-home
is used.
The --cleanenv
option is used to exclude passing EBV variables frin the host into the container.
Similar to --no-home
, --cleanenv
is used to disable Singularity passing host environment variables ($PATH
, $LD_LIBRARY_PATH
, etc) to the container.
To make download of layers for build and pull faster and less redundant, singularity
use a caching strategy. By default, the Singularity software will create a set of folders in your $HOME directory for docker layers and metadata, respectively:
$HOME/.singularity
+
+Singularity also uses some temporary directories to build the squashfs filesystem, so this temp space needs to be large enough to hold the entire resulting Singularity image. By default this happens in /tmp but can be overridden by setting SINGULARITY_TMPDIR to the full path where you want the squashfs temp files to be stored.
+In many HPC platform, limited space is assigned to $HOME
. So to make the pipeline more robust, it is recommended to set SINGULARITY_CACHEDIR
to make sure enough space can be used.
The library that SingularityCE uses to retrieve and cache Docker/OCI layers keeps track of them using a single-file database. If your home directory is on a network filesystem which experiences interruptions, or you run out of storage, it is possible for this database to become inconsistent.
+If you observe error messages that mention github.com/etcd-io/bbolt when trying to run SingularityCE, then you should remove the database file:
+rm ~/.local/share/containers/cache/blob-info-cache-v1.boltdb
+
+Here are the discussions useful for this issue:
+https://github.com/apptainer/singularity/issues/5329#issuecomment-637595826 +https://docs.sylabs.io/guides/main/user-guide/build_env.html#boltdb-corruption-errors +https://github.com/apptainer/singularity/issues/5329#issuecomment-1062000005
+When the program inside a container needs to connect to a database via API or download some data, the error message below might be threwn out:
+++SSL certificate problem: self signed certificate in certificate chain
+
This is related to VPN setting. Disabling VPN solved the issue. Detailed reason not sure.
+ +