Dear Volunteers,

We are beginning to sunset the Separation project (note that this is different from the N-Body project, which still needs your help!!!). Thanks to your computational contributions, we have completed the goals that we set out to accomplish with this the project, so we are going to shut down the Separation project in the near future. We are planning on submitting a paper containing the final results of the Separation project to an academic journal in the near future. It is possible that the reviewer may request revisions that involve re-running Separation data, in which case we might bring it back for a short time, but until that happens we do not need your computer time for this. We would like to sincerely thank you for all the time and effort that you spent helping us complete this substantial task. We owe the success of the project to you all.

With this announcement comes a few updates to MilkyWay@home: MilkyWay@home will continue to exist, but only as the Nbody project. Because of the complexity of running Nbody tree codes on GPUs, there is little speed-up from running Nbody on a GPU compared to an equivalent CPU. Although we did beta-test a full GPU Nbody application, we have decided not to deploy it due to concerns over maintaining its support; among other issues, supporting GPU Nbody would require changing the GPU code every time the CPU code is updated, and making sure every change is tested and works identically on both platforms. Since we are actively working on extensions of the Nbody code that include such things as the effects of the Large Magellanic Cloud's gravity and the consequences of self-interacting dark matter on the formation of tidal streams, this parallel support would be difficult. So, when Separation shuts down, we will be ending GPU support for MilkyWay@home. This will have the greatest impact on people who crunch lots of Separation work units on high-end GPUs; these users can expect to earn a much lower amount of credit per time than they did before. If you contribute only CPU cycles, your ability to earn credit will be unaffected. We still want as many people to contribute CPU time to MilkyWay@home as possible! However, we understand that if your goal is to use GPUs to obtain a large amount of credit quickly, there are more efficient ways to do this and other projects that can better use your resources.

We would appreciate your input on this because we expect that it will probably take some time for GPU-oriented users to swap that hardware over to different projects. How long would you like us to wait before we shut down Separation?

Again, thank you so much for letting us use your processors! They have not only increased our knowledge of the Milky Way galaxy that we live in, but they have also contributed to five PhD theses and trained dozens of undergraduate students to build and maintain large and complex computing systems. These students and I thank you for your contributions. We will be posting the results of the final Separation project results probably later this year, after they have gone through the peer review process (which takes about six months on average, with wide variability).

Best,
Tom & Prof. Newberg

I would just set the shutdown at the deadline after the last task is sent out. That allows the slowest host with too large a cache to get most of the work returned.

Any news or plans for a research paper using the results from the Separation search?

---

. How long would you like us to wait before we shut down Separation?

Best,
Tom & Prof. Newberg

Around 2030. :(

I would not say that the goal of GPU users is to "gain large amounts of credit quickly". that's a pretty large mischaracterization in my opinion.

most, if not all, of us use GPUs because they are massively more power efficient for the work being done. hundreds or thousands of times more work done per watt than CPUs when properly coded/optimized. since most of us pay for our own electricity to donate free compute resources, it makes sense that people will go for a power efficient device.

sad to see the Separation project going away as I personally just came to the project. but I do understand shutting down a project for which there is no longer a benefit. I agree that there's no reason to keep a project up to crunch data that no one will look at just to placate the users.

as far as timeline, in line with my last statement, that's probably best left up to the project scientists rather than the users. we have a lot of bias in that decision and most users will say keep it up as long as possible. the best answer will be to shut it down when YOU are ready and no longer need the results.

---

I would just set the shutdown at the deadline after the last task is sent out. That allows the slowest host with too large a cache to get most of the work returned.

Any news or plans for a research paper using the results from the Separation search?

Yes! We are working on one. It has had a very long lead time, but it's getting done.

I bought much of my hardware with Separation's rather unique FP64 requirements in mind. It's a shame that it is ending.
Is there an expected time frame for tasks to run out?

Hate to say it, but a lot of users will not stay/come back to just run CPU on this project as they are used to what their GPU can do. So expect a large drop off of users after.

However, maybe spend sometime optimizing the N-Body GPU app so that maybe they will stay/come back? Especially if you can find a way to utilize NVDIA CUDA more to bring those users in?

Hate to say it, but a lot of users will not stay/come back to just run CPU on this project as they are used to what their GPU can do. So expect a large drop off of users after.

However, maybe spend sometime optimizing the N-Body GPU app so that maybe they will stay/come back? Especially if you can find a way to utilize NVDIA CUDA more to bring those users in?

You're right, we expect a large drop-off in the number of users.

During our benchmark tests, other GPU N-body codes performed similarly to our GPU code. I don't think that it is an issue with optimization of the GPU code implementation, I think that there is just too much overhead with building the particle tree on the GPU that there is no substantial speed-up compared to running on CPU. It's possible that there are improvements that could be made, but it isn't really a feasible thing to support with our current group and infrastructure.

Hate to say it, but a lot of users will not stay/come back to just run CPU on this project as they are used to what their GPU can do. So expect a large drop off of users after.

However, maybe spend sometime optimizing the N-Body GPU app so that maybe they will stay/come back? Especially if you can find a way to utilize NVDIA CUDA more to bring those users in?

You're right, we expect a large drop-off in the number of users.

During our benchmark tests, other GPU N-body codes performed similarly to our GPU code. I don't think that it is an issue with optimization of the GPU code implementation, I think that there is just too much overhead with building the particle tree on the GPU that there is no substantial speed-up compared to running on CPU. It's possible that there are improvements that could be made, but it isn't really a feasible thing to support with our current group and infrastructure.

is the GPU n-body code on your github page? we have a very competent GPU developer on our team who is great at GPU optimization. we've produced optimized GPU applications for several other projects.

if it's not on your github, would you be willing to share what code you have already so that we can take a look?

---

It is a pity to see separation go , though also nice to know the research will be complete and written up .
But
I have 869 tasks stuck in the database from the January 2021 crash , I am shure there will be many other participants also with stuck tasks , across all participants this could add up to many thousands of work units in limbo .
Half of mine are still `pending` ,
Before the separation work is removed from server could someone have a look to see if anything can be rescued or made useable from them .

Please keep Separation running! I'm willing to contibute hardware that specifically excels in FP64 for the help of the project. It would be a shame if I had to transition elsewhere.. :(

Please keep Separation running! I'm willing to contibute hardware that specifically excels in FP64 for the help of the project. It would be a shame if I had to transition elsewhere.. :(

I don't think you read the reason for shutting down separation. The project has enough data for their research.

Tom,

It's always a bit sad to see a project come to an end, but it's also good to know the goals have been achieved. Well done to all concerned!

Regarding actual shut-down, I'm inclined to agree with Ian&Steve C's comment on the timeline in his first post. Has the current Separation run already reached a point where it's effectively work for works sake, or is there still serious value in processing the rest of this batch? It really has to be your call as to when to stop generating new work :-)

If it's a matter of trying to get the current run to converge as quickly as possible, I'll stick around until that happens (as, I suspect, will many others); otherwise I might as well switch to N-Body only at once, resuming GPU work if and only if you have to do re-runs based on the review process.

Regarding GPU users finding other things to do, I suspect quite a few of us will just give more time to Einstein@home :-)

