Update usage docu for newcomers

[d4straub]

This is a first proposal to make the usage documentation more friendly to scientists new to the field. It attempts to explain the defaults of the pipeline and when to deviate from them.
Up for discussion.

PR checklist

• This comment contains a description of changes (with reason).
• If you've fixed a bug or added code that should be tested, add tests!
• If you've added a new tool - have you followed the pipeline conventions in the contribution docs
• If necessary, also make a PR on the nf-core/mag branch on the nf-core/test-datasets repository.
• Make sure your code lints (nf-core pipelines lint).
• Ensure the test suite passes (nextflow run . -profile test,docker --outdir <OUTDIR>).
• Check for unexpected warnings in debug mode (nextflow run . -profile debug,test,docker --outdir <OUTDIR>).
• Usage Documentation in docs/usage.md is updated.
• Output Documentation in docs/output.md is updated.
• CHANGELOG.md is updated.
• README.md is updated (including new tool citations and authors/contributors).

[jfy133]

@nf-core-bot fix linting

[d4straub]

I think looks pretty good already.

[d4straub]

I think it would be helpful to add here approximate RAM and time requirements. Same for binners. Maybe we can add numbers that we produce for the manuscrtipt review here? Alternatively, a student of mine is working on checking computational requirements and we could add that numbers when they are available.

[jfy133]

I'm always loathe to do make such things outside a dedicated study (which I really REALLY want to see, but few do) as it can be so highly dependent on the data and complexity input... but yes I guess we could add it from the stuff @dialvarezs is adding.

[jfy133]

I guess we can with that provide read counts, but I assume the CAMI stuff is static? And then what metric of metagenome complexity can we use?

[jfy133]

More context: I had this problem with a taxprofiler paper we just submitted, the only two metrics we could really report on were RAM and harddrive usagee...

Number of CPUs you can choose, you can set to 1 or 1000 it depends on how much is available, and time also depends many different factors: how old the CPU is, what type it is, how busy the scheduler is, what the IO bandwidth is, which are all driven by the infrastructure not the pipeline/tools themselves

[d4straub]

I would add this to give an approximation, i.e. does the specific assembler need 1 hour or 1 day, what tool needs longer? Is the RAM 10GB, 100GB, or 1TB? Number of CPUs kept on default. And thats it. After all its for people who are new to this to give an idea what to expect. We have that questions occationally in slack afaik.
And also how computational requirements relate to each other. I assume that in many cases the RAM and time ratios between alternative tools hold true, e.g. when one needs 10GB RAM and another needs 100GB, then the latter will usually need 10x more than the former. And that would be helpful in itself as well, I think.

[d4straub]

But we can also postpone that and attempt to add it in a separate PR? No need to complicate things?

[d4straub]

So how its going here? Do we wait for more opinions?

[jfy133]

Apparently I dreamt I merged this 🤦

[d4straub]

I can merge it bypassing merging rules (because confirm-pass wont pass ever)