https://www.tcec-chess.com/archive.html?season=17&div=sf&game=84
It would seem that SF found a fortress, but then mysteriously blundered it away. Can someone analyze this and see what went wrong?
This was really a big loss in the context of the TCEC, we really need to analyze/debug this issue. It was a fortress with eval flatlining twice once at 1.6 then again at 1.88. Developers please kindly take a look. I am providing the link to the logs that i got from TCEC here. Do y'all think that its an issue with 50 move rule implementation?
This seems to happen rather often, iirc there were 2 more cases of this behaviour in TCEC SuFi, but I am not sure.
Please, make it easy for the devs to analyze this. I.e. at least the move where the blunder is played. Better with the FEN, the moved that was played, the move that would have been right. It is also helpful if the same info is provided for all recent games where this pattern happened.
Finally, if the position is lost after a deep analysis (and recall 5min at TCEC is multiple hours at home), there is no real solvable issue, I'm afraid.
What move number was the suspicious one?
@vondele It looks like this happened in Zeitnot, again.
At move 121, White resets the 50-move counter with the pawn move 121. c3-c4. And with move 133. Rd5xc5, White gives the quality to enter a probably already won endgame. And this all happens with very low time for both engines.
So far I was not able to spot something related to the 50-move rule nor an obvious blunder. But I'm no GM, of course!
Someone in chat mentioned that on a normal home PC sf sees Rxc5 as being bad within a few minutes, which SF on tcec hardware with 176 threads should be able to see even on increments.

Just meming. This has been an incredible SuFi to watch, though it's a shame the high thread count combined with low increment TC led to some terribly inaccurate albeit entertaining play from both sides. Hats off to everyone who works on making SF the great engine that it is.
Someone in chat mentioned that on a normal home PC sf sees Rxc5 as being bad within a few minutes, which SF on tcec hardware with 176 threads should be able to see even on increments.
Occy mentionned that on his 2990WX, it took SF less than 2 seconds to reject the blunder and see that Rxc5 was winning for white if Ke7. But threading variability + low time might be enough of an explanation in this case, however unnerving that blunder was...
I'll close this assuming #2620 tracks this one as well.
Most helpful comment
Just meming. This has been an incredible SuFi to watch, though it's a shame the high thread count combined with low increment TC led to some terribly inaccurate albeit entertaining play from both sides. Hats off to everyone who works on making SF the great engine that it is.