LHC@home

I am playing with WUs to be crunched with sixtracktest. In particular, in the last batch of jobs submitted last week, the discrimination between successful and un-successful results was a missing setting in the template output .xml file.

Now the next batch of jobs (34) is aimed at verifying that we can collect more data then the usual output we get back from you.

Thanks a lot to everyone supporting sixtracktest!

Yes indeed, but some may miss the deadline but won't cost you. Eric.
(I have the same problem!)

---

I got one sixtracktest task last night. Here: https://lhcathome.cern.ch/lhcathome/result.php?resultid=151408364
This failed for me and for two other hosts so far with error:

upload failure: <file_xfer_error>
  <file_name>wTest_madxCode_withCC__1__s__26.13_26.18__4_6__4__85_1_sixvf_boinc34_2_1</file_name>
  <error_code>-131 (file size too big)</error_code>
</file_xfer_error>

---

Seems to be a problem probably with the result template/xml.
The result probably is too big but I don't see any "nbytes"...
I'll leave this to my colleagues. Eric.

I got one sixtracktest task last night. Here: https://lhcathome.cern.ch/lhcathome/result.php?resultid=151408364
This failed for me and for two other hosts so far with error:

upload failure: <file_xfer_error>
  <file_name>wTest_madxCode_withCC__1__s__26.13_26.18__4_6__4__85_1_sixvf_boinc34_2_1</file_name>
  <error_code>-131 (file size too big)</error_code>
</file_xfer_error>

---

I see the same results on my computers, my mac even got one :)

9.Mac

118 LHC@home 07/18/17 05:09:03 Output file wTest_madxCode_withCC__1__s__26.13_26.18__4_6__4__85_1_sixvf_boinc34_3_1 for task wTest_madxCode_withCC__1__s__26.13_26.18__4_6__4__85_1_sixvf_boinc34_3 exceeds size limit.
119 LHC@home 07/18/17 05:09:03 File size: 20866468.000000 bytes. Limit: 20000000.000000 bytes

Thanks a lot, Toby, Eric, and Harri, for the very valuable feedback! It was essential to spot the actual problem!
Indeed, it is an issue of maximum size of the result file as described in the template file of the sixtrack output.

One of the new features of the new exes (sixtracktest) is the possibility to produce further output than the one strictly required for evaluating the dynamic aperture - eg for frequency map analysis, bunch evolution during tracking, ... This is collected in a second output file, of variable size. Initially it was set to 20MB, but the test I was submitting required slightly more - I have increased it by a factor 10.

First results have been already produced and successfully uploaded, eg:
https://lhcathome.cern.ch/lhcathome_ops/db_action.php?table=workunit&id=73333800
Many many thanks to all you!

Some validated sixtracktest tasks finally, here's one: https://lhcathome.cern.ch/lhcathome/result.php?resultid=153267772
Very short though, around 20...25 seconds each.

---

That sounds encouraging. I'll be submitting myself once I have figured
out how to do it. I think we try and keep tests short to avoid wasting the
volunteer CPU, we are testing some SixTrack or other system functionality.
However, I want to try going for 10 million turns, a first, by running a series
of 100,000 turn tasks, and I want to see the growth in the Checkpoint/Restart
file size and the network activity. Eric.

Some validated sixtracktest tasks finally, here's one: https://lhcathome.cern.ch/lhcathome/result.php?resultid=153267772
Very short though, around 20...25 seconds each.

---

Dear all,

just to let you know that finally all tests performed so far on sixtracktest are successful! I think we will see soon new exes being released for production!

The tests were pretty small, to check that all new features were working properly, and the necessary adjustments to BOINC settings (eg template output) were applied. At the same time, it was possible to better track problems and have a negligible impact on the credit granted to you, in case of failures at different stages of processing.

Thanks again to all you who contributed with these tests!
Alessio, for the SixTrack team.

Great news

I just received 15 new sixtracktest tasks, they went back in the queue behind 17 sixtrack tasks. Let's see how they perform.

---

Great; I can now run on sixtracktest thanks to my colleague Alessio.
There will be many more to come as I need statistics and error analysis
for my upcoming paper. Just meed to check results first. Eric.

