YaY

Fixed two bugs in the fitter that were causing it not to minimise properly and to use the wrong residual in the chi squared calculation. This leaves one small effect, that the fortran sometimes has higher chi squared for the IP and less for the track. Probably due to it using the errors from the 2D PCA and not swimming them.
Heres what the chi squareds look like (track errors simplified):

So changed the error over to a tsi, eta representation before the chi squared is calculated to prevent the under-detemined error matrices that were causing the inversion problem. Shapes of lone ip fraction much better, but still getting a hard shoulder on the C++ at sqrt(1000) microns!
Investigating....

So shift the scale isn't really gonna help. The problem is that the x and y error are highly correlated (obviously as they both come from tsi) giving us matrices that are near-singular.
So three options present themselves - either use a precision (slow) matrix inversion, or rethink the problem to remove the inversion, or recode the swimming etc to use a less correlated parameterisation.
Humph.

Matrix Inversion Woes

So after thinking I had fixed the problems menthioned in the powerpoint there were still remaining differences.... So on Dave's suggestion made the track errors simple and constant per track. Fortran responds as expected and C++ doesn't bat an eyelid. Alarm bells galore! Find a typo in the new matrix inversion code I had written, doh. Fixing that makes my new routine hit the computational precision wall again. Thinking about it I should just convert to microns and see if dealing with numbers of order unity will work.

Down in the lab the GPIB card I scavenged refuses to work with XP. But as Brian has taken the chip away this is somewhat academic. But as the labview test code is half written I should try and find a driver.

Fixes Galore

So most of the detail of what I've been doing is in the powerpoint from todays meeting.

Catch Up

So I haven't posted in a while due to e7even's ineptness, grrr. Things are looking better now connection wise anyway.
Been looking in more depth about how the two versions decide if a track is attached to the IP or not, by looking at how the fraction of lone IP's varys with the impact parameter of the track input. We get the plot shown where the C++ (green) has a sharp cut at exactly sqrt(1000) microns!! And the fortran has the slow rise (blue) Ignore the first and last bins. Oh this is for spherical IP of 5 micron, a non spherical IP just smeers the change a bit more.
On good news have the batch farm doing my bidding again, need some data disk though.
I'm on the trail of some strangness in the covar matrix conversion... stay tuned!

Trying to shake off this cold, so tried to do some work from home. E7even however think that 30% packet loss is an acceptable way to run an ISP grrr.

Switching the compliation of ZVTOP++ to a makefile as it was getting annoying to wait after small changes to the code base. About time I learnt make anyway. This makefiles site was useful. But still needed the make manual to clear up a few things about implicit rules.
Edited the SGV compile file to reflect the new makefile, and it works!
Just run make depend when changing header files.
Todo

1. Merge changes from SGV version back to CVS, then delete the copy and use a symlink instead
2. Clean up bxzvtop++.cpp and add some comments for Mark
3. Put SGV up for download for Mark
   

First day back in after xmas. Talking to Andrei about hardware work. Good place to start getting myself into this is to use the setup that Brain Hawes has to recreate his measurements and compare with the spice model he has. Basically clock amplitude vs. clock frequency vs. bias voltage. Then measure the actual capacitance of CPC2 for the spice model.
Longer term plan is to set up a proper test stand for analogue output from the 4 test channels, using charge injection and a source. Hopefully looking to March for this to be up and running.
Todos:

1. Talk to Brian about setup
2. Check radiation paperwork