Consistent use of primers throughout pipeline

[martinghunt]

Expected behaviour: the amplicon scheme and the primers used are inferred early on in the pipeline. Some primers can be identified as not present in the reads. These primers should be completely excluded from everything onwards.

Actual behaviour: inconsistent use of whether primers are present or not.

See comment "The logic for identifying primers before cylon is run is different than the later primer id logic that we use to mask primer positions in the consensus." #99 (comment)

[jeff-k]

Identifying which primers belonging to an amplicon are observed among all fragments belonging to that amplicon is a subtly different task than identifying which primer appears in a fragment.

I agree that it would have been nice to retain the original consistent logic but the solution that we arrived at ultimately requires that these operations follow different logic.

[martinghunt]

IIRC the plan was always to remove primers in the way I just described. And be consistent throughout.

[jeff-k]

There has been a large amount of discussion and planning about how we identify amplicons and which primers are observed from them and how we identify which bases belong to primers inside a given fragment. These are quite different problems.

If you would like to modify the behaviour of the amplicon coordinates that are passed to cylon during the consensus step, then let's decouple that request from the adapter issues.

[iqbal-lab]

This issue is about

• if an alt primer is excluded from the scheme and removed before passing to cylon, it shoudl be excluded forever
  It is not about the primer-id having different implementations at the start and in selfQC

[jeff-k]

Yes, that is what we do

[iqbal-lab]

yeah the point is, we excliude it when passing to cylon, but it comes back by the time we get to selfQC