LHC@home

Hi team,

is there any clue why I am crunching tasks in 10 secs?

I checked workunit and "other" computer also did the same...

By doing this, I ran out ot tasks and run dry for some hours, not good for the science :)

---

IIRC from different posts in 2017 CERN simulates lots of different parameter sets for beam control with sixtrack.
Very short runtimes normally mean that the beam would be unstable with this particular parameter set.
Thus short runtimes do have an important meaning for science.

Unfortunately BOINC has some problems by design with highly variable runtimes and it has to decide whether to overcommit a computer or leave it idle sometimes.
As idle is better than overcommitment, this is the default.

Good question. I would be interested in an answer by the team as well. I might be able to explain it, but I can't say without doubt.

I'll just say, as a fellow volunteer I can only assure you that this is normal, not an error. In addition to the underlying scientific causes, there is some difficulty to estimating GLFOPS (and by extension run time). E.g. I currently have several WUs that were estimated to take just minutes to crunch, but actually took several hours.

Here is the background to the project

http://lhcathome.web.cern.ch/projects/sixtrack/sixtrack-and-numerical-simulations

Hi all,

thanks for asking the question. SixTrack tasks are meant to estimate the stability of the beams for different configurations of the simulated machine (in general, LHC and its upgrade, HL-LHC, but also other accelerators in the near future). The parameter space is huge, as we have to scan not only the phase space of the beam, but also all the main knobs affecting the non-linear beam dynamics. ... and this is done for each optics configuration of the studied machine (that's how we call the linear part of the machine, which can be simulated pretty easily, even on a laptop).

As already mentioned by computezrmle, the stability of a given region of phase space is not known a priori - that's why we need to send out tasks on BOINC, and your help is precious! Depending on the values of the scanned parameters, the same particle can be subject to stable motion (hence, it will remain in the beam for long times, and similarly in your simulations!) or can be subject to chaotic motion, with its unavoidable loss, eventually.

In order to guess/check that the short length of a task is due to physics and not to an error, please have a look at the name of the task. Let's take for instance a tasks I have recently crunched:

w-c1_job.B1inj_c1.2158__54__s__64.28_59.31__9.1_10.1__6__12_1_sixvf_boinc56708_1

study name:

w-c1_job.B1inj_c1.2158

random seed (most of the times, we run a little monte carlo to see the effect of unavoidable magnetic field errors in magnets):

__54__s__

machine tune (an indication of the machine configuration, linear part of the dynamics):

64.28_59.31

amplitude of beam "phase space" currently scanned:

__9.1_10.1__

number of tracked turns (actually, its exponent, eg 10^6):

__6__

angle of beam "phase space" currently scanned:

__12

In general, a scanned amplitude below 6 or 7 is stable, whereas above 14 is will almost surely be unstable. Anyway, numbers are not cast in stone, and there might be configurations of the non-linear part dramatically affecting particles at small amplitudes.

Hope it helps!

Not OP, but thank you for the explanation!

Can you tell us something about WUs titled BOINC_Errors?

Edit: Also wanted to thank you for your recent moderation. Don't hesitate to lock duplicate topics. Thank you!

Those WUs are from a study on beam-beam effects (i.e. effects on non-linear beam dynamics due to beam-beam collisions and/or parasitic encounters), taking into account also errors in magnetic fields.
Cheers,
A.