|
1)
Message boards :
ATLAS application :
ATLAS long simulation 1.00
(Message 44550)
Posted 25 Mar 2021 by Michael Goetz Post: There are/were just a few long tasks in the queue. All is GOOD on your end. There was an ID 10T error. :) I realized something wasn't right when the short Atlas task was running only on one core. I had set that machine to run only on 1 core while trying to get Theory (native) to run on it (before understanding why it didn't, and giving up.) The long tasks won't download with less than 4 cores, so problem solved. My bad! |
|
2)
Message boards :
ATLAS application :
ATLAS long simulation 1.00
(Message 44548)
Posted 25 Mar 2021 by Michael Goetz Post: I think there's still a configuration problem... This is the host https://lhcathome.cern.ch/lhcathome/show_host_detail.php?hostid=10686009 It is an Intel i5-4670K, 4c/4t Haswell CPU, 24 GM memory, running Linux Debian 10 (Buster). It's native Linux, not a VM. I was using it yesterday to successfully run the long ATLAS tasks on the development server. Relevant snippet from the client log: 3/25/2021 10:25:23 AM | LHC@home | Sending scheduler request: To fetch work. 3/25/2021 10:25:23 AM | LHC@home | Requesting new tasks for CPU 3/25/2021 10:25:25 AM | LHC@home | Scheduler request completed: got 0 new tasks 3/25/2021 10:25:25 AM | LHC@home | No tasks sent 3/25/2021 10:25:25 AM | LHC@home | No tasks are available for ATLAS (long simulation) 3/25/2021 10:25:25 AM | LHC@home | Message from server: VirtualBox is not installed (The vbox warning probably isn't important.) There's two things I know are NOT the problem. 1) It's not my preferences, because another computer assigned to the same venue (default) just got a long ATLAS task. 2) I didn't break this computer's configuration after testing on the dev system, because I moved it to running the production short ATLAS tests and it got a task successfully. The only obvious conclusion is that there's something wrong in the server configuration, most likely the plan class. The two machines have different CPUs (Intel vs. AMD), different cores (4 vs 8), and different memory (24 GB vs. 32 GB.) EDIT: Another difference is that the computer that is able to get tasks is a Linux VM running on a Windows host, while the computer that is not able to get tasks is not a VM. Neither system has VBOX installed. |
|
3)
Message boards :
Number crunching :
Badges data
(Message 38463)
Posted 27 Mar 2019 by Michael Goetz Post: Has there been any update to the badge export situation? My badges do not show up either on Bok's site or at https://signature.statseb.fr/. Other people's badges do, so I suspect that the badge stats file (typically badge_user.gz) used to be created but isn't anymore. Are badges being exported? If so, is badge_user.gz the correct filename? |
|
4)
Message boards :
ATLAS application :
Credit doesn't add up
(Message 37708)
Posted 29 Dec 2018 by Michael Goetz Post: Literally. The credit from each task is less than the total credit shown by the host. The host is a VM specifically built to run native Atlas tasks, so it's never run anything else. There's one recent host, visible here: https://lhcathome.cern.ch/lhcathome/show_host_detail.php?hostid=10579492. Notice that as of this writing it has 6565 credits. This is a list of all of the tasks have been run. Nothing's been purged from the database yet. https://lhcathome.cern.ch/lhcathome/results.php?hostid=10579492. As of right now, there's 11 completed tasks, two in progress at the host, and three failed tasks that was me figuring out how to get native Atlas to work. The problem is that the credit awarded totals 3515.85 credits. The host, and my account, seems to get credited with more credit that the tasks are generating. Anyone know why the credit in the host is higher than the credit in the tasks the host has run? It's not anything obvious; the host has run no other tasks (it was just created) and nothing has been purged from the database. |
©2024 CERN