Handling of single_channel_generator test

[Juergen Reuter]

This happens from time to time ... vamp test take ages without any particular reason. This again jeopardizes usability and reliability of our test suites.

[Juergen Reuter]

Actually sometimes, it is vamp_test, sometimes it is vamp_test0.... My suggestion is to switch off ALL vamp and Omega selftests at the moment, as they are ONLY generating noise!!!!!!

[Juergen Reuter]

First survey on that, it seems that the sys time stays almost the same, while the real and user time can go up by a factor of 8 or so:

 real        user        sys
0m19.904s  0m19.676s   0m0.120s
0m18.549s  0m18.317s   0m0.135s
2m17.475s  2m16.828s   0m0.141s

And it is the vamp0 test which takes that long.

[Juergen Reuter]

Next info: as the duration of the test ist driven by vamp_test0, the vamp_test0 duration is completely driven by the call to single_channel_generator.

[Juergen Reuter]

It is the generation of the unweighted events in the single channel generator which takes that long. Let's discuss what we gonna change here....

[Juergen Reuter]

The single_channel_generator test could for an unpleasant random seed take several minutes, as it is run in a do loop over 100 iterations in the unweighted mode. We could either do this only for very few iterations, leave the test out or run for a favourable random seed to be found where it is rather fast. Will resolve at the Wuerzburg meeting at latest.

[Juergen Reuter]

We are using a fixed seed now, having the option for changing the seed for testing. This is an acceptable seed, time-wise. Closing.