petsc-users Digest, Vol 4, Issue 28

[Matthew Knepley]

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

>
>
>> Message: 2
>> Date: Sun, 26 Apr 2009 23:37:10 +0200
>> From: Jed Brown <jed at 59A2.org>
>> Subject: Re: How to write a program,    which can be run on 1 and
>>        multiple processors?
>> To: PETSc users list <petsc-users at mcs.anl.gov>
>> Message-ID: <49F4D406.3000908 at 59A2.org>
>> 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.

   Matt


>
> 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
lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20090428/628387b3/attachment-0001.htm>