petsc-users Digest, Vol 4, Issue 28

Matt Reilly matthewreilly at
Tue Apr 28 07:12:19 CDT 2009

> 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 

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.

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.


More information about the petsc-users mailing list