Humph, really should update this more. Maybe if my isp wasn't so crap. Anyway.
The previous fix to the covariance matrix was just a temporary patch as it didn't take into accout the correlation terms. The sensible way out of this was to adopt the SGV helix convention with a 5x5 covariance matrix that wouldn't give any inversion problems. In a later post I'll detail that convention with some diagrams etc.
The conversion gave some fringe benefits, I reworked the swimming code so that swimming is now "Just in time". I also simplified the swiming interface, removing the swimmer object. The 5x5 covariance matrix means a 2x2 positon matrix, swimming that is orders of magnitude faster than the old 6x6. :)
The new swimming was tested by swimming the point nearest the MC production vertex (given by SGV) Swimming the covariance has't been implemented yet as I have to work out what the jacobian should be!

After all those changes the comparison with the FORTRAN was similar to with the quick fix, this plot here is for track errors of 10 micron IP spherical 5 micron and chi-squared cut of 10. Vertical axis is the fraction of tracks not vertexed with the IP, horizontal the 3D impact parameter.

The smooth shoulder on this plot is unexpected, for both C++ and FORTRAN. The reason being that for constrant track errors we expect there to be a hard cut, as the chi-squared should only depend on 3D impact parameter. We can seperate out the tracks that should have been in the shoulder and plot thier angles: So we conclude that this an effect caused by a miscalculation of the z residual or z error as this only invloves tracks at low theta. We know what the C++ is doing its just using the difference in z with the error on the z axis. A diagram helps:
The green point is the one we want to get the chi-squared to, red the 3D POCA on the track. The tracks and its error are in blue. The C++ (and presumably the FORTRAN) were using the black lengths as residual and error. I'll put the correct lengths in a new post.