[petsc-dev] What needs to be done before a release?

[Blaise Bourdin]

On Jun 1, 2012, at 2:23 PM, Jed Brown wrote:

> On Fri, Jun 1, 2012 at 1:34 PM, Blaise Bourdin <bourdin at lsu.edu> wrote:
> Apologies, will do next time. That would also have helped me realize that I had pushed to my own clone, not petsc-3.3 or petsc-dev repository... I am attaching the patch I was planing on submitting.
> 
> Out of curiosity, what is the rationale for not wanting an explicit interface? As far as I understand, the fortran standard mandates an explicit interface in this situation (array of strings). I would understand in the situation of pure f77 compatibility for instance, but we threw this away with the iso_c_binding module anyway...
> 
> Fortran modules are horribly nonportable from a build system perspective since every compiler manages them differently.

I agree. Some compilers even change the flag names from one release to the next. 


> Having the interfaces requires those extra interface files in the includes that we already hate so much, and we can't protect the headers (to make including the right ones simple like in C) because you have to include them for every subroutine.

Not really. You don't need to include the modules in each subroutine or function if they are included (used) in the Program or Module in which the function is defined



> I think it would be better [1] for the "modern" Fortran users for PETSc to do everything with modules, using explicit interfaces for all functions, and datatypes for PETSc objects.

Apart for [1], I fully agree. I actually think that there should only be two way to use fortran: the old f77 way without any type checking, interface, and where all petscobjects are integer, or the right way which you described.


> Unfortunately, that forces people to spell out things like type(Mat) [2] and XGetContext() either requires an explicit interface written by the user [3] or use of the ISO C bindings in the interface [4].
Not really. As long as your context is not too large (so that allocating a copy and copying the data won't kill you), you can always write a generic interface for XGetContext that returns an array of your favorite data type, then use transfer. And when your context is large, you should pass by address anyway). Conceptually, it is not really different from casting into a *void. McCormick has a nice writeup on this http://www.macresearch.org/advanced_fortran_90_callbacks_with_the_transfer_function

How does using iso_c_binding helps with a fortran library called from fortran? 

> I can think of no explanation for this absurdity other than that the Fortran language standards committee is the most successful global trolling agency in modern history [5].

>  
> Perhaps introducing f2003 in petsc was a bad idea, considering the large variety of compilers you need to support. If you feel that it introduces more issues than solving problems, feel free to strip the PetscOptionsEnum and PetscBagRegisterEnum bindings. They could easily be packaged separately for the few people who will ever need them.
> 
> [1] Better, but it would be best for them to stop using Fortran.
Why not. But what is the alternative knowing that I am not willing to give up array sections, operator overloading and vector operations? Are you going to suggest that I switch to C++? 

> [2] No #includes means no macros [6] and no equivalent of typedef.
The only macro I would miss are CHKERRQ and SETERRQ. I would actually make an exception for these two. For numerical and string types, the fortran way of doing typedef is kind.


> [3] Disaster because (a) it is maintained by the user with no way to check that it is correct and (b) the user may need multiple incompatible definitions in the same project.
> [4] Indeed, the best way to write a Fortran library called from Fortran is to use the ISO C bindings.
> [5] The people who dream up ways to link MKL and the Portland Group deserve honorable mention.
> [6] Type macros are terrible anyway because of the aforementioned punchcard nostalgia leading to different projects adopting different line/format styles and compilers having no portable way to select.
I don't know of any compiler which does not default to free form for .f90/.F90 files, do you? Free format has been around for over 20 years. That some people insist on coding on 72 cols (or is it 78?) in the days of large screens is beyond me indeed. 

So I guess that you guys don't want an explicit interface for PetscBagRegisterEnum, right? I'll fix the harmless bugs in the current binding, then.

Blaise

-- 
Department of Mathematics and Center for Computation & Technology
Louisiana State University, Baton Rouge, LA 70803, USA
Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120601/c29d4106/attachment.html>