You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the filtering of e.g. minimum counts or genes in the quality control report has no related checks to see if there are any spots lefter the filtering. Filtering itself will work just fine, but will produce non-informative errors downstream, which should be improved. The check should output an informative message about (1) what filtering step raised the problem, (2) what the relevant parameter was set to (either default or user-specified) and (3) that the user should re-run with a lowered threshold.
I'm not sure whether this type of check should stop the pipeline or not. Such errors currently do yield errors that stop the pipeline, but we could also re-work the QC report in some fashion to still be able to output something - this could possibly be a useful functionality to have in regards to using e.g.checkatlas or multiqc for aggregating multiple reports as discussed in #40.
The text was updated successfully, but these errors were encountered:
I ran into this as well. The main problem was that the in_tissue column was parsed with the wrong dtype, leading to all spots being filtered out, no matter the threshold.
This is currently in the dev branch of the pipeline, implemented in such a way that it won't stop the pipeline but rather continue on without filtering as well as giving a notice to the user in the relevant report.
Description of feature
Currently, the filtering of e.g. minimum counts or genes in the quality control report has no related checks to see if there are any spots lefter the filtering. Filtering itself will work just fine, but will produce non-informative errors downstream, which should be improved. The check should output an informative message about (1) what filtering step raised the problem, (2) what the relevant parameter was set to (either default or user-specified) and (3) that the user should re-run with a lowered threshold.
I'm not sure whether this type of check should stop the pipeline or not. Such errors currently do yield errors that stop the pipeline, but we could also re-work the QC report in some fashion to still be able to output something - this could possibly be a useful functionality to have in regards to using e.g.
checkatlas
ormultiqc
for aggregating multiple reports as discussed in #40.The text was updated successfully, but these errors were encountered: