[petsc-users] Updating Fortran code to petsc 3.8

[Randy Michael Churchill]

>
>    Please clarify.
>
> 1) You can successfully update to 3.8 and compile and run the code?

I haven't updated all of the code to 3.8, I wanted to make sure there
wasn't any tricks to maintain backwards compatibility before I change
everything. I'm only in the process of changing several of the codebase's
files, updating any "Amat = 0" statements or "if (Amat==0) then"
statements, which do not compile with 3.8 (they need the specific
PETSC_NULL_XXX instead of 0). When I make those changes, that section of
the code compiles (btw, on NERSC Edison, with my own compiled petsc v3.8).


>
>
2) You do not have a way to support both 3.7 and 3.8 except by putting a
> large number of #ifdef in the code?
>
If I have to change "Amat = 0" to "Amat = PETSC_NULL_MAT" for 3.8, and
change all of the PETSC_NULL_OBJECT for 3.8, many of those PETSC_NULL_XXX
references are not included in v3.7, correct? If not, and I want to keep
backwards compatibility, everywhere there is a PETSC_NULL_OBJECT, I would
have to do:
#include <petscversion.h>
#if PETSC_VERSION_GE(3,8,0)
call MatNullSpaceCreate(comm, PETSC_TRUE, 0, PETSC_NULL_VEC, nullsp,ierr)
#else
call MatNullSpaceCreate(comm, PETSC_TRUE, 0, PETSC_NULL_OBJECT, nullsp,ierr)
#endif

If this is the only way to upgrade our codebase to use petsc v3.8, thats
fine, I just wanted to verify that there wasn't another way, which would be
cleaner (e.g. perhaps creating an include file with all of the
PETSC_NULL_XXX definitions which aren't in v3.7, and thus avoid many of
these #if PETSC_VERSION statements).




>
>   Yes, 3.8 is a dramatic shift in API (to one we feel is much better), it
> is not simple to write code that works with both versions. We recommend
> just using a 3.8 version once you verify it behaves as the previous
> version. Note that on any computer including those at NERSc if 3.8 is not
> installed by default you may install it yourself.
>
>    Barry
>
> > On Oct 30, 2017, at 12:18 PM, Randy Michael Churchill <rchurchi at pppl.gov>
> wrote:
> >
> > I'm updating my Fortran code to petsc 3.8. I have several modules with
> types, and often when a type is initialized in the code, there are certain
> Petsc variables that aren't ready to be initialized, so they are set to 0.
> Later, in several parts of the code, these are checked with and if
> statments, e.g.:
> >
> > module modmat
> > #include <petsc/finclude/petsc.h>
> > #include <petsc/finclude/petscmat.h>
> > use petsc
> > use petscmat
> >
> > type mymat
> > Mat :: Amat
> > end type mymat
> >
> > contains
> >   subroutine mymat_init(this)
> >     this%Amat = 0
> >   end subroutine mymat_init
> > end module modmat
> >
> >
> > program main
> > use modmat
> > implicit none
> > type(mymat)::mymat1
> >
> > call mymat_init(mymat1)
> > call somethingamazing(mymat1)
> > end program main
> >
> > subroutine somethingamazing(this)
> > use modmat
> > typ(mymat) :: this
> > if (this%Amat == 0) then
> >   print 'Amat not initialized'
> > endif
> > end subroutine somethingamazing
> >
> >
> > However, with Petsc 3.8, if I set Amat to 0, I get the error:
> > error #6303: The assignment operation or the binary expression operation
> is invalid for the data types of the two operands.
> >
> > I replaced the 0 with PETSC_NULL_MAT, but then the if statement gives an
> error:
> > error #6355: This binary operation is invalid for this data type.
> >
> > I change the if statement to:
> > if (this%Amat == PETSC_NULL_MAT) then
> > and it compiles.
> >
> > Is this the right way to update Fortran code to v3.8? Is there any
> alternative? My concern is we will have no backwards compatibility, because
> I believe the specific PETSC_NULL_XXX objects were only introduced in 3.8.
> So if we update to 3.8, we would either have to drop support for <3.8 or
> have a lot of #if PETSC_VERSION statements.
> >
> > --
> > R. Michael Churchill
>
>


-- 
R. Michael Churchill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20171030/8e29b667/attachment-0001.html>