Hey everyone, When running nf-RNAseq it is recommended to set the max intron length to something suitable to your organism; for example in the model plant arabidopsis introns >6kb are very rare and running it with the default setting of 100MB will potentially give you some problematic artifacts. The parameter --allignIntronMax is passed to STAR in this pipeline. Is there a way to control this parameter globally in nf-rnasplice? The only thing i could find in the parameter documentation was controlling rmats_min_intron_len, but no max; and also not for components than rmats

In the rnaseq pipeline, there is the

--extra_star_align_args

parameter that allows you to pass additional arguments to STAR. Unfortunately, rnasplice does not have that (yet?), so you would have to use the more convoluted way of adding the parameters using

ext.args

for the

STAR_ALIGN

process in a config file. It is very important, though, that you check what the currently configured setting of

ext.args

for that process is, and that you add those settings to your own, otherwise you would be messing up other STAR parameters, and the pipeline might even crash. 🤞

It is very important, though, that you check what the currently configured setting of

ext.args

for that process is, and that you add those settings to your own, otherwise you would be messing up other STAR parameters, and the pipeline might even crash. 🤞

What does this mean, more exactly? I was under the impression that

ext.args

is generally initialized to NULL or empty, unless explicitly set by the user for some specific process. Is this not the case? Do the nf-core pipelines actually assume some "default" values for

ext.args

for the various pipeline processes?

@Alexandru Mizeranschi,

ext.args

is empty if you use a module in its default state (which typically is "bare-bones", relying on tool defaults), but many/most modules are customized by the respective pipeline (e.g. you might use different STAR arguments in rnaseq compared to rnasplice) via

ext.args

. So if you don't copy these custom settings over to your config, they get lost.

can you give some examples of which STAR arguments you mean, specifically? https://github.com/nf-core/rnasplice/blob/master/modules/nf-core/star/align/main.nf#L54

Look at the

$args

at the bottom of the STAR command line. This gets initialized from

ext.args

. Let me find where that is. It depends on the pipeline where the customizations are encoded. If there is a

conf/modules.config

, it would likely be there, but there are other places, and I think newer pipelines are moving away from a central config file to make it easier to move configs around.

I think I found what you mean, and you're right, there is a

conf/modules.config

and it does use

ext.args

do set some parameters for this process. https://github.com/nf-core/rnasplice/blob/master/conf/modules.config#L244

Yes, exactly, that's it. One would have to basically copy all that and add anything else to it (or modify existing settings, if desired).

Great info, thanks again. I really wish the nf-core guys would standardize this stuff a bit better. If people don't consider looking there, or they don't even know that they should look for these things in the first place, they might end up causing some unfortunate behavior from their pipelines when using

ext.args

.

Thanks Thomas and Alexandru for the very insightfull discussion. Yes I agree, or having a option to pass these parameters along. Anyway, thanks a lot!

Great info, thanks again. I really wish the nf-core guys would standardize this stuff a bit better. If people don't consider looking there, or they don't even know that they should look for these things in the first place, they might end up causing some unfortunate behavior from their pipelines when using ext.args.

It is standardised already 😉 . Manual customisation of

ext.args

is entirely at the users risk. Only parameters you give to the pipeline e.g.

nextflow run nf-core/rnasplice <...> --foo

are official supported

I find the whole idea of pipeline developers setting up predefined

ext.args

values in config files a bit confusing, honestly. Just my 2 cents. And as @Thomas Danhorn explained above, it's potentially opening up a can of worms for users who are looking to get a bit of extra flexibility from the nf-core pipelines. For instance, people who use STAR in both #CE8SSJV3N and #C0493FQQZ3P and need a custom parameter added, as in the example above, would basically need to dig into various config files and make some sort of a union of predefined parameters from both pipelines, or risk breaking things in their pipeline runs.

Well the problem is you can't 'easily' cater to both sides: novice users and experienced The options are: • Flexibiluty: No pipeline level-specific parameters, just let user inject whatever the want with

--extra_*_args

