dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

On 21/02/11 20:36, Johan Hake wrote:
> On Monday February 21 2011 12:31:18 Garth N. Wells wrote:
>> On 21/02/11 18:00, Johan Hake wrote:
>>> On Monday February 21 2011 08:18:18 Garth N. Wells wrote:
>>>> On 17/02/11 21:28, Johan Hake wrote:
>>>>> Hello!
>>>>>
>>>>> I have a not so large 3D mesh of some 50K vertices, generated from some
>>>>> geometry (not UnitCube).
>>>>>
>>>>> When I set
>>>>>
>>>>>   parameters.num_threads = 2
>>>>>
>>>>> and try to assemble I just get:
>>>>>   Coloring mesh.
>>>>>
>>>>> and then it seems it wont find a solution... I had to break it because
>>>>> it nearly hang the computer for some 5 min.
>>>>>
>>>>> Have anyone experience the same? Is there any way to controll the
>>>>> coloring?
>>>>
>>>> It's had minimal testing, so issues can be expected. Can you post your
>>>> solver? 50k vertices is not very big, so I would expect it to be pretty
>>>> fast.
>>>
>>> Yes I would expect that too. I have used the coloring on other meshes
>>> with success.
>>>
>>> The mesh can be downloaded from here:
>>>   <http://folk.uio.no/hake/trouble.xml.gz>
>>>
>>> To reproduce the trouble just run:
>>>   from dolfin import *
>>>   mesh = Mesh('trouble.xml.gz')
>>>   V = FunctionSpace(mesh, "CG", 1)
>>>   assemble(Function(V)*dx)
>>>   parameters.num_threads = 2
>>>   assemble(Function(V)*dx)
>>>
>>> The mesh has two distinct domains, but that shouldnto be causing the
>>> trouble, as other I have successfully colored other such meshes. I guess
>>> it can be the particular mesh that causes coloring to stall. It is
>>> generated using tetgen.
>>
>> I don't think that I've tested multi-threaded assembly for functionals.
>>
>> When we get around to implementing it, assembling functionals shouldn't
>> require colouring. It should just involve OpenMP parallelising the
>> assembly loop, and then each thread adds its contribution to the result
>> once it's processed its bunch of cells (while avoiding a race condition).
> 
> I just used a Functional so I could stick with a shorter example ;)
> 
> The above code works fine with another mesh. Changing the form to a linear or 
> bilinear form triggers the same coloring (right?), which stalls on this 
> particular mesh.
> 

You didn't bother to mention that the mesh is special!

The mesh is disconnected, which I suspect is the problem. My limited
understanding of the Boost colouring algorithm is that it starts at one
graph node and advances from there by moving along edges. Obviously this
will break down for a disconnected meshes since there is no way for the
algorithm to move from one graph (mesh) to the next.

Garth


> Johan
> 
>> Garth
>>
>>> At the end of the day I have to wait untill we support subdomains in the
>>> OpenMPAssembler as I am heavily using these...
>>>
>>> Johan
>>>
>>>> Garth
>>>>
>>>>> Johan
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~dolfin
>>>>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~dolfin
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~dolfin
>>>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~dolfin
>>>> More help   : https://help.launchpad.net/ListHelp
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dolfin
>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dolfin
>> More help   : https://help.launchpad.net/ListHelp