I just received 15 new sixtracktest tasks, they went back in the queue behind 17 sixtrack tasks. Let's see how they perform.

---

Great; I can now run on sixtracktest thanks to my colleague Alessio.
There will be many more to come as I need statistics and error analysis
for my upcoming paper. Just meed to check results first. Eric.

I just received 15 new sixtracktest tasks, they went back in the queue behind 17 sixtrack tasks. Let's see how they perform.

First tasks have finished OK, took about 40 minutes each. Waiting for the quorum partner to finish their bit.

---

had about 60 sixtracktest, all still waiting for validation (wingman), but no errors were reported (on windows and linux).

what i recognized is that compared to the "production sixtrack tasks" they need roughly 5-8 times more ram per task (also on windows and linux).

Very good; your comment on memory is correct. My colleagues are
trying to use a "big" version to limit the total number of versions.
I am hoping that the working set size will be as before and that there will not be
excessive paging. Eric.

had about 60 sixtracktest, all still waiting for validation (wingman), but no errors were reported (on windows and linux).

what i recognized is that compared to the "production sixtrack tasks" they need roughly 5-8 times more ram per task (also on windows and linux).

---

I got several sixtracktest tasks on different systems: Linux64, Win7 64bit, Win10 32bit.
All tasks are running fine and meanwhile some are reported back.
On Windows I do not see the 10-60 minutes low cpu-usage init phase anymore.

One issue: On one Win7 64bit machine I first got a bunch that should run the 32 bit application. I don't know if that could be a performance problem.
The last 4 tasks I got were assigned with the 64bit application.

I got some sixtracktest WUs on both of my hosts.

i7-2600:
lin64 version (as expected)

i7-3770K:
lin32 version (should have been lin64)

Both BOINC clients are configured to accept alternative platforms so that may be the reason for the mismatch.

<edit>
Oops:
The lin64 walltimes on the i7-2600 are very short.
https://lhcathome.cern.ch/lhcathome/results.php?hostid=10486393&offset=0&show_names=0&state=0&appid=10
This may be investigated.
</edit>

Thanks a lot; I was about to ask if the "real time" problem
had gone away on Windows 10! Great news. Eric.
(More news tomorrow.)

I got several sixtracktest tasks on different systems: Linux64, Win7 64bit, Win10 32bit.
All tasks are running fine and meanwhile some are reported back.
On Windows I do not see the 10-60 minutes low cpu-usage init phase anymore.

One issue: On one Win7 64bit machine I first got a bunch that should run the 32 bit application. I don't know if that could be a performance problem.
The last 4 tasks I got were assigned with the 64bit application.

---

https://lhcathome.cern.ch/lhcathome/results.php?hostid=10480067&offset=0&show_names=0&state=6&appid=
https://lhcathome.cern.ch/lhcathome/results.php?hostid=10317541&offset=0&show_names=0&state=6&appid=10

sixtracktest v46.15 (sse2)
windows_x86_64

At line 2515 of file C:/msys64/home/kyrsjo/code/SixTrack/SixTrack/SixTrack_cmakesix_API_BIGNBLZ_BOINC_BUILD_TESTING_CR_LIBARCHIVE_defaultcompiler_defaultbuildtype/sixve.f
Fortran runtime error: Bad integer for item 1 in list input

sixtracktest v46.15 (sse2)
windows_intelx86

At line 2515 of file C:/msys64/home/kyrsjo/code/SixTrack-32bit/SixTrack/SixTrack_CMAKE_SHORTNAME/sixve.f
Fortran runtime error: Bad integer for item 1 in list input

Hello Sergey,

thanks for reporting these errors. We will investigate the issue (suspect a problem of input).

As volunteer, I got 16 sixtracktest tasks, on both windows and linux - all ok for the moment:
https://lhcathome.cern.ch/lhcathome/results.php?userid=384669&offset=0&show_names=0&state=0&appid=10

For the larger memory footprint, we are extending the capabilities of SixTrack also in view of way larger machines than the LHC, e.g. the Future Circular Collider (FCC), and we have quite some colleagues waiting to use the new version of the code, with a lot of brand new tasks for the next years. Hence, the idea to simplify things with only one version of the exe.