Simplify pipeline parameters

[grst]

Description of feature

This pipeline has an enormous number of parameters. Each of them creates a maintenance burden (keeping docs up-to-date, take params into account during modifications) and make it more complicated for users to understand what they need to specify in order to run the pipeline correctly.

IMO we should try to attempt to reduce the number of parameters once the multi-config toolsheet is fully supported (#470).

Some candidates for removal:

• study_type is probably superseeded by the toolsheet?
• deseq2_cores -> shouldn't that be inferred from the number of cores assigned to the nextflow task
• --exploratory_whisker_distance (Why would one even want to change this?)
• --exploratory_palette_name -> better choose a suitable palette based on the number of categories.
• --differential_foldchanges_logged -> fold changes should always be logged.
• --differential_palette_name -> same
• --limma_confit -> any reason not to always have it?
• --limma_ndups/--limmma_spacing, --limma_block, --limma_correlation I think these were just added to support duplicate correlation/mixed models in limma, but we decided in https://github.com/nf-core/differentialabundance/pull/339/files to not move forward with this in favor of DREAM which offers a much nicer and more flexible way to deal with random effects.
• --gsea_zip_report -> an output folder should be enough. Users can zip themselves if they want.
• --grprofiler2_palette_name -> see above
• --report_scree -> just include it. Better to support custom reports instead, see https://github.com/nf-core/differentialabundance/issues/88
• --differental_.*_column -> internally set the appropriate colnames for each method. I don't think there's any point in exposing this to the user.

@pinin4fjords LMK what you think

[suzannejin]

yes i agree!! many of these parameters, like for example deseq2 specific column values, etc they should not be provided as parameter by the user, but instead fixed inside the pipeline or something.

[pinin4fjords]

We should address these one by one. e.g. the fold change logging is method dependent.

But I agree with the principle, I may have got a little param-happy. Folks can still supply these things via custom config and ext.args.

[SusiJo]

Hi, I also agree and approve the idea of simplification. There are some parameters that have non-intuitive names and could be simplified for users, i.e. --transcript_length_matrix to have a more generic name like --feature_length_matrix