[petsc-users] Preallocation (Unstructured FE)

[Tabrez Ali]

Matt

Any linear 2/3d element would do. A linear tetrahedron would be good to 
start with.

Thanks
Tabrez

On 05/17/2011 11:21 AM, Matthew Knepley wrote:
> On Tue, May 17, 2011 at 9:36 AM, Tabrez Ali <stali at geology.wisc.edu 
> <mailto:stali at geology.wisc.edu>> wrote:
>
>     Matt
>
>     An example which reads an unstructured mesh (ascii or exodus),
>     partitions it and sets up Mat (with the right preallocation) would
>     be great. If it is in Fortran then that would be perfect. Btw my
>     problem also has Lagrange multiplier constraints.
>
>
> Yes, I should have been more specific. What element?
>
>   Thanks,
>
>      Matt
>
>     Thanks
>     Tabrez
>
>
>     On 05/17/2011 08:25 AM, Matthew Knepley wrote:
>>     On Mon, May 2, 2011 at 8:16 AM, Tabrez Ali
>>     <stali at geology.wisc.edu <mailto:stali at geology.wisc.edu>> wrote:
>>
>>         Is there a way I can use this and other mesh routines from
>>         Fortran? The manual doesn't say much on this.
>>
>>
>>     Yes, but you are right that nothing is in the manual. DMMESH (in
>>     petsc-dev) now obeys the full DM interface,
>>     so that DMGetMatrix() will return you a properly allocated Mat.
>>     So what is the problem? Of course, it is that
>>     Petsc has no good way to specify what finite element you are
>>     dealing with.
>>
>>     The way I was doing this is to encode it using some C++ classes.
>>     This turns out to be a bad way to do things.
>>     I am currently reworking it so that this information is stored in
>>     a simple C struct that you can produce. Should
>>     have this done soon.
>>
>>     Can you mail me a description of an example you would like to run?
>>
>>       Thanks,
>>
>>          Matt
>>
>>
>>         Tabrez
>>
>>
>>         On 05/01/2011 09:53 AM, Matthew Knepley wrote:
>>>         On Sat, Apr 30, 2011 at 12:58 PM, Tabrez Ali
>>>         <stali at geology.wisc.edu <mailto:stali at geology.wisc.edu>> wrote:
>>>
>>>             Petsc Developers/Users
>>>
>>>             I having some performance issues with preallocation in a
>>>             fully unstructured FE code. It would be very helpful if
>>>             those using FE codes can comment.
>>>
>>>             For a problem of size 100K nodes and 600K tet elements
>>>             (on 1 cpu)
>>>
>>>             1. If I calculate the _exact_ number of non-zeros per
>>>             row (using a running list in Fortran) by looping over
>>>             nodes & elements, the code takes 17 mins (to calculate
>>>             nnz's/per row, assemble and solve).
>>>             2. If I dont use a running list and simply get the
>>>             average of the max number of nodes a node might be
>>>             connected to (again by looping over nodes & elements but
>>>             not using a running list) then it takes 8 mins
>>>             3. If I just magically guess the right value calculated
>>>             in 2 and use that as average nnz per row then it only
>>>             takes 25 secs.
>>>
>>>             Basically in all cases Assembly and Solve are very fast
>>>             (few seconds) but the nnz calculation itself (in 2 and
>>>             3) takes a long time. How can this be cut down? Is there
>>>             a heuristic way to estimate the number (as done in 3)
>>>             even if it slightly overestimates the nnz's per row or
>>>             are efficient ways to do step 1 or 2. Right now I have
>>>             do i=1,num_nodes; do j=1,num_elements ... which
>>>             obviously is slow for large number of nodes/elements.
>>>
>>>
>>>         If you want to see my code doing this, look at
>>>
>>>           include/petscdmmesh.hh:preallocateOperatorNew()
>>>
>>>         which handles the determination of nonzero structure for a
>>>         FEM operator. It should look mostly
>>>         like your own code.
>>>
>>>             Matt
>>>
>>>             Thanks in advance
>>>             Tabrez
>>>
>>>
>>>
>>>
>>>         -- 
>>>         What most experimenters take for granted before they begin
>>>         their experiments is infinitely more interesting than any
>>>         results to which their experiments lead.
>>>         -- Norbert Wiener
>>
>>
>>
>>
>>     -- 
>>     What most experimenters take for granted before they begin their
>>     experiments is infinitely more interesting than any results to
>>     which their experiments lead.
>>     -- Norbert Wiener
>
>
>
>
> -- 
> What most experimenters take for granted before they begin their 
> experiments is infinitely more interesting than any results to which 
> their experiments lead.
> -- Norbert Wiener

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20110517/7fe189ff/attachment.htm>