Good luck with the paper! I'll continue to watch progress on all projects here with great interest...

Cheers - Al.

P.S. there is still the occasional post on the SETI@home site asking when that is going to restart -- expect the same to happen here :-)

Hate to say it, but a lot of users will not stay/come back to just run CPU on this project as they are used to what their GPU can do. So expect a large drop off of users after.

However, maybe spend sometime optimizing the N-Body GPU app so that maybe they will stay/come back? Especially if you can find a way to utilize NVDIA CUDA more to bring those users in?

You're right, we expect a large drop-off in the number of users.

During our benchmark tests, other GPU N-body codes performed similarly to our GPU code. I don't think that it is an issue with optimization of the GPU code implementation, I think that there is just too much overhead with building the particle tree on the GPU that there is no substantial speed-up compared to running on CPU. It's possible that there are improvements that could be made, but it isn't really a feasible thing to support with our current group and infrastructure.

is the GPU n-body code on your github page? we have a very competent GPU developer on our team who is great at GPU optimization. we've produced optimized GPU applications for several other projects.

if it's not on your github, would you be willing to share what code you have already so that we can take a look?

As long as it is not Linux only :)

As long as it is not Linux only :)

It is much, much easier to develop in Linux compared to Windows.

Nothing preventing a good Windows developer from tackling a N-body gpu app.

But no reason to NOT develop an enhanced N-body gpu app for Linux users.

The user always has the option of running Linux.

---

Gee, this is the saddest news of the year so far, I'll never get my big blue star :(

But happy to read that what we did was useful somehow though ;)

Hate to say it, but a lot of users will not stay/come back to just run CPU on this project as they are used to what their GPU can do. So expect a large drop off of users after.

However, maybe spend sometime optimizing the N-Body GPU app so that maybe they will stay/come back? Especially if you can find a way to utilize NVDIA CUDA more to bring those users in?

You're right, we expect a large drop-off in the number of users.

During our benchmark tests, other GPU N-body codes performed similarly to our GPU code. I don't think that it is an issue with optimization of the GPU code implementation, I think that there is just too much overhead with building the particle tree on the GPU that there is no substantial speed-up compared to running on CPU. It's possible that there are improvements that could be made, but it isn't really a feasible thing to support with our current group and infrastructure.

I think if you could bring up the N-Body gpu tasks before you sunset the Separation gpu tasks it would be an easy transfer of resources from one app to the other and the loss of users would be minimal. Getting the data to Ian&Steve's teammate would at least get the Linux side of things up and running pretty quickly and then maybe you guys inhouse could develop the Windows app using his tweaks or reaching out to someone else who has the skillset, perhaps even within RPI itself.

Already disconnected the project from my machines after all available current work completed this evening.

My request is till the end of this year, if it’s possible.

How soon will we know the duration decision (sorry if this has already been answered)?

Ian&Steve C. :

Very well said ...

S-F-V