Hey All,

I just released a new version of Nbody, 1.60. In this version we completely changed the cost function. This is a function that is used in the histogram comparison algorithm. We discovered that the old cost function, which was supposed to allow us to retain the mass data in the normalized histograms, did not account properly for the amount of mass.

This was not a bug, but rather a change in the science behind the algorithm. We would not have rethought the algorithm without the results from MW@H.

As always, if there is any problem, let me know.

Thank you all,
Sidd

I'm afraid what I'm seeing is 6 hours at a time of multitasking reserving all 4 cores, 8 threads but only using less than 20% of my total CPU.

nope. my mistake. when I exited the BOINC mgr. that process continued...process not completing not the first time i've seen this...

I'm going to have to turn these off till you stop wasting hours of my CPU time.

---

;

Hello Sid,
Reference UID 1028971 Task 1584882935 sent 4 May 20:16:12 UTC
Reported/expired 6 May 4:40:20 UTC on my machine 683929
Task consumed run time 90:487:50 CPU: 337,941.60
This is a 4 month old machine with an Intel i5-6000 3.30 GHz CPU and 8 GB RAM on board.
Hope this helps you. Wisesooth
PS: I did some design work on your GO button. Did Heidi share it with you?

---

Hi,

I get "atos cannot load symbols for the file milkyway_nbody_1.60_x86_64-apple-darwin__mt for architecture x86_64" error on some of the new nbody workunits
http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=1587075175
http://milkyway.cs.rpi.edu/milkyway/result.php?resultid=1586520635

atos seems to be https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/atos.1.html

Killing this one off... Only 6.919% done in 21:39:49 CPU HRS
Running WAY TO SLOW

Name ps_nbody_5_3_16_v160_1_inertia_p95_1461261003_1206610_0

Application	MilkyWay@Home N-Body Simulation 1.60 (mt)
Workunit name	ps_nbody_5_3_16_v160_1_inertia_p95_1461261003_1206610
State	Running
Received	11-05-2016 11:35
Report deadline	23-05-2016 11:35
Estimated app speed	2.25 GFLOPs/sec
Estimated task size	3,402 GFLOPs
Resources	4 CPUs
CPU time at last checkpoint	21:39:49
CPU time	21:43:04
Elapsed time	07:25:17
Estimated time remaining	99:50:36
Fraction done	6.919%
Virtual memory size	41.73 MB
Working set size	42.35 MB
Directory	slots/4
Process ID	3348

---

Task 1591663252 is my current record holder at CPU time 7 days 16 hours 47 min 52 sec

The long run time doesn't bother me in the slightest as long as something useful spit out in the end.

I'm curious as to what these "inertia" units are actually doing though, because their run times vary by huge amounts (some take as little as 30 minutes of CPU time or in this case as long as 7.75 days).

So... what's up with that?

Edit: Actually I found the shortest I've done is 99.21 seconds and the longest is 665,272.70 seconds. :-)

---

Hey,

The inertia runs are meant to help us optimize the optimizer. Our optimizer has a few free parameters we can tune. We are trying to tune them for our unique parameter surface so that we can have our runs converge in a reasonable amount of time.

As for some taking longer than others, that is more a sim parameter issue. The time step is dependent on the simulation parameters. Some of the inertia runs may be exploring our parameter space more than others so they encounter simulation parameters that lead to a longer/shorter run time.

My task, ps_nbody_5_3_16_v160_1_inertia_p95_1461261003_1288901_1, has run for 10 hours and is at 9% with 4 days to go. However, the deadline is 10 hours from now.
Is there any point in continuing it, or should I abort it and let another task run?
Thanks!

Hi,

Since N-Body 1.60 I've had an significant increase in tasks which ended in "Error while computing"

This is one of the examples: