This is a test version of Biostars. For the public version, visit https://www.biostars.org.
STAR genome index generation: NF-core vs manual parameters (seeking clarification)

Hi everyone, I’m trying to better understand the practical differences between generating a STAR genome index manually versus generating it through an NF-core RNA-seq pipeline.

Most STAR tutorials and forum posts emphasize that large genomes (e.g., human) don’t necessarily require extremely high RAM if parameters such as --limitGenomeGenerateRAM, --genomeChrBinNbits, or --genomeSAindexNbases are adjusted correctly.

However, NF-core abstracts these settings, and I’m not fully clear on how much control the user has over STAR parameters during index generation inside the workflow.

So I’d like to ask the community:

  1. Does NF-core override or restrict STAR’s index-generation parameters? For example, can you pass optimized values for --limitGenomeGenerateRAM, --genomeSAindexNbases, etc., or does NF-core rely mostly on defaults?

  2. In your experience, is there any performance/efficiency advantage to building the index within NF-core, compared to building it manually with STAR? Or is it generally better to generate the index directly with STAR (especially when you want full control)?

  3. Are there cases where NF-core’s index building is actually slower or more resource-intensive due to conservative defaults? I’ve seen some reports of unusually long runtimes.

  4. Finally, is there any practical downside to simply providing NF-core with a manually generated STAR index instead of letting the workflow generate its own?

I’m not debating workflows—just trying to understand how much flexibility exists and whether manual index generation is still preferred when dealing with large genomes or limited compute environments.

Thanks!

transcriptome r coding
• 3,740 views • link
written by Amb@r85 • Amb@r85

1 answer

However, NF-core abstracts these settings, and I’m not fully clear on how much control the user has over STAR parameters during index generation inside the workflow.

most (all?) nf-core processes provide a way to customize any part of the code. It's usually a parameter 'args' that is blank by default.

https://github.com/nf-core/modules/blob/master/modules/nf-core/star/genomegenerate/main.nf#L22

if you want to customize the creation of the STAR genome, you can provide an extra config file (eg. with -c local.config containing the instructions to override 'args'

process {
withName: "STAR_GENOMEGENERATE" {
    ext.args =  "--limitGenomeGenerateRAM 12345 "
    }

}
• 0 views • link
written by Pierre Lindenbaum Pierre Lindenbaum

Thanks! This is helpful — I wasn’t aware that ext.args could override STAR’s index-generation parameters so explicitly.

A follow-up question, since this is what motivated the post:

If one manually generates a STAR index using optimized parameters (for example using lower genomeChrBinNbits, adjusted genomeSAindexNbases, or tighter RAM limits), is there any downside to providing that precomputed index to NF-core instead of letting the workflow generate it internally?

I’m asking because I’ve seen very long runtimes and unusually high memory usage during NF-core index generation compared to manual STAR runs, so I want to confirm whether this is simply due to conservative defaults, or whether NF-core does something fundamentally different.

And relatedly — when writing a methods section, does the community generally see any advantage in citing NF-core as a complete workflow vs. explicitly listing the tools + versions + parameters (e.g. STAR/featureCounts/etc.)?

My intuition has always been that the latter is more transparent for reproducibility, but I’m curious how others approach this.

• 0 views • link
written by Amb@r85 • Amb@r85

Why do you have to choose one or the other? Are you afraid of the methods section becoming too long?

• 0 views • link
written by dsull dsull

I’m asking because in some cases NF-core and manual STAR indexing don’t behave identically, particularly regarding:

  • RAM requirements
  • index generation time
  • SAindex / ChrBin parameter defaults
  • differences in how methods need to be reported

So the question isn’t about “choosing” one method due to fear of a long methods section — it’s about whether the choice affects computational efficiency or reproducibility, especially in environments with limited resources.

If both approaches produce equivalent results under the hood, that’s useful to know. If not — that’s also useful.

This is why I’m trying to understand when (or whether) NF-core’s abstraction restricts STAR’s full parameter space, and how the community prefers to handle citation transparency.

• 0 views • link
written by Amb@r85 • Amb@r85

There can be subtle effects on alignment if certain settings are adjusted, so there will be slight differences.

I’d just mention the tools and the fact that you ran nf-core. The methods section is about what YOU did; and you don’t have to explain everything that goes on under the hood—just name/cite the tools that are used (e.g. star) and that’s that. You wouldn’t go about saying you ran STAR with parameters X, Y, and Z if you ran it through nf-core.

That’s my 2 cents.

• 0 views • link
written by dsull dsull

Thanks — and just to clarify the motivation here:

I’m not trying to avoid command-line STAR. I actually prefer running STAR directly because it gives full control over parameters, and I’m comfortable tuning things like genomeSAindexNbases, genomeChrBinNbits, and RAM limits when building large-genome indexes.

The question is really about equivalence and reproducibility, not convenience.

If NF-core:

abstracts or fixes certain STAR parameters,

uses defaults that differ from commonly recommended STAR settings, or

generates an index that is not identical to one produced manually,

then this has implications for:

computational efficiency,

memory usage,

downstream alignment behavior, and

how much detail needs to be reported in the Methods section.

That’s why I’m trying to understand whether NF-core adds an actual advantage (beyond automation), or whether manually generating a STAR index remains preferable when you want explicit control and fully transparent documentation.

I’m definitely not concerned about methods sections becoming long — I’m concerned about being precise about what was actually done.

Would appreciate any insights on how others handle this distinction.

• 0 views • link
written by Amb@r85 • Amb@r85

Log in to answer this question.

More posts like this