Allow negative delays in trace_utilities.delay

[fschlueter]

This is not finished yet and will break the tests. We have to take a few decisions here. Currently I am always cropping the traces after delaying to remove the now unphysical signals at the beginning or end. However, in case of a positive delay this will change the trace start time (as it did before). This is now calculated in function. If we want to keep that we have to change the code where this function is used. I also changed the calculation of the number of samples to crop. We might need to check if that calculation agrees now with calculations outside of this function. And finally, why do we have the argument delayed_samples I would remove it.

[fschlueter]

Oh this function is only used in one module (analogToDigitalConverter) which makes the gravity of our decisions much smaller. Why it is not used in base_trace.apply_time_shift? Both do the same but apply_time_shift does not corp anything (which I think might be a problem). Should we not corp it in apply_time_shift but than zero-pad again to avoid changing trace start time and number of samples? The same we could add to this function here!

[fschlueter]

@cg-laser or @sjoerd-bouma any thoughts?

[fschlueter]

Okay one unit test is still failing which I will investigate. However, apparently the new warning I added is firing a lot during our simulation examples. Are we time-shifting traces with noise? Shouldn't we corp those traces than by default?

[fschlueter]

CPP version of ray tracer is available
fraction of triggered events = 114/10000 = 0.011 -> 8.07561 km^3 sr
effective volume deviates 2119.7 sigma (3%) from the mean
deviation is more than 3 sigma -> this should only happen in less than 1\% of the tests. Rerun the test and see if the error persists.

what is going on here?