[Getdp] Floating potentials in 3D: long execution times

[John_V]

I'm confirming that the fix worked. What had required 57 minutes now takes
only a bit over 3.5.

Thanks very much!

--John


On Sat, May 28, 2011 at 10:19 AM, Christophe Geuzaine
<cgeuzaine at ulg.ac.be>wrote:

>
> To the list: these performance issues should be fixed in SVN. If you use
> global quantities please le us know if you encounter any problems with the
> new version.
>
>
>
>
> On 27/05/11 08:33, Christophe Geuzaine wrote:
>
>>
>> Hi John - Thanks for the feedback. The two issues you mention (slow
>> generation of GroupsOfNodesOf and slow assembly) are indeed known, but
>> seem to be especially bad in your case. How many nodes do you have on
>> the floating potential surfaces?
>>
>>
>> On 25/05/11 17:54, John_V wrote:
>>
>>> I am using GetDP to calculate the potential in a 3D geometry of mixed
>>> conductors and insulators. The calculation is repeated frequently with
>>> different charge distributions, so CPU time is important. Even though my
>>> mesh has ~400k nodes, with some experimenting I have been able to get
>>> good solutions in about 90 seconds, provided all the conducting surfaces
>>> have Dirichlet boundary conditions.
>>>
>>> I need also to be able to deal with floating conductors, however. My
>>> first attempt at this was to treat the floating conductor as if it were
>>> a dielectric with very large dielectric constant. The problem with this
>>> approach is that it degrades the condition of the matrix. I have to use
>>> the ILUP preconditioner (~12 minutes to compute) instead of the faster
>>> ILU0 one (0.3 seconds).
>>>
>>> The discussion of floating potentials in the manual gave me hope of a
>>> better alternative. Bernhard Kubicek's "Capacitor2D" example on the Wiki
>>> showed the way, The method is very elegant, based I think on basis
>>> functions for groups of nodes as described in the paper by Dular,
>>> Legros, and Nicolet in IEEE Trans. Magnet. 34 (1998). I have implemented
>>> this for my 3D geometry.
>>>
>>> As I hoped, doing it this way let me return to the fast ILU0
>>> precondition. However, time gained here is lost elsewhere. Execution
>>> times are VERY large. It requires a total of 57 minutes CPU time for
>>> this method on my mesh.
>>>
>>> The two largest contributors to the 57 minutes are preprocessing
>>> (especially generating GroupsOfNodesOf, 27.5 minutes) and generating the
>>> system of equations (29 minutes).
>>>
>>> What is GetDP doing during all that time? Are these operations
>>> inherently this time-consuming?
>>>
>>> John
>>>
>>>
>>>
>>> _______________________________________________
>>> getdp mailing list
>>> getdp at geuz.org
>>> http://www.geuz.org/mailman/listinfo/getdp
>>>
>>
>>
>>
>
> --
> Prof. Christophe Geuzaine
> University of Liege, Electrical Engineering and Computer Science
> http://www.montefiore.ulg.ac.be/~geuzaine
>
> _______________________________________________
> getdp mailing list
> getdp at geuz.org
> http://www.geuz.org/mailman/listinfo/getdp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.geuz.org/pipermail/getdp/attachments/20110531/af826ac6/attachment.html>