MSIsensorPro requires a baseline file not the output of scan.

[RSWilson1]

twistcgp/workflows/twistcgp.nf

Line 178 in b96aed7

MSISENSORPRO_PRO(

The documentation in MSIsensor Pro isn't clear about the difference between scan and baseline files but the pro command requires a baseline file instead of the output of scan (the output of scan is used to make the baseline) Issue referencing the correct usage: xjtu-omics/msisensor-pro#77.

[nh13]

Thanks for the report and the fork PR (RSWilson1/twistcgp#1).

After checking the source, pro -d actually accepts both a scan list and a baseline. Per ProUsage() in cpp/distribution.cpp:

1. msisensor-pro pro -d reference.list          -i 0.1 -t tumor.bam -o out
2. msisensor-pro pro -d reference.list_baseline        -t tumor.bam -o out

Mode 1 uses a hard threshold, mode 2 uses trained per-site thresholds. The wiki Best-Practices only documents mode 2 for tumor-only, and the maintainer recommends it in xjtu-omics/msisensor-pro#77.

The nf-core msisensorpro/pro module passes the scan list to -d without setting -i, so the pipeline silently runs mode 1 at the default threshold (0.1) instead of the likely-more-accurate mode 2. Real issue, smaller than a crash.

Plan:

1. Here: add --msisensor_pro_baseline, require it when --use_msisensor_pro_licensed is set, skip MSISENSORPRO_SCAN in that path, and document baseline construction (borrowing from your fork).
2. nf-core/modules: file an issue for (a) a new msisensorpro/baseline module, (b) exposing -i in msisensorpro/pro, (c) clarifying the -d dual semantics in meta.yml. Will cross-link.

One pushback on the fork PR: overloading --msisensor_scan to mean either a scan list or a baseline depending on mode is confusing. A separate --msisensor_pro_baseline keeps semantics clean.

[nh13]

Upstream filed:

• Issue: [BUG] msisensorpro/pro silently runs in hard-threshold fallback mode; baseline module missing nf-core/modules#11188
• Draft PR: feat: add msisensorpro/baseline module; clarify pro -d dual semantics nf-core/modules#11190 (new msisensorpro/baseline module + pro meta.yml clarification)

[znorgaard]

Some suggested modification to the plan @nh13.

In dev we've moved away from providing a scan for msisensor2 because it's redundant when using a model. #77

Which means on dev, the --msisensor_scan param is only used for msisensorpro. If we don't use it for msisensorpro, we can remove it entirely.

I vote against requiring a baseline as input when running msisensorpro. That limits the utility for users that want to make an initial run with msisensorpro before they've built up a panel of normals.

I think the plan should be to have --msisensor_pro_sites param which can be a scan, a baseline, or nothing. If it's nothing, we generate the scan automatically. In the docs we document how to generate a baseline file like we do for other PON creation. And we can recommend adjusting -i using ext.args.