Re: petsc-users Digest, Vol 4, Issue 28
Message: 2 Date: Sun, 26 Apr 2009 23:37:10 +0200 From: Jed Brown <[email protected]> Subject: Re: How to write a program, which can be run on 1 and multiple processors? To: PETSc users list <[email protected]> Message-ID: <[email protected]> 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). 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. matt
On Tue, Apr 28, 2009 at 7:12 AM, Matt Reilly <[email protected]> wrote:
Message: 2 Date: Sun, 26 Apr 2009 23:37:10 +0200 From: Jed Brown <[email protected]> Subject: Re: How to write a program, which can be run on 1 and multiple processors? To: PETSc users list <[email protected]> Message-ID: <[email protected]> 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
participants (2)
-
Matt Reilly -
Matthew Knepley