. But then novice users won't know what to put in, or any user can put things and complain that something isn't working (because not supported by the pipeline) • Complete lockdown: only pipeline parameters and injected directly into the module - no flexibility and only get new stuff added if a user requests a new parameter I agree having common parameter names would be nice across modules, but it always come down to naming things: it is bascially impossible to implement to cover all cases. Lets say you have

--extra_star_extra_args

for all pipelines and that is hardcoded in the module. That's fine - but then you have a pipeline that needs STAR twice - then what do you do ? Maybe each STAR instance needs different parameters, so what do you name it there? What we have now is a compromise to try and nudge people NOT to use whatever tool parameter they want willy-nilly - but give them a half hidden way to add it if they really really want. Ultimately we've opted to cater primarily for new users or novice users (biologists), as they have the largest learning curve AND focusing on that makes much more robust/reliable core pipelines. Giving too much flexibilty also risks reducing reproducbility > potentially opening up a can of worms for users who are looking to get a bit of extra flexibility from the nf-core pipelines. People looking for more flexibility are normally more experienced and should be able to understand the system somewhat (and read the docs) 😉

Alright, fair points. Thanks for the documentation link above!

Yes good points, and thanks for the explaination. I am not sure I agree this should be a parameter for advanced users to adjust, since also novice users would need to adjust the max intron size for their species of interest to get robust outputs.

In that case, you might want to make a feature request on GitHub, for the pipeline devs to add a dedicated pipeline parameter that sets the max intron size in STAR

I know that

--extra_star_extra_args

is not standard, but I nevertheless hope that more pipelines (including rnasplice, so if you ask for features, ask for that) will adopt it (it's either that, or you spend a lot of time explaining to users how to work around it 😀). The same goes for any other tool where users are likely to want to add/change parameter settings. Other than that, I think the system is OK the way it is,

ext.args

is there if you really need it. One thing to be discussed is if

ext.args2

should be set up to be used instead, so if the parameters being customized in

ext.args

are unaffected, you don't need to worry about clobbering them. But then any process in any pipeline would need to check for and integrate

ext.args2

, and if there are conflicts with

ext.args

, these would need to be resolved.

I hope the opposite. On principle I don't trust users and if I give them a free for all parameter they means I basically have to give official support when they break dtuff. I would rather just point them to docs for doing crazy stuff at their own risk and then that's over and done with

My take is that the people who just want results (anything, not matter if they make sense) will just run with the defaults anyway, but the people who think about things should have the option to tweak things if they need without too many hurdles. (These also tend to be the people who find their own solutions.) What I like about

--extra_star_extra_args

is that STAR has dozens of parameters, so you can't reasonably have a dedicate parameter in rnaseq/rnasplice/etc. for each one, if and if you leave a few out, someone will request them sooner or later. I agree, personal philosophies ... 😄 "With great power comes great responsibility", I can live with that.

To me that sounds like an issue of STAR. I think it's a fine approach in special cases like that but I wouldn't want it as a default already

What I like about

--extra_star_extra_args

is that STAR has dozens of parameters, so you can't reasonably have a dedicate parameter in rnaseq/rnasplice/etc. for each one, if and if you leave a few out, someone will request them sooner or later.

A similar point to this one came up recently in the context of #CE9MS66BS, for the QUAST tool. The main issue there is that the corresponding module doesn't even have any

ext.args

support, so flexibility there is very low ATM. https://github.com/nf-core/mag/issues/748

That's a bad comparison though because mag quast is a very old local module and not up to standard

Ah yes, I was not looking for an immediate function, just wondering if i had missed the parameter somewhere in the documentation. What @Thomas Danhorn is saying is right, I think; most people will just run it with defaults and being either blissfully unaware or can't/don't want to bother with digging into the config files. My concern is that running with defaults on species that are not human, mouse etc might give you false /misleading results, and if it is difficult to adjust the parameter is usually won't be. I see the pipeline being referenced sometimes with no mention if this parameter was adjusted; so i assume it wasn't. That being said, thanks for all the info, I at least can adjust it! I'll put in a feature request; but I understand it might be tricky to implement.