petsc-users Digest, Vol 4, Issue 28

Matthew Knepley knepley at
Tue Apr 28 08:20:00 CDT 2009

On Tue, Apr 28, 2009 at 7:12 AM, Matt Reilly <matthewreilly at> wrote:

>> Message: 2
>> Date: Sun, 26 Apr 2009 23:37:10 +0200
>> From: Jed Brown <jed at>
>> Subject: Re: How to write a program,    which can be run on 1 and
>>        multiple processors?
>> To: PETSc users list <petsc-users at>
>> Message-ID: <49F4D406.3000908 at>
>> Content-Type: text/plain; charset=ISO-8859-1
>> Yixun Liu wrote:
>>> Hi,
>>> I want to make my code run on 1 or multiple processors. The code, which
>>> can run on multiple processors is like the following,
>>> MatCreate(PETSC_COMM_WORLD, &A);
>>>   MatSetSizes(A, 3*numOfVerticesOfOneProcessor,
>>> 3*numOfVerticesOfOneProcessor, systemSize, systemSize);
>> You don't have to provide both local and global size unless you want
>> PETSc to check that these numbers are compatible.
>>>   MatSetFromOptions(A);
>>>   MatMPIAIJSetPreallocation(A, 50, PETSC_NULL, 50, PETSC_NULL);
>>> However if I want to run on 1 processor I have to change the last code
>>> to:
>>> MatSeqAIJSetPreallocation(A,1000,PETSC_NULL);
>>                              ^^^^
>> you probably mean 100
>>> How to avoid changing code?
>> Call both always.  You can call {Seq,MPI}BAIJ preallocation while you're
>> at it.  The preallocation functions don't do anything unless they match
>> the matrix type that you have.
>> Jed
> Jed's suggestion works, and is certainly reasonable.
> Personally, I'd advocate wrapping the sequence of
> matcreate/setfromoptions/preallocate in a higher
> level function, if possible. One version of the function exists for serial
> codes, the other for
> parallel.  This keeps the code cleaner, doesn't rely on functions that
> don't do anything if the
> conditions aren't right, and will probably look cleaner (be easier to
> maintain).

These exist already. They are not easier to maintain, and have
disadvantages. That is why we switched.

> The disadvantage of this approach is that you have two routines that
> perform the same function,
> but in slightly different ways.  If you find a bug in one, it is important
> that you remember to fix
> the bug in both routines. In my own code, when I'm forced into this
> situation, I put a large reminder
> comment in both routines to remind me that there bug fixes in one routine
> should be propagated to
> the other.

I am not sure what you mean. These routines do not perform the same function
at all. There is no
code reuse.


> Finally, some would suggest using #ifdef #endif conditional compilation.
>  I'm not one of them.
> The problem with conditional compilation is that it is a slippery slope.
> You start off with just one
> or two instances, and then they breed. Soon you've got a giant program with
> dozens of places
> where a human reader will have quite a difficult time figuring out just
> what code gets compiled
> and what code doesn't.
>      matt
What most experimenters take for granted before they begin their experiments
is infinitely more interesting than any results to which their experiments
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the petsc-users mailing list