Hello Milkyway@Home,

As you may or may not know I'm a new scientist working with BOINC. Basically what I'm doing is picking up where Nate left off. Nate sucessfully used this Maximum Likelihood algorithm to plot out the location and characteristics of the Sagittarius Dwarf Tidal Stream as it flows through the Milky Way.

The maximum likelihood code was built to run on SDSS (http://www.sdss.org/) data which is organized into 2.5 degree wide slices of sky. The orientation of the slices in 3D space is determined by the number of the stripe in the SDSS survey. As such-- the objects we study are positioned haphazardly inside the stripes, obliquely angled as it were. We are of the opinion that if we could transform these stripes so that they are permendicular to the stream we would enable the program to calculate more accurate results.

So we looked to a paper by scientist Stephen Majewski (http://arxiv.org/abs/astro-ph/0304198) in which a coordinate system was described with the plane of the Sagittarius Dwarf debris being the equator. After transforming our standard spherical coordinates into the Sagittarian spherical coordinates, we took slices of the sky along longitudinal lines that are the same shape as SDSS stripes. Since the Sagittarius Stream is on the equator in these new coordinates, each longitudinal slice contains a perpendicular cross section of the stream by definition.

<>
http://i698.photobucket.com/albums/vv346/vickej2/13ii.jpg?t=1243962157
http://i698.photobucket.com/albums/vv346/vickej2/35ii.jpg?t=1243962176
<>

After a little coding, viola, the program can calculate the exact same code using Sagittarius Geometry as well as SDSS geometry. The only difference is the algorithm for how the stripe number relates to actual position in 3D space.

Last night with Travis' help, I started I believe 5 runs: ps_sgr_208_1 - ps_sgr_208_5. These 5 runs are of stripe 208 (any stripes above 200 denote sagittarius stripes, so stripe 200 is sagittarius stripe 8). You can easily tell if you are working on a Sagittarius stripe by looking in the parameter file and checking the "sgr_coordinates:" flag. 0 denotes SDSS geometry, 1 denotes SGR geometry.

These runs are in a very controversial part of the experiment. Basically in this section of sky we are getting two different minima: one with the stream pointing toward the sun, and one with it pointing tangentially to the sun. This is a big topic of debate not only in our RPI research group, but in the astrophysics society as a whole. Hopefully with my new and improved cross sections some more light will be shed onto this area of the sky.

<>
http://i698.photobucket.com/albums/vv346/vickej2/sky.jpg?t=1243962135

I look forward to working together,
John Vickers

P.S. I see a thread relating to the ps_sgr_208_test and the GPU application. I am fairly sure that Travis mentioned that the GPUs would have problems with the SGR geometry change when we were talking last night. The CPU applications seem to be running it correctly though. Apologies for the inconvenience.

Hello John!

A warm welcome to the boards, and thank you for a very informative introduction. We look forward to hearing more from you :-)

---

Don't drink water, that's the stuff that rusts pipes

I see a thread relating to the ps_sgr_208_test and the GPU application. I am fairly sure that Travis mentioned that the GPUs would have problems with the SGR geometry change when we were talking last night. The CPU applications seem to be running it correctly though. Apologies for the inconvenience.

I thought it was only a problem with extremely small WUs for a ps_sgr_208_test batch (taking only some fraction of a second to compute). At least Travis has not indicated any general problem:

yeah, ps_sgr_208_1 is still running (and fine AFAIK), but i stopped the bad _test one has stopped and there shouldn't be any new WUs for it.

As the coordinate transformation is done on the CPU also with the GPU version (and it is using the same code for that) I really wonder why there should be a problem. The GPU version was SGR coordinate capable since day one, as Travis/Nate/whoever put that gcToSgr and sgrToGal routines in the legacy code before. I think it was version 0.04 (for CPUs) or something like that adding support for SGR coordinates. If there wasn't a bug in that early version (0.07 was the base to create the GPU version), it should run flawless on GPUs too.

I just had a look, at least the SGR WUs don't crash and one one also gets credits for it (i.e. the outlier detection does not kick in, whatever that means).

Name ps_sgr_208_1_181499_1243961905_0
[..]
Outcome Success
[..]
stderr out <core_client_version>5.10.28</core_client_version>
<![CDATA[
<stderr_txt>
Running Milkyway@home ATI GPU application version 0.19e by Gipsel
CPU: AMD Phenom(tm) II X4 940 Processor (4 cores/threads) 1.41665 GHz (202ms) [C&Q at work ;)]

CAL Runtime: 1.3.145
Found 1 CAL device

Device 0: ATI Radeon HD 4800 (RV770) 512 MB local RAM (remote 28 MB cached + 256 MB uncached)
GPU core clock: 750 MHz, memory clock: 400 MHz
800 shader units organized in 10 SIMDs with 16 VLIW units (5-issue), wavefront size 64 threads
supporting double precision

1 WUs already running on GPU 0
Starting WU on GPU 0

main integral, 160 iterations
predicted runtime per iteration is 62 ms (33.3333 ms are allowed), dividing each iteration in 2 parts
borders of the domains at 0 504 1000
Calculated about 1.53283e+012 floatingpoint ops on GPU, 4.08581e+007 on FPU. Approximate GPU time 10.9531 seconds.

probability calculation (stars)
Calculated about 5.61279e+008 floatingpoint ops on FPU.

WU completed.
CPU time: 0.5625 seconds, GPU time: 10.9531 seconds, wall clock time: 33.609 seconds, CPU frequency: 2.99058 GHz

</stderr_txt>
]]>

Validate state Valid
Claimed credit 0.0634811906523444
Granted credit 11.50045
application version 0.19

Yeah the SGR search seems to be running fine (I figured you were doing the coordinate conversion on the CPU so it wouldn't be an issue). The other search that had a problem was because the integral size was very small, nothing to do with using the SGR coordinates.

---