Closed allyhawkins closed 1 month ago
This all looks good to me! I'll note that I also tested this locally (I thought about whether we might want to add this to stub testing, but I don't think that's necessary) -
- I added a couple lines to the stub run metadata file to give project
STUBP08
5 libraries- I ran
nextflow merge.nf -stub -profile stub --max_merge_libraries 4 --project STUBP08
- Indeed, I received the message:
WARN: Not merging STUBP08 because it contains too many libraries.
I also don't think this is necessary. We also skip multiplexed libraries in the same way and don't have a stub run for that so I think it's probably good as is.
Closes #776
In processing data for the Portal, we have seen that projects with > 100 libraries do not successfully run through the merge workflow due to what we think is limitations of the packages we use. We don't actually know the number of libraries that cause the problem and it's probably based on number of cells and how big the actual matrices are, but as of right now we do not include any projects with > 100 libraries as merged objects on the Portal.
Because of this, I'm adding a parameter to specify the maximum number of libraries allowed in a merged object and setting the default to 100. If any projects have more than this, then we will print a message to the log files and skip processing that sample.