#18 Clumpify dedupe=t and containment=t possibly bugged

[Simon]

When using both dedupe=t containment=t options, clumpify.sh seems to deplete far fewer reads than dedupe=t by itself, when logic would dictate depleting more reads.

It seems to me that this function in Clump.java might be the cause:

    public static boolean contains(Read a, Read b, int maxSubs){
        if(a.numericID==b.numericID){return false;}
        boolean ok=contains_inner(a, b, maxSubs);
        if(!ok || a.mate==null){return ok;}
        ok=contains_inner(a.mate, b.mate, maxSubs);
        if(!ok){return false;}
        ReadKey rka1=(ReadKey)a.obj;
        ReadKey rkb1=(ReadKey)b.obj;
        ReadKey rka2=(ReadKey)a.mate.obj; //TODO: In containment mode, mates need to always get keys.
        ReadKey rkb2=(ReadKey)b.mate.obj;
        return ((rka1.kmerMinusStrand==rkb1.kmerMinusStrand)!=(rka2.kmerMinusStrand==rkb2.kmerMinusStrand)); //Ensures that both reads have the same directionality.
    }

The final kmerMinusStrand check should always fail because from what I can tell the reads are all considered plus strand. The only confusing aspect is how the containment=t module is able to deplete any reads at all.

[Brian Bushnell]

I'm not sure why I wrote the last line like that. I changed it to:

return ((rka1.kmerMinusStrand==rkb1.kmerMinusStrand) && (rka2.kmerMinusStrand==rkb2.kmerMinusStrand));

...which fixes the problem. That will be released soon in 38.71. Sorry for the delay!