[petsc-users] Preallocation (Unstructured FE)

[Tabrez Ali]

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.

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

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