Re: removing f77 support from PETSc?

[Richard Tran Mills <rmills@xxxxxxxx>]

Barry,

Since g95 and gfortran seem to work OK now, there are no very compelling 
reasons to keep f77 support that I know of.  It is worth asking, however:

1) How many people use the current F77-style calls in their code?  Such a 
change could be a huge pain for them if they've got lots of these calls.

2) Has anyone encountered any problems with the "universal" (we hope) F90 
interfaces that we introduced in PETSc 2.3.3?

The really important question is (2), of course.  To the best of my knowledge, 
the new interface really does seem to be universal.  I have encountered no 
problems with it, and have not heard any reported.

Regarding (1), we might just want to deprecate the use of F77.  That is:

  Current VecGetArrayF90 becomes VecGetArray
  Current VecGetArray becomes VecGetArrayF77

Likewise, the current *.h90 files become *.h, and the current *.h files become 
*.h77.

If we decide to put everything we can into Fortran modules, of course, then 
maintaining F77 compatibility would be quite messy and probably not worth it.

--Richard

Barry Smith wrote:
>   Since there are two seemingly ok free f90 compilers is there any 
> reason for PETSc to continue
> to support f77 or should we remove this support, for example change 
> VecGetArrayF90() to VecGetArray()
> etc and combine the *.h and *.h90 files?
>
>    I think so.
>
>
>   Should we go further and move most of the header code (parmeters, 
> common blocks etc) into
> Fortran modules and just put the few things in include files that cannot 
> go into modules like
> #define PetscScalar real8
> etc?
>
>    Seems reasonable also to me.
>
>    Barry

--
Richard Tran Mills, Ph.D.            |   E-mail: rmills@xxxxxxxxxxxxxxxx
Computational Scientist              |   Phone:  (865) 241-3198
Computational Earth Sciences Group   |   Fax:    (865) 574-0405
Oak Ridge National Laboratory        |   http://climate.ornl.gov/~rmills