[yt-dev] yt-3.0 parallel_capable

Britton Smith brittonsmith at gmail.com
Tue Apr 22 12:42:50 PDT 2014


Hi again,

I don't know how much this helps, but if I change line 43 of
parallel_analysis_interface.py from parallel_capable = False to
parallel_capable = True, things work as they are supposed to in parallel.
 Could there be an import somewhere that is resetting the value of
parallel_capable?

Britton


On Tue, Apr 22, 2014 at 8:28 PM, Britton Smith <brittonsmith at gmail.com>wrote:

> HI Nathan,
>
> Adding that call did not change the result.  To be clear, this is what I
> ran:
> http://paste.yt-project.org/show/4548/
>
> What is strange is that the logger was clearly set up for parallel as it
> correctly prints the different processor numbers.  Enable parallelism shows
> that parallel_capable is True, so somewhere along the line this is getting
> changed.
>
> Britton
>
>
> On Tue, Apr 22, 2014 at 8:23 PM, Nathan Goldbaum <nathan12343 at gmail.com>wrote:
>
>> Hi Britton,
>>
>> What happens when you call yt.enable_parallelism() at the top of the
>> script?
>>
>> There were some adjustments to the way parallelism works related to
>> YTEP-0019.  See this PR:
>> https://bitbucket.org/yt_analysis/yt/pull-request/729/ytep-0019/diff
>>
>> Do you have a short test script I can try running over here to confirm
>> the issue?
>>
>> -Nathan
>>
>>
>> On Tue, Apr 22, 2014 at 12:20 PM, Britton Smith <brittonsmith at gmail.com>wrote:
>>
>>> Hi all,
>>>
>>> I don't recall when I first noticed this, but I'm finding that the
>>> parallel_root_only decorator doesn't seem to be working.  A simple test is
>>> to run a script that only loads a dataset.  The print_key_parameters
>>> function is inside of a parallel_root_only decorator, so all that should
>>> only be printed by the root processor, but when I run that script in
>>> parallel it is printed by all processors.  I am still looking into this,
>>> but so far I have found that printing the value of parallel_capable inside
>>> this decorator always gives False even when running in parallel.
>>>
>>> Can someone confirm this?  If so, does anyone know what's going on?
>>>
>>> Britton
>>>
>>> _______________________________________________
>>> yt-dev mailing list
>>> yt-dev at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>
>>>
>>
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140422/f9f08f62/attachment.html>


More information about the yt-dev mailing list