Development for LHC@home

For a better understanding you may look at the mcplots pages.
Mcplots is the backend system feeding LHC@home's Theory queue.
http://mcplots-dev.cern.ch/production.php?view=control

We are currently working with revision 2390, hence click on "coverage" of that line:
http://mcplots-dev.cern.ch/production.php?view=revision&rev=2390

"Runs summary" mentions a total of 70981 runs.
Each run represents a complex combination of an event generator and a set of input parameters and subroutines to be used.
To fulfil your request, each volunteer would have to select his preferred jobs out of a list with 70981 entries.
This selection table would have to be changed for every new revision and somebody would have to explain it.


The "Jobs run time" histogram and the data behind (click on the histogram):
It shows that by far the vast majority of jobs finish within a few hours (even minutes)

For a better understanding you may look at the mcplots pages.
Mcplots is the backend system feeding LHC@home's Theory queue.
http://mcplots-dev.cern.ch/production.php?view=control

We are currently working with revision 2390, hence click on "coverage" of that line:
http://mcplots-dev.cern.ch/production.php?view=revision&rev=2390

"Runs summary" mentions a total of 70981 runs.
Each run represents a complex combination of an event generator and a set of input parameters and subroutines to be used.
To fulfil your request, each volunteer would have to select his preferred jobs out of a list with 70981 entries.
This selection table would have to be changed for every new revision and somebody would have to explain it.


The "Jobs run time" histogram and the data behind (click on the histogram):
It shows that by far the vast majority of jobs finish within a few hours (even minutes)

Unfortunately my tasks don't do that running 6 hours or more with the 9 day deadline increasing with every update. I am trying to catch them early but they often run for 3 or more hours with a completion percentage of around 0.655 percent with 9+ days, and increasing, remaining.

I am one of those people on the News who is between homes because they took the money out of the old one but the new one isn't finished being built yet. YES I absolutely would do it again, I'm currently saving over $1k per month and for 3 months was saving over $3k per month as I stayed in a timeshare for 90 days straight. BUT it means I'm on a couple of laptops and an older Mac desktop, and sometimes some Raspberry Pi's, so my crunching thru-put has been severely downgraded from 15+ desktops all with gaming level, albeit older now, gpus.

I appreciate the response and now understand the problems what I was asking for would create, I will just keep aborting them then until I get my next target and then move on to something less computationally intense until I can get my desktops back up and running again.

Unfortunately my tasks don't do that running 6 hours or more with the 9 day deadline increasing with every update. I am trying to catch them early but they often run for 3 or more hours with a completion percentage of around 0.655 percent with 9+ days, and increasing, remaining.

It appears that you are looking at the progress data presented by BOINC.
Those are only accurate if you have lots of tasks with nearly equal runtimes.

In case of Theory the runtimes vary between a few minutes and a couple of days which causes the BOINC estimates to be a complete fake.


Most (but unfortunately not all) Theory tasks deliver the number of completed events in their internal logfiles.
This logs are accessible if you select the task in BOINC manager and click "show graphics".

First you may check the running.log's timestamp.
If this is much older than, say, half a day the task may stuck in an endless loop and should be cancelled.

Then check the content of the running.log
It's first line corresponds with the info given in stderr.txt, e.g.:

cranky: [INFO] ===> [runRivet] Sat Sep  4 05:21:14 UTC 2021 [boinc pp jets 7000 250 - pythia6 6.428 z2 100000 198]

The next to last value (here: 100000) shows how many events are to be processed.
At the end of the logfile you find the number of completed events.

Together with the task runtime from BOINC you can now calculate the ratio events/second which allows you to estimate the runtime left.
It has to be done manually since BOINC can't access the task internal logfiles.

Sherpa tasks often present time estimates of a few thousand days in the future.
This may also be a fake.
Here you may repeat the check after a few hours.
Cancel them if the sherpa estimation has increased between both checks.


In case the manually calculated ETA can be reached before the task's due date the task should not be cancelled.

Have prepared vboxwrapper 200 (from Cosmology@Home) to test it with Theory - OS Win11pro.
Waiting atm for a new task. https://lhcathomedev.cern.ch/lhcathome-dev/show_host_detail.php?hostid=3452

Have prepared vboxwrapper 200 (from Cosmology@Home) to test it with Theory - OS Win11pro.

I already tested vboxwrapper 26203 on LHC@home (production server) for ATLAS, CMS and Theory.
Just started 2 Theory tasks here @LHC-development. (Windows 10)

This is Teamwork, but for me:
14.12.2021 11:36:35 | lhcathome-dev | Scheduler request completed: got 0 new tasks
14.12.2021 11:36:35 | lhcathome-dev | No tasks sent
14.12.2021 11:36:35 | lhcathome-dev | No tasks are available for Theory Simulation
14.12.2021 11:36:35 | lhcathome-dev | Project requested delay of 61 seconds
Some tasks from WCG and LHC@Home (Atlas) are running for the moment, so waiting.....

Have prepared vboxwrapper 200 (from Cosmology@Home) to test it with Theory - OS Win11pro.
Waiting atm for a new task. https://lhcathomedev.cern.ch/lhcathome-dev/show_host_detail.php?hostid=3452

First Theory with vboxwrapper 200 is running. No SHERPA ;-)
Edit:45,2 from 47,9 GByte RAM in use.
Don't know why, because Theory is using less than 1 GByte.

2021-12-14 12:34:30 (9836): vboxwrapper (7.9.26200): starting
2021-12-14 12:34:30 (9836): Feature: Checkpoint interval offset (588 seconds)
2021-12-14 12:34:30 (9836): Detected: VirtualBox VboxManage Interface (Version: 6.1.30)
2021-12-14 12:34:33 (9836): Setting CPU Count for VM. (1)
2021-12-14 15:49:35 (9836): Guest Log: 15:49:29 CET +01:00 2021-12-14: cranky: [INFO] Container 'runc' finished with status code 0.

2021-12-14 17:39:41 (8688): Detected: vboxwrapper 26202
2021-12-14 17:39:41 (8688): Detected: BOINC client v7.16.20
2021-12-14 17:39:41 (8688): Detected: VirtualBox VboxManage Interface (Version: 6.1.30)
2021-12-14 17:39:43 (8688): Setting CPU Count for VM. (1)
2021-12-15 03:21:22 (8688): Guest Log: 03:21:06 CET +01:00 2021-12-15: cranky: [INFO] Container 'runc' finished with status code 0.
Both vboxwrapper (200 and 203) working with Win11pro.