Welcome to MilkyWay@home

Posts by Sidd

21) Message boards : Number crunching : Always immediate segfault on MilkyWay@Home N-Body Simulation v1.62 (mt) (Message 65039)
Posted 17 Aug 2016 by Sidd
Post:
Hey,

Thanks for letting us know. I looked into it and it seems that this workunit ran successfully on other systems. However, on a couple of systems there was max disk usage exceeded errors. I am not sure about why that happened and am looking into it. I think perhaps this was the issue with yours but for some reason threw a different error. It might be due to the difference in operating systems, but I am not sure. I will continue looking into it.

If this continues with other workunits, please be sure to let us know,

Thanks,
Sidd
22) Message boards : News : Nbody Release 1.62 (Message 64769)
Posted 28 Jun 2016 by Sidd
Post:
Hey,

I am not entirely sure. I had a run up until last night but the server may not have been sending out new work units since it was more or less converged. But I will be putting up new runs later today or tomorrow so WU will start flowing soon.

Thanks for your patience!
Sidd
23) Message boards : News : Nbody Release 1.62 (Message 64767)
Posted 28 Jun 2016 by Sidd
Post:
Hey All,

I just released a new version of nbody, v1.62. In this release we did a few things:

We realized that different platforms were giving slightly different results. This was a problem as it would throw off the search algorithm and also may cause validation issues. Turns out there were an number of reasons for this. One was that the likelihood calculation was performed using single precision on a double precision application. So we changed it to be a double precision calculation.

Also, and most prominently, we realized that the windows command prompt and unix terminal read in inputs with different precision. One would cut the value of after about the 10th decimal place. This mean the actual input parameters were slightly different! Therefore, we forced the rounding of the input parameters after the 9th decimal place. That seemed to do the trick mostly.

Finally, we realized that our building mechanism was not building linux binaries statically. When we tried with our current mechanism we ran into a can of worms known as seg faults. It was a nightmare trying to find it so we decided to temporarily switch our building mechanism. I tested them on all our computers and it seems to work. But, as always, let me know if something goes awry.



Thanks everyone for your continued support!
Sidd
24) Message boards : News : Nbody Release 1.60 (Message 64571)
Posted 25 May 2016 by Sidd
Post:
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.
25) Message boards : News : Nbody Release 1.60 (Message 64470)
Posted 14 Apr 2016 by Sidd
Post:
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
26) Message boards : News : Nbody Release 1.58 (Message 64398)
Posted 21 Mar 2016 by Sidd
Post:
Hey All,

I just released a new version of nbody. This one fixes a bug that was found only after instituting the CM correction in the previous release. Let me know if there are any issues.

-Sidd
27) Message boards : News : Nbody Release 1.56 (Message 64364)
Posted 8 Mar 2016 by Sidd
Post:
Hey All,

I just released a new version of Nbody. This updates fixes some library issues we were having. Also, it adds a center of mass and center of momentum correction to the initialization (the added computation time is very negligible). We did this because we found that different seeds would produce a small random initial center of mass position and velocity. While it was not a large difference, we wanted it to be nonexistent.

I will be putting up some runs shortly.

As always, thank you all!
Sidd
28) Message boards : News : Nbody Release 1.54 (Message 64087)
Posted 11 Nov 2015 by Sidd
Post:
Hey All,

I just released a new version of nbody, version 1.54. There are no major changes, just some minor bug fixes. There was a sampling bug in the velocity assignment which caused it to throw away more possible vels than it should. So the initialization is much faster than before. However, the results should be the same. But faster is always better!

Let me know if there is any issues with the new version/binaries.

Thank you!
Sidd
29) Message boards : News : New Release- Nbody version 1.52 (Message 63936)
Posted 18 Sep 2015 by Sidd
Post:
Hey,


That would be an awesome thing to get working. We have been tossing ideas around about how to do it. But it is still, unfortunately, a work in progress.

Also, right now we want to focus on making sure the application can actually return results before tinkering with the code again. But, again, we have that on our to do list!

Cheers,
Sidd
30) Message boards : News : Deprecation of Linux 32bit (Message 63932)
Posted 14 Sep 2015 by Sidd
Post:
Hey,

Thanks for the information. I have already deprecated the 32bit linux version for Nbody.


Cheers,
Sidd
31) Message boards : News : New Release- Nbody version 1.52 (Message 63931)
Posted 14 Sep 2015 by Sidd
Post:
Thank you!

I think it is ok if they run for a while because for those parameters the timestep was probably determined to be a bit small. The real issue is if they hang at 100% for a long time.


Cheers,
Sidd
32) Message boards : News : Deprecation of Linux 32bit (Message 63918)
Posted 10 Sep 2015 by Sidd
Post:
Hey All,

I have some important news. It seems that all of the linux 32bit binaries are failing. These account for 2k of the 70k returned results so far. I do not think it is the binaries that are at fault since I am getting error returns from them (which I wouldn't if it was the binaries failing on startup). It seems that most of the errors are due to outdated libraries from very old versions of linux.

When compiling our binaries, we use the oldest supported version of ubuntu. However, there is still a large user base for versions older than these. A lot of these seem to coincide with linux 32 bit users. Sending out failing workunits would be a waste of extremely valuable volunteer computer time that could be put to use serving other projects. Therefore, we will be deprecating the Linux 32bit version and will not be releasing them in the future.

I thank you all for continuing support,
Sidd
33) Message boards : News : New Release- Nbody version 1.52 (Message 63915)
Posted 9 Sep 2015 by Sidd
Post:
Hey,

Thanks for letting me know. Is it still at 100%? If it remains there for a few more hours I would say cancel it. Can you send me the work unit id or the parameters that went with it?


Thanks,
Sidd
34) Message boards : News : New Release- Nbody version 1.52 (Message 63913)
Posted 9 Sep 2015 by Sidd
Post:
Hey All,

I have released the new version and about to put up runs. Please let me know if there are any problems.


Thanks!
Cheers,
Sidd
35) Message boards : News : New Release- Nbody version 1.52 (Message 63907)
Posted 8 Sep 2015 by Sidd
Post:
Hey all,

We will be rolling out a new version of Nbody, v1.52, within the next 24hrs. I have left such a large time window because, as these things sometimes go, there could be unforeseen setbacks. I will update everyone once we are about to hit the go button (if only we had an actual go button. That would be so cool.)

We are releasing for windows again. I tested the binaries on a windows machine and they appear to be working. But you never know. Therefore, I will be paying very close attention to the forums for weird behavior. Please let us know!

If you would like more details on what is included in this release, check out my development blog:

http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=3798

Thanks everyone for your support
Cheers,
Sidd
36) Message boards : News : Nbody Status Update (Message 63872)
Posted 12 Aug 2015 by Sidd
Post:
Hey All,

I just posted a new blog post. Check it out:

http://milkyway.cs.rpi.edu/milkyway/forum_thread.php?id=3798

Cheers,
Sidd
37) Message boards : Application Code Discussion : Dev Blog: Siddhartha Shelton (Message 63871)
Posted 12 Aug 2015 by Sidd
Post:
Hey All,

Sorry for the long delay in posting an update. So lets just jump right in. (Also, apologies if I start getting a bit too detailed.)

Disclaimer: the plots shown here are most likely not in a publishable quality/format (would have to better label things like axis and titles, etc). I am including them here only to give an idea of what I am working on.

I mentioned in the last blog post that the distribution matches the radial distribution. In 3d space, we need 3 coordinates. In our code, we assign radii to our particles by sampling the density distribution we want, in this case a plummer sphere. We also assign angles, the azimuth and polar angles from spherical coordinates. From these angles are are able to calculate the required x,y and z coordinates for that particle. We have checked these distributions and they match theory. These are picture below. The particle distributions are binned in the histogram and the theoretical distribution is shown with a line.



Above are the initial distributions for a two component dwarf separated into its light and dark components. The binned data is from the simulation and the curves are theoretical distributions.



Above are the initial spacial angular distributions for the combined two component sphere.


We then tried to do the same with the velocity distribution. As I mentioned in the last post, this is especially important. If the velocities are assigned too high, the particles go flying off into space. If they are assigned too low then they collapse into the center of the sphere. So we definitely need to make sure they match theory. One small problem, we do not know what the theory curve looks like.

In order to remedy this, we look at special cases. Our code right now allows us to produce a two component plummer sphere. However, in the special case, one of those spheres has 0 mass and no particles are assigned to it. Therefore, using the 2 component structure, we produce a 1 component sphere. How does this help?

In order to assign velocities, we sample something known as the distribution function. This function is very complicated. This function allows us to find the probability of finding a particle at a particular location and velocity by integrating it over space and velocity. Therefore, if one were to integrate it over all space and over all velocities you should get 1 (or 100% probability), since we know the particle exists and is somewhere with some velocity. The general version of this equation involves an complicated integral shown below:


Above is the distribution function. The epsilon in the integral limit and integrand denominator is the energy of the particle. The rho is the density distribution we are using, and psi is the potential. These are shown below:


Where the a's are scale radii for the light and dark components, the M's are the masses of those components, G is the gravitational constant, and r is the radii.


We cannot solve this analytically because of our two component model. However, for a single component plummer sphere, the integral is readily solved and can be found in various texts. Therefore, we test our code by having it produce a single plummer sphere and comparing it to a single component model. In fact, doing this opens a new realm of testing.

Here is the single plummer distribution function:




The first set of tests, before anything else, was to make sure we are calculating the integral correctly. In order to solve the integral, we expand the integrand in terms of r. For the limits, we find the radius at which the potential is equal to that energy (using a root finding algorithm. Originally written by Jake Weiss). Therefore, the integral is actual a function of r and v of the particle and is integrated over r' as shown below:



The first test of the integral is to hold v constant and alter r and calculate the integral. Then compare it to the single component equation when doing the same thing. This is shown below:


The red curve being the one calculated from our two component model
The next test was to hold r constant and alter v. This is shown below. Again, red is our two component model.


Originally, the two curves, calculated and theoretical did not quite fit. This was because of the integration function we were using as well as the form of the integrand. The integrand has a singularity in the denominator. As the curve moves away from the singularity, it quickly tends to zero. We wanted this section of the integral to be calculated more accurately. Simply increasing the resolution of the integral solved the issue but made the initialization procedure extremely lengthy. Therefore, we decided to put in an adaptive resolution so that the integral would be calculated very accurately where the integrand "mattered" and not as accurately where it was practically zero. This led to a decent initialization time (about a minute to 2 on my laptop) and the above plots.

Below is a plot of the integrand. The part that is actually integrated is to the right of the spike:


Finally, back to the velocity distributions. First off, just to quickly get them out of the way, we were able to match the velocity angular distributions to theory:





Testing the velocity distribution was a bit more complicated. Since we know the single plummer distribution function, we can create a sample set of velocities by sampling that equation. We can then compare that distribution to the one created from our two component model (remember, it is still being used to generate a single component sphere, so they should match within random seed differences). We were able to see that they match:


The histogram is our calculated distribution and the green line is the test distribution.


As for the potential I mentioned in my last post, we were able to find multiple things. What we were looking to do was match a theoretical value of the total potential energy of a two component plummer sphere against what we actually calculated. I do not have plots for these, but we were able to find that the theoretical values did closely match what we get from our generated particles. To be more specific, we calculated the total potential energy using the following method:

The first term after the equal sign is the normal method of calculating the total potential energy of a group of particles. By changing this into an integral, we can use our theoretical distributions.


Finally, we were able to (and was actually the first thing done after the last post) to get the virial ratio to be equal to 1. We calculated this ratio two ways. In both ways we calculated the total kinetic energy by summing over the kinetic energy from each particle. In the first way, we calculated the total potential energy using the following method:

This takes the mass of each particle and multiplies by the theoretical potential we are using to calculate the potential energy.

The second method uses:

This uses the classical method of calculating the potential energy, by calculating the total potential energy each particle gets from every other particle (and divided by 2 to compensate for double counting).

Thankfully, both methods yielded the same answer, and the virial ratio, 2K/U, was found to equal 1 which is what we want for an object in virial equilibrium.


So, now we know everything is being initialized correctly. However, we want to make sure they stay that way. Therefore, we replot each of the above plots over time. (My code that does this stability test produces 112 plots, all of which are useful!). Ideally, all of the distributions would stay mostly the same over time. We find that the angular plots do. However, the radial plots show a tiny bit of movement:


Here are the radial plots initially, after 1gy and 4gy of run time:





and the velocity distribution:





As you can see, there was some movement at 1gy. The movement was a bit worse previously which was due to two things. The first was that some plummer sphere mass and radii parameters are intrinsically a bit unstable. The second was that the parameters being sent into the calculation of the time step were being sent in incorrectly. After these two things were remedied we are able to get the above stability plots. However, this is still too unstable for our liking.

What we are currently looking at is if the timestep equation is correct. We are comparing this against established code such as NEMO, which has the ability to create a single plummer sphere and evolve it. However, I do not believe it will be much longer before we are able to release a new version of NBODY.

Sorry for the long post. I do not have any potatoes for you. Also, I did not check the grammar, so forgive me for any errosr.

--
Cheers,
Siddhartha Shelton
38) Message boards : News : Nbody Status Update (Message 63800)
Posted 14 Jul 2015 by Sidd
Post:
Hey,

Thanks a ton! Yep, I can tell you we are definitely concerned. But most likely we will have to wait and see. The actual code itself should still work, its all the other things, like compiling and getting it running on client computers, that may be affected. But as it is, we use an windows XP machine to compile our code for windows which allows for a wider range of volunteer machine use. Hopefully, things will still be compatible. But, again, we will have to wait and see.


Cheers,
Sidd
39) Message boards : Application Code Discussion : Dev Blog: Siddhartha Shelton (Message 63782)
Posted 30 Jun 2015 by Sidd
Post:
Hey all,

Here is a run down on the things I have been working on. Pretty much I have been unit testing the initialization code. I have been matching everything generated to theoretical quantities. I will put up some plots next time around of my fits. But so far I have been able to fit the radial and angular distributions. This means that the particles are being placed in the correct place.

What I am currently working on is fitting the potential and the velocities. These are especially important because if they are off, then the evolution of the particles will be wrong.

We want our dwarf galaxy to be in virial equilibrium. Mathematically speaking, we want the total kinetic energy and potential energy of all the particles to follow: 2K/P = 1 where K is the total kinetic and P is the total potential energy. Thus, if the particles have bad velocities they would not be in virial equilibrium, i.e. the ratio will not equal 1.

I am close in fitting the potential, but it is not exactly matching the theoretical value. So there is work to be done on that front.

Also, I am working on a way to test the velocities as well, so that is also a work in progress.


I think it is funny to note that my test codes combined is now longer than my dwarf initialization code.

More to come soon.

Cheers,
Sidd
40) Message boards : News : Nbody Status Update (Message 63771)
Posted 25 Jun 2015 by Sidd
Post:
Hey All,

Just a quick update on the status of Nbody. I discovered that the hanging that people were experiencing were due to the Newton Raphson root finding algorithm which would get stuck in an infinite loop. After looking for why this occurred for sometime, I decided to switch to a bisection method which is insured not to get stuck.

The slow nature of the initialization of the plummer was found to be an error in the calculation of one of the limits of integration in a crucial integral that was being calculated. What a time it was finding that! With that limit fixed, it seems that the initialization takes a few seconds!

I am currently unit testing the code and hopefully should get a lovely new version in a couple of weeks.

Cheers,
Sidd


Previous 20 · Next 20

©2024 Astroinformatics Group