After a summer and autumn of intense development, we are ready to restart the nbody runs. We have updated the code and have working binaries for Linux 64bit, Linux 32bit, Windows 64bit and Mac 64bit. At a later date I will be posting the binary for Windows 32.

Please let us know how the new code is running.

Previous n_body code was labeled 1.00 in mistake, this new release continues the versioning system previously in use and will be version 0.94

Only run Milkyway when running out of work for other projects. After attaching to the project and noticed the following on the N-BODY tasks (System is i7/950, Win7/64-bit, 6Gb ram 1 x EVGA GTX660SC 2Gb, 1 x EVGA GTX460SE 2 1Gb, Nvidia 310.33):

It's really too early for me to tell if there has been any changes. I've only been using BOING Projects since 21st October 2012. I haven't had any noticable situations with M@H so far, except that the Time Remaining Clock has been Counting Upwards instead of Downwards, but this has been happening with other Projects too. I was informed in another Forum that it's Normal because thats the way The Program Works with the Tasks. However, I can't see why it should operate that way. Why would a Countdown Clock Count Upwards. Its like the timer on a Microwave Oven, for example, that has been set for 30 Minutes, but instead of it Counting Down to Zero Minutes, it Counts Upwards and the Remaining Time just gets Increases, as Time Passes By. Thank goodness that we can see that The PROGRESS Colum shows that The Percentage of Work Done is actually Increasing, therefore confirming that the Work unit is being Processed.
Also, the Elapsed Time Clock IS working Correctly, and DOES Increase as expected. So thats another thing that shows that its doing its job.

Anyway, I hope that thee changes you have made work the way you intend them too.
[/code]

Richard Haselgrove asked if some one would copy and paste the following:

Could somebody with posting rights copy the following information to the project's News thread, please? Their message boards are locked up so tight that a new users can't even post an explanation for why their new app isn't going to give them enough credit to post...

0xC0000135 isn't exactly an unknown error - it means 'The application failed to initialize properly'. That's usually a missing DLL - and no, thank you Google, NOT usually the silly 'dot Net' framework.

Sure enough, trusty old Dependency Walker indicates a need for LIBGOMP_64-1.DLL, and the app_version supplied for the app doesn't reference it:

Also, I was expecting this to be a multi-threaded app, and I see _mt at the end of the file name: yet there's no MT plan class, and <max_ncpus> is just 1. If the app itself is going to try to use more cores than BOINC frees for it, that's going to cause major scheduling problems.

The next error, once the DLLs are in place, is usually 0xc0000374 for memory heap corruption. They'll need to go back to code, and see where they're writing outside the bounds of allocated memory, for that one.

Its like the timer on a Microwave Oven, for example, that has been set for 30 Minutes, but instead of it Counting Down to Zero Minutes, it Counts Upwards and the Remaining Time just gets Increases, as Time Passes By.

It's like a timer on an intelligent microwave oven, which checks all the time the temperature of the food and when it sees, that it's not getting warm fast as initially expected, it's telling you it might take longer than expected to get it warm..