[Yt-dev] Parallel Hop

Matthew Turk matthewturk at gmail.com
Fri Jan 23 11:04:12 PST 2009


Okay, after some off-list discussion, I'm bringing it back here.  I
agree, the differences are not *necessarily* important.  But, they are
dependent on tilings.  I don't like that.

The way I see it, there are a few possibilities here.  But let me
start out by saying, I do not think we should present this unless we
know *where* the differences come from; we should at least have an
idea what's going on.

The HOP algorithm, from my reading of the paper, works in a couple steps.

1. Associate with each particle a density.
2. Trace all particles to 'maximum' density among neighbors; all
particles whose densest nearest neighbor is a given particle are a
"group."
3. Remove all particles below the density threshold.
4. The groups sharing "sufficiently dense" boundaries are re-joined.

So I'd like to identify where in the process the particle results
change.  This will likely -- by necessity -- include some patches to
change the memory structure.  It is not clear to me that identifying
the divergence is a trivial matter.

Stephen, if you could put your data up somewhere, along with the
scripts you used to generate that blog post, we can get going on this
in earnest.

-Matt

PS Are we sure none of this is related to periodicity?  HOP is scale
free, so I would suspect it wraps around the local tile.

On Thu, Jan 22, 2009 at 9:00 PM, Matthew Turk <matthewturk at gmail.com> wrote:
> Hi everyone,
>
> Sorry to pollute the inboxes.  Thing is, I think that maybe I want to
> dial back my enthusiasm.  I think what has been sitting poorly with me
> is that we don't know *why* the particles are disappearing, and where
> they are going.  If they exist within the padding region, then they
> should still show up.  I'm going to run some of my own tests on the
> RD0005-mine dataset you gave me, Stephen, and see what I come up with.
>  I want to figure out *why* it's doing what it's doing.
>
> -Matt
>
> On Thu, Jan 22, 2009 at 5:31 PM, Matthew Turk <matthewturk at gmail.com> wrote:
>> Hi Stephen,
>>
>> Awesome.  I am going to see if I can replicate your methodology over
>> here sometime this weekend, because this is great stuff and it should
>> get written up.
>>
>> Looks like basically the entire analysis workflow is now parallelized
>> -- derived quantities, projections, halo profiling, radial & phase
>> plots, I think even slices, and HOP.  The only major component I see
>> as missing is clump finding, and I have an idea for that, but for now
>> it should be parallelized on the iterate-over-halos level.
>>
>> This is tremendous.
>>
>> -Matt
>>
>> On Thu, Jan 22, 2009 at 5:26 PM, Stephen Skory <stephenskory at yahoo.com> wrote:
>>> All,
>>>
>>>> Could you quantify that a bit, Stephen?  I definitely agree with the
>>>> point about the fuzziness of halo boundaries, but how far off are the
>>>> results when you vary processor count?  If you were to make halo
>>>> catalogs of the same dataset using 1,2,4,8, etc. processors, and then
>>>> compare them (assuming that n=1 processor is the "perfect" solution),
>>>> how far off are the halo centers?
>>>
>>> If you're interested, I've made a parameter-space survey of processor counts and padding, here, with lots of pictures:
>>>
>>> http://stephenskory.com/research/?p=1469
>>>
>>> It's password protected. Contact me off-list if you want it.
>>>
>>> But in summary, I found that parallel hop differs from serial by no more than 1% in absolute particle count, and the change is larger in smaller haloes, which are already vague to begin with. Even for very large objects (relative to the box) a little bit of padding goes a long way, 0.05 is nearly identical to a padding of 0.2. However, padding is still required to get good answers. The centers change by very, very little between serial and parallel.
>>>
>>>  _______________________________________________________
>>> sskory at physics.ucsd.edu           o__  Stephen Skory
>>> http://physics.ucsd.edu/~sskory/ _.>/ _Graduate Student
>>> ________________________________(_)_\(_)_______________
>>> _______________________________________________
>>> Yt-dev mailing list
>>> Yt-dev at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>
>>
>



More information about the yt-dev mailing list