> For the complete documentation index, see [llms.txt](https://academy.dnanexus.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://academy.dnanexus.com/public-datasets-on-the-dnanexus-platform/molecular-modeling/nf-core-proteinfold.md). # nf-core: Proteinfold ## Necessary Disclaimers and Legal The user is responsible for reviewing and complying with the license requirements of the software, models, and reference databases referenced in this documentation. nf-core/proteinfold v2.0.0 supports multiple structure prediction modes, including AlphaFold2, ColabFold, ESMFold, Boltz, AlphaFold3, HelixFold3, RoseTTAFold-All-Atom, and RoseTTAFold2NA, each governed by independent license terms set by the respective third-party developers. Before use in any commercial or for-profit context, users must independently verify current license terms directly from the original developer's source. In particular: * Commercial use may be restricted at the level of model weights, reference databases, or both, even where the source code itself is permissively licensed * License terms may change over time at the developer's discretion | Prediction Model | Code License | Weight License | Commercial? | | -------------------- | -------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | ----------- | | AlphaFold2 | [Apache 2.0](https://github.com/google-deepmind/alphafold?tab=Apache-2.0-1-ov-file) | [CC BY 4.0](https://github.com/google-deepmind/alphafold?tab=readme-ov-file#model-parameters) | Yes | | ColabFold | [MIT](https://github.com/sokrypton/ColabFold?tab=MIT-1-ov-file) | Relies on AF2 weights (CC BY 4.0) | Yes | | ESMFold | [MIT](https://github.com/facebookresearch/esm?tab=MIT-1-ov-file) | [MIT](https://zenodo.org/records/7566741) | Yes | | Boltz | [MIT](https://github.com/jwohlwend/boltz/?tab=MIT-1-ov-file) | [MIT](https://huggingface.co/boltz-community/boltz-2/tree/main) | Yes | | RoseTTAFold2NA | [MIT](https://github.com/uw-ipd/RoseTTAFold2NA?tab=MIT-1-ov-file) | [Rosetta-DL Software license](https://github.com/RosettaCommons/RoseTTAFold) | No | | RoseTTAFold-All-Atom | [BSD](https://github.com/baker-laboratory/RoseTTAFold-All-Atom/?tab=License-1-ov-file) | [Rosetta-DL Software license](https://github.com/RosettaCommons/RoseTTAFold) | No | | AlphaFold3 | [Apache 2.0](https://github.com/google-deepmind/alphafold3?tab=Apache-2.0-1-ov-file) | [Custom non-commercial](https://github.com/google-deepmind/alphafold3?tab=readme-ov-file) | No | | HelixFold3 | [Non-commercial](https://github.com/PaddlePaddle/PaddleHelix/blob/dev/apps/protein_folding/helixfold3/LICENSE) | [Non-commercial](https://github.com/PaddlePaddle/PaddleHelix/blob/dev/apps/protein_folding/helixfold3/LICENSE) | No | **Note:** * The 2021-07-14 AlphaFold parameters are released under the CC BY-NC 4.0 license, which restricts their use to non-commercial purposes only. We recommend using the alphafold\_params\_2022-12-06 release instead, which is licensed under CC BY 4.0 (permitting commercial use with attribution) and contains the same monomer/pTM weights as the 2021 release. * Some model weights and databases referenced in the [nf-core/proteinfold configuration](https://github.com/nf-core/proteinfold/blob/2.0.0/conf/dbs.config) (e.g., PDB100, HelixFold3, RoseTTAFold) are subject to non-commercial or restricted-use licenses; we did not download these components, and we recommend users verify the applicable license terms before use. Users are responsible for the costs associated with nf-core/proteinfold, protein structure prediction methods, databases, and their storage in their project spaces. Instance type availability and pricing are subject to the contract between the user or the user's organization and DNAnexus. ## Citation for nf-core/proteinfold v2.0.0 nf-core is a community-driven collection of curated bioinformatics pipelines built using Nextflow, providing standardized, scalable, and portable workflows for reproducible analysis across diverse computing environments. Following these standards, nf-core/proteinfold enables state-of-the-art protein structure prediction through optimized Nextflow execution. If you use nf-core/proteinfold, please cite the [pipeline](https://zenodo.org/records/7437038) accordingly. Additional references for integrated tools are listed in the pipeline’s [CITATIONS.md](https://github.com/nf-core/proteinfold/blob/2.0.0/CITATIONS.md). ## Overview of nf-core/proteinfold v2.0.0 pipeline Version 2.0.0 (released on March 27, 2026) is a major release that significantly expands the pipeline compared to v1.1.1, which supported three prediction modes (AlphaFold2, ColabFold, and ESMFold). The new version introduces several key additions and changes: * **5 new prediction modes:** Boltz, AlphaFold3, HelixFold3, RoseTTAFold-All-Atom, and RoseTTAFold2NA, bringing the total to 8 modes. * Of these 8 modes, only AlphaFold2, ColabFold, ESMFold, and Boltz are free for commercial use based on the current licensing of their code, weights, and required reference databases. * **Multi-mode parallel execution:** multiple modes can now be run simultaneously using a comma-separated list (e.g. --mode alphafold2,colabfold,boltz) * **Sample sheet schema:** the input column was renamed from sequence to id. * The pipeline produces an interactive HTML report to visualize structure prediction outputs. * Version 2 supports an optional Foldseek easy-search step on the top-ranked structure per input/mode combination, but this step is disabled by default (skip\_foldseek = true) and is not part of core structure prediction functionality. Foldseek has not been deployed on this DNAnexus platform because of its restricted license. On DNAnexus, we have made the nf-core/proteinfold (version 2.0.0) directly available, together with a CSV Builder for preparing inputs and a full database ( > 4 TB). See the “Where to Access nf-core/proteinfold v2.0.0” section below to start accessing the dataset and the applet. ## Where to access nf-core/proteinfold v2.0.0 The nf-core/proteinfold v2.0.0 folder on DNAnexus is organized as follows: ``` ProteinFold_v2.0.0/ ├── proteinfold_v2.0.0 # Nextflow applet ├── example_parameter_files/ # Example parameter JSON files ├── example_samplesheet_files/ # Example samplesheets ├── example_results/ # Example output ├── references/ # Pre-downloaded reference databases └── soft_configs/ # Resource configuration files ``` **Note on project ID:** Throughout this guide, replace project-xxx with your own DNAnexus project ID. Your project ID can be found on the DNAnexus platform under Project Settings, or by running dx CLI. Note on parameter prefixes: Parameters prefixed with -i (e.g. -ioutdir, -inextflow\_run\_opts) are DNAnexus applet input arguments passed to dx run. Parameters prefixed with -- (e.g. --genome, --fasta) are Nextflow pipeline parameters, typically supplied via a JSON params file or within nextflow\_run\_opts. ## Copying applet and data into a project To use these resources, you have two options: * **Option 1:** Clone the datasets and applet into your own DNAnexus project. Follow the steps below. * **Option 2:** Reference the databases directly from the Public Datasets project, without copying. Our example uses AWS US (East), but the Public Datasets are also available in other regions. Steps to copy data into your own project: 1. Create a new project billed to your organization. See [Setting Up a Project](https://academy.dnanexus.com/overview-of-the-platform/setting-up-a-project) for instructions. 2. Go to the Resources tab and find the project "Public Datasets AWS US East". Navigate to the ProteinFold\_v2.0.0 folder. 3. Select the folders and files you need. 4. Click Copy from the top right menu and select the project you created in Step 1. 5. Go to your project to start running the pipeline. Note: The example\_results/ folder contains output from completed pipeline runs and is provided for reference only. ## Samplesheet input The samplesheet is a .csv file passed to the pipeline via --input. Each row represents one protein sequence to be folded/predicted. There are two required columns: id and fasta. ``` id,fasta T1024,dx://project-xxx:/path/to/T1024.fasta T1026,dx://project-xxx:/path/to/T1026.fasta ``` Each FASTA file should ideally contain only a single protein sequence, unless you are running in multimer mode. If you need to fold multiple sequences individually, you can supply one or more FASTA files containing several sequences using the --split\_fasta parameter. In this case, the pipeline treats every sequence within the file as its own independent entry, folding each one separately and in parallel. ### Using the CSV Builder to prepare your samplesheet Instead of manually writing the samplesheet, you can use the CSV Builder for nf-core/proteinfold, an applet on DNAnexus platform that generates a pipeline-ready samplesheet. It validates your input against the correct schema (id,fasta for v2.0.0), automatically resolves file paths into dx:// URIs, and saves the output directly to your project. Quick steps: 1. Copy the proteinfold\_samplesheet\_builder applet and example dataset into your project (see \[CSV Builder User Guide \] for setup instructions). 2. Launch the applet from the DNAnexus platform. 3. Provide your input using either: * fasta: select one or more FASTA files directly from your project, or * prefilled samplesheet: upload an existing .csv file with sequence names and file references. 4. Select the ProteinFold pipeline version 2.0.0. 5. Set an output samplesheet name and destination, then launch the job. The job typically completes in \~2 minutes. Once done, verify the job status is Done and the output .csv matches the expected schema for version 2.0.0. For detailed setup, input formats, and troubleshooting, refer to the full CSV Builder for nf-core/proteinfold user guide \. ### Example samplesheets Several example samplesheets are provided in the example\_samplesheet\_files/ folder on the platform. ``` example_samplesheet_files/ ├── samplesheet.csv ├── samplesheet_multimer.csv ├── rna_complex_samplesheet.csv ├── samplesheet_single_fasta.csv └── proteinfold_v2.0.0_samplesheet_dx_path.csv ``` Most of these samplesheets reference FASTA files hosted on the [nf-core/test-datasets GitHub repository](https://github.com/nf-core/test-datasets/tree/proteinfold) and are downloaded directly at runtime. These can be used as-is without modifying any paths, making them a convenient option for quickly testing the pipeline. proteinfold\_v2.0.0\_samplesheet\_dx\_path.csv is an example samplesheet showing dx:// paths pointing to files staged on the platform (Public Dataset AWS East project, project-J3JyY6j030gzQypGpk273241). This is an example output generated by the CSV Builder. ## Databases nf-core/proteinfold relies on external reference databases and model parameters to run its supported prediction modes. They are pre-downloaded and arranged on the DNAnexus platform to match the exact structure nf-core/proteinfold expects, so you can skip the download step entirely and point straight to --db parameter, saving significant setup time. The reference databases for this project are organized as follows: ``` ProteinFold_v2.0.0/ └── references/ └── db/ ├── bfd/ ├── colabfold_envdb/ ├── colabfold_uniref30/ ├── mgnify/ ├── params/ ├── pdb70/ ├── pdb_mmcif/ ├── pdb_seqres/ ├── small_bfd/ ├── uniprot/ ├── uniref30/ └── uniref90/ ``` Each mode utilizes a subset of these folders, as detailed in the table below. When running the pipeline, you can use the --db parameter to specify a single parent folder (e.g., db/) instead of defining each folder path individually. | Folder | Used by | | ------------------- | ------------------------------------ | | bfd | AlphaFold2 | | small\_bfd | AlphaFold2 | | uniref90 | AlphaFold2 | | uniref30 | AlphaFold2 | | mgnify | AlphaFold2 | | pdb70 | AlphaFold2 (monomer templates) | | pdb\_mmcif | AlphaFold2 | | pdb\_seqres | AlphaFold2 | | uniprot | AlphaFold2 | | colabfold\_uniref30 | ColabFold (local search mode) | | colabfold\_envdb | ColabFold (local search mode) | | params | All modes (model weights/parameters) | For detailed per-mode file structure, refer to the official usage docs: [AlphaFold2](https://nf-co.re/proteinfold/2.0.0/docs/usage/alphafold2),[ ColabFold](https://nf-co.re/proteinfold/2.0.0/docs/usage/colabfold),[ ESMFold](https://nf-co.re/proteinfold/2.0.0/docs/usage/esmfold),[ Boltz](https://nf-co.re/proteinfold/2.0.0/docs/usage/boltz). **Notes:** * Each database folder needs to keep its internal file names and layout exactly as downloaded. For example, bfd/ must contain: ``` bfd/ ├── bfd_metaclust_clu_complete_id30_c90_final_seq.sorted_opt_a3m.ffdata ├── bfd_metaclust_clu_complete_id30_c90_final_seq.sorted_opt_a3m.ffindex ├── bfd_metaclust_clu_complete_id30_c90_final_seq.sorted_opt_cs219.ffdata ├── bfd_metaclust_clu_complete_id30_c90_final_seq.sorted_opt_cs219.ffindex ├── bfd_metaclust_clu_complete_id30_c90_final_seq.sorted_opt_hhm.ffdata └── bfd_metaclust_clu_complete_id30_c90_final_seq.sorted_opt_hhm.ffindex ``` Do not rename or move files inside them unless you have verified the pipeline's expected structure for that specific folder. ## Running the pipeline ### Resource configuration Depending on your samples, selected modes, and databases, you may need to adjust compute resources (instance type, memory, CPU, GPU). A single soft config file, all\_models\_gpu\_dnanexus\_real\_db.config, provides example resource settings for all modes. ``` project-xxx:/ProteinFold_v2.0.0/soft_configs/all_models_gpu_dnanexus_real_db.config ``` This file is provided using the input parameter -inextflow\_soft\_confs. When a process defined in the soft config file is run, an appropriate machine satisfying all requirements is requested. It also sets a global docker.runOptions rule to run the process on a GPU, if GPU mode is chosen. Example resource settings ``` withName: 'RUN_ALPHAFOLD2' { machineType = 'mem2_ssd2_gpu4_v2_x48' memory = 192.GB cpus = 48 time = 24.h } ``` Note: ESMFold includes a beforeScript that fixes a CUDA library path issue when running on Seqera Platform (Tower). This only activates when the TOWER\_WORKFLOW\_ID environment variable is present. ### Quick Start Test Use ESMFold mode to quickly validate the pipeline and applet setup (\~46 minutes). #### Run via UI 1. Navigate to your ProteinFold\_v2.0.0 folder and click on the proteinfold\_v2.0.0 applet, then Run. 2. Provide a Job Name (e.g., proteinfold\_2.0.0\_esmfold\_test) and choose an output destination. 3. Under the INPUTS tab, click the input box (labeled "Select File"). 4. In the file browser that opens, navigate to example\_samplesheet\_files/ (or your own samplesheet location) and select your samplesheet CSV (e.g., samplesheet.csv). Click Select. 5. Click the nextflow\_soft\_confs box (labeled "Select File"). 6. In the file browser that opens, navigate to soft\_configs/ and select all\_models\_gpu\_dnanexus\_real\_db.config. Click Select. 7. Under the COMMON section, fill in the following: 8. Enter the output directory name (e.g., esmfold\_monomer) in the outdir box. The pipeline will create a folder with this name inside the destination folder to save all output files. 9. In the mode box, type the model you want to use, such as esmfold. Mode can be any combination of alphafold2, alphafold3, colabfold, esmfold, rosettafold\_all\_atom, boltz, helixfold3, rosettafold2na separated by a comma (,) with no spaces. 10. Set use\_gpu to True to run on a GPU instance. * In the db box, enter the path to the reference database: dx://project-xxx:/ProteinFold\_v2.0.0/references/db/ and set True for full\_dbs. * Scroll down to the model parameter section. In the esmfold\_model\_preset box, type monomer for this run (leave esmfold\_num\_recycles as default unless needed). 8\. Under the NEXTFLOW OPTIONS section, enter -profile docker in the Nextflow Run Options box. 9\. Click Start Analysis to launch the pipeline. 10\. Go to the MONITOR tab to check the pipeline execution progress. The Inputs and Outputs section at the bottom summarizes all input parameters and the output files from the run. #### Run via command line ``` dx run project-xxx:/ProteinFold_v2.0.0/proteinfold_v2.0.0 \ -inextflow_run_opts="-profile docker" \ -inextflow_soft_confs="project-xxx:/ProteinFold_v2.0.0/soft_configs/all_models_gpu_dnanexus_real_db.config" \ -iinput="project-xxx:/ProteinFold_v2.0.0/samplesheet_input/samplesheet.csv" \ -imode="esmfold" \ -iuse_gpu=true \ -ifull_dbs=true \ -idb="dx://project-xxx:/ProteinFold_v2.0.0/references/db/" \ -iesmfold_model_preset="monomer" \ -ioutdir="esmfold_monomer" \ --destination="project-xxx:/ProteinFold_v2.0.0/example_results" \ --priority high \ --name="proteinfold_v2_esmfold_monomer" \ -y ``` ### AlphaFold2 By default, the pipeline splits MSA generation from model inference for more efficient resource use. The example below runs AlphaFold2 in standard mode using the default monomer\_ptm preset, with the full BFD database. Please note that the runtime is nearly 5 hours. There are two ways to submit this run: using a parameter JSON file, or passing all inputs directly via dx run. An example parameter JSON file for this run is available at example\_parameter\_files/alphafold2\_parameters.json. #### Option 1: Using a parameter JSON file ``` { "input": "dx://project-xxx:/ProteinFold_v2.0.0/samplesheet_input/samplesheet.csv", "outdir": "results_alphafold2_monomer_standard", "mode": "alphafold2", "alphafold2_full_dbs": true, "alphafold2_mode": "standard", "alphafold2_db": "dx://project-xxx:/ProteinFold_v2.0.0/references/db/", "use_gpu": true } ``` Once the JSON file is saved on the platform, submit the pipeline using dx run: ``` dx run project-xxx:/ProteinFold_v2.0.0/proteinfold_v2.0.0 \ -inextflow_params_file="project-xxx:/ProteinFold_v2.0.0/example_parameter_files/alphafold2_parameters.json" \ -inextflow_soft_confs="project-xxx:/ProteinFold_v2.0.0/soft_configs/all_models_gpu_dnanexus_real_db.config" \ -inextflow_run_opts="-profile docker" \ --destination="project-xxx:/ProteinFold_v2.0.0/example_results" \ --priority high \ --name="proteinfold_v2_alphafold2_standard_monomer" \ -y ``` #### Option 2: Passing all inputs directly via dx run ``` dx run project-xxx:/ProteinFold_v2.0.0/proteinfold_v2.0.0 \ -inextflow_run_opts="-profile docker" \ -inextflow_soft_confs="project-xxx:/ProteinFold_v2.0.0/soft_configs/all_models_gpu_dnanexus_real_db.config" \ -iinput="project-xxx:/ProteinFold_v2.0.0/samplesheet_input/samplesheet.csv" \ -imode="alphafold2" \ -ialphafold2_mode="standard" \ -iuse_gpu=true \ -ialphafold2_full_dbs=true \ -ialphafold2_db="dx://project-xxx:/ProteinFold_v2.0.0/references/db/" \ -ioutdir="results_alphafold2_monomer_standard" \ --destination="project-xxx:/ProteinFold_v2.0.0/example_results" \ --priority high \ --name="proteinfold_v2_alphafold2_standard_monomer" \ -y ``` ### Boltz By default, Boltz uses a local ColabFold search protocol (MMseqs2) to generate MSAs based on the [Boltz usage documentation](https://nf-co.re/proteinfold/2.0.0/docs/usage/boltz). This requires both colabfold\_db and boltz\_db to point to the reference database. This example is adapted from nf-core/proteinfold's[ test\_full\_boltz.config](https://github.com/nf-core/proteinfold/blob/2.0.0/conf/test_full_boltz.config), using the full reference database on this platform instead of the mini test databases, and all\_models\_gpu\_dnanexus\_real\_db.config for resource allocation. ``` dx run project-xxx:/ProteinFold_v2.0.0/proteinfold_v2.0.0 \ -inextflow_run_opts="-profile docker" \ -inextflow_soft_confs="project-xxx:/ProteinFold_v2.0.0/soft_configs/all_models_gpu_dnanexus_real_db.config" \ -iinput="project-xxx:/ProteinFold_v2.0.0/example_samplesheet_files/samplesheet_single_fasta.csv" \ -imode="boltz" \ -iuse_gpu=true \ -icolabfold_model_preset="alphafold2_ptm" \ -icolabfold_db="dx://project-xxx:/ProteinFold_v2.0.0/references/db/" \ -iboltz_db="dx://project-xxx:/ProteinFold_v2.0.0/references/db/" \ -ioutdir="boltz" \ --destination="project-xxx:/ProteinFold_v2.0.0/example_results" \ --priority high \ --name="proteinfold_v2_boltz" \ -y ``` Please note that the runtime is nearly 4 hours. ## Output structure After a successful run, results are saved to the folder defined by outdir in your parameters. The top-level structure varies by mode, but generally follows this pattern: ``` / ├── / # e.g. alphafold2/, boltz/ ├── multiqc/ ├── pipeline_info/ └── reports/ ``` ### AlphaFold2 (standard, monomer): ``` alphafold2_standard_monomer/ ├── alphafold2/ ├── multiqc/ ├── pipeline_info/ └── reports/ ``` ### Boltz: ``` boltz/ ├── boltz/ ├── mmseqs/ ├── multiqc/ ├── pipeline_info/ ├── reports/ └── split/ ``` In our example run, Boltz includes two extra folders: mmseqs/ (intermediate MSA search output from the local ColabFold search step) and split/ (per-sequence split files from SPLIT\_MSA). ### Example Results We provide example results from completed pipeline runs, available for reference. For a quick view, you can access reports/, containing the interactive HTML report generated by GENERATE\_REPORT, used to visualize the predicted structure(s). ``` example_results/ └── boltz/ └── reports/ └── T1026_boltz_report.html ``` Opening T1026\_boltz\_report.html shows a 3D structure viewer color coded by per residue confidence (pLDDT), where blue and cyan indicate reliable regions and yellow and orange indicate less reliable ones.

The report includes key visualizations such as sequence coverage, predicted Local Distance Difference Test (pLDDT), and Predicted Aligned Error (PAE). Please refer to the [official nf-core documentation](https://nf-co.re/proteinfold/2.0.0/docs/output/) for output explanation. ## Technical considerations ### outdir parameter The outdir parameter is required and defines the subdirectory where results are stored. When launching the pipeline, choose a parent directory (e.g., results) and specify the desired output folder name (e.g., proteinfold\_2.0.0\_esmfold\_test) in the outdir field. Note: You do not need to manually create the proteinfold\_2.0.0\_esmfold\_test folder inside results. The pipeline will automatically create it. ### Modifications to the reference database structure Several folders in the reference database were packaged into single .tar/.tar.gz archives instead of individual files, to avoid long staging times when transferring large numbers of files from platform storage into the job worker at runtime. These archives are extracted automatically during the pipeline run, so no manual extraction is needed beforehand. * pdb\_mmcif/mmcif\_files/mmCIF.tar.gz: the original structure expects individual, uncompressed .cif files. Since this folder contains 188,000+ files, the team packaged them into a single archive to stage as one file instead. * params/mols/mols.tar: the mols reference data used by Boltz contains 44,000+ individual files, packaged into a single archive inside the mols/ folder. This one is handled inside the RUN\_BOLTZ process itself, which locates and extracts the .tar file in place before prediction runs. ### db vs. mode-specific database parameters You can point the pipeline to your database in two ways: * db: a single, general path that works for any mode. * \\_db (e.g. esmfold\_db, alphafold2\_db, boltz\_db): a path specific to one mode. If you only set db, the pipeline automatically applies it to the mode you're running. For example, running --mode esmfold with -idb alone is enough. You do not need to also set -iesmfold\_db. If you run more than one mode at once (e.g. --mode alphafold2,boltz), db is applied to both modes automatically. ### Testing with the Built-in Test Profiles [nf-core/proteinfold ](https://github.com/nf-core/proteinfold/tree/2.0.0/conf)provides test\_full\_\* config profiles (e.g. test\_full\_boltz, test\_full\_alphafold2\_multimer, test\_full\_esmfold) to verify the pipeline works correctly against a small mini reference database. We have not pre-downloaded this mini database on the platform. Running these test jobs stages it directly from its source (S3) at runtime. To run a test profile, add it to -profile alongside docker (e.g. -profile test\_full\_alphafold2\_multimer,docker), and pass our soft config file via -inextflow\_soft\_confs as usual: ``` dx run project-xxx:/ProteinFold_v2.0.0/proteinfold_v2.0.0 \ -inextflow_run_opts="-profile test_full_alphafold2_multimer,docker" \ -inextflow_soft_confs="project-xxx:/ProteinFold_v2.0.0/soft_configs/all_models_gpu_dnanexus_real_db.config" \ -iuse_gpu=true \ -ioutdir="test_full_alphafold2_multimer" \ --destination="project-xxx:/ProteinFold_v2.0.0/example_results" \ --priority high \ --name="proteinfold_v2_test_full_alphafold2_multimer" \ -y ``` Note: no -iinput, -imode, or -idb is needed. These are already defined by the test\_full\_alphafold2\_multimer profile itself. ### Boltz test profile: mols folder staging failure The default test\_full\_boltz profile stages boltz2\_mols\_path from the S3-hosted mini database (s3://proteinfold-dataset/test-data/mini\_dbs/params/mols/). This folder contains 45,000+ individual files. Staging this many small files as a foreign S3 file directly into a DNAnexus job repeatedly failed with chunk upload errors: ``` ERROR ~ File: file-J978j000jy8197kz34J4VjVG > chunk [1] > PUT response: 400 ERROR ~ [Upload] Chunk 1 for file-J978j000jy8197kz34J4VjVG upload exceeds maximum number of upload retries WARN: Unable to stage foreign file: s3://proteinfold-dataset/test-data/mini_dbs/params/mols (try 1 of 3) ``` Therefore, we need to override boltz2\_mols\_path to point to a mols.tar archive staged on the platform, instead of the default mini database path: ``` --boltz2_mols_path dx://project-xxx:/ProteinFold_v2.0.0/references/db/params/mols/ ``` Here is the command for the test\_full\_boltz profile: ``` dx run project-xxx:/ProteinFold_v2.0.0/proteinfold_v2.0.0 \ -inextflow_run_opts="-profile test_full_boltz,docker" \ -inextflow_soft_confs="project-xxx:/ProteinFold_v2.0.0/soft_configs/all_models_gpu_dnanexus_real_db.config" \ -iuse_gpu=true \ -iboltz2_mols_path="dx://project-xxx:/ProteinFold_v2.0.0/references/db/params/mols/" \ -ioutdir="test_full_boltz" \ --destination="project-xxx:/ProteinFold_v2.0.0/example_results" \ --priority high \ --name="proteinfold_v2_test_full_boltz" \ -y ``` Note: no -iinput, -imode, or -idb is needed, these are already defined by the test\_full\_boltz profile itself.