[petsc-dev] Counting Fortran function pointers

[Barry Smith]

  You had a problem with this? :-)  Some dusty old corners of PETSc are best never viewed.

-/*
-snes->fortran_func_pointers usage:
-
-0: oursnesfunction
-1: oursnestest
-2: oursnesjacobian
-3: oursnesmonitor
-4: oursnesmonitor ctx
-5: ourmondestroy
-6: unused
-7: unused
-8: unused
-9: unused
-10: ourdestroy
-11: oursnestest ctx
-12: unused
-13: oursnesgs
-
- */

On Jan 9, 2013, at 7:37 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> Richard, I pushed a new Fortran callback handling system. It is subtype-safe and doesn't rely on crazy static numbering. You can see what is left to do by
> 
> $ grep AllocateFortran src/**/*.c
> 
> Once these are gone, we can delete the old system.
> 
> Meanwhile, you can add new functions using the system here. The Set call will create a callback ID if it doesn't exist yet and the object will automatically handle resizing and resetting when you change subtypes.
> 
> https://bitbucket.org/petsc/petsc-dev/commits/f2a68b8a037edffd463d1ee6e9014e2edcd4aad7
> 
> a couple more instances:
> 
> https://bitbucket.org/petsc/petsc-dev/commits/bc94ac15bf5a75c3290770efe7e624a46ddcad37
> 
> 
> On Mon, Jan 7, 2013 at 5:48 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> Richard, it's better to mail the list. No, we haven't reworked subtype Fortran pointers yet, but I think we know what needs to be done.
> 
> 
> On Mon, Jan 7, 2013 at 1:42 PM, Richard Tran Mills <rtm at eecs.utk.edu> wrote:
> Hi Jed,
> 
> I am back at work after some extended time away and I need to start messing with DMShell so that I can use it to set operations like LocalToGlobal and GlobalToLocal updates from inside PFLOTRAN.
> 
> Did this issue of handling the Fortran function pointers get resolved somehow?  Is there something I need to change in how I am doing the Fortran bindings?
> 
> Cheers,
> Richard
> 
> 
> On 12/4/12 5:43 PM, Jed Brown wrote:
>> As usual, anything that is duplicated and not checked by the compiler is broken.
>> 
>> $ grep PetscObjectAllocateFortranPointers src/**/*.c                                                                                                                            
>> src/dm/impls/da/ftn-custom/zda2f.c:  PetscObjectAllocateFortranPointers(*da,6);
>> src/dm/impls/da/ftn-custom/zda2f.c:  PetscObjectAllocateFortranPointers(*da,6);
>> src/dm/impls/shell/ftn-custom/zdmshellf.c:  PetscObjectAllocateFortranPointers(*dm,2);
>> src/dm/impls/shell/ftn-custom/zdmshellf.c:  PetscObjectAllocateFortranPointers(*dm,2);
>> 
>> Note that changing the type does not reset the function pointers, thus having a DMSHELL, calling DMSetType(dm,DMDA), and then setting a DMDA local function will cause memory corruption.
>> 
>> I cannot express how much I hate this system. The full-blown solution is that for each type, we register a (global) token which is the index of that function pointer. That doesn't have any false dependencies, but is more "initialize" code.
>> 
>> An alternative, used in the TS and KSP code below, is to have a common enum that lists all the Fortran functions. It's a false header dependency, but not a binary dependency.
>> 
>> What should we do? The current state is a disaster.
>> 
>> src/ksp/ksp/impls/gmres/fgmres/ftn-custom/zmodpcff.c:  PetscObjectAllocateFortranPointers(*ksp,3);
>> src/ksp/ksp/interface/ftn-custom/zitfuncf.c:  PetscObjectAllocateFortranPointers(*ksp,FTN_MAX);
>> src/ksp/ksp/interface/ftn-custom/zitfuncf.c:  PetscObjectAllocateFortranPointers(*ksp,FTN_MAX);
>> src/ksp/pc/impls/mg/ftn-custom/zmgfuncf.c:    PetscObjectAllocateFortranPointers(*mat,1);
>> src/ksp/pc/impls/shell/ftn-custom/zshellpcf.c:  PetscObjectAllocateFortranPointers(*pc,5);
>> src/ksp/pc/impls/shell/ftn-custom/zshellpcf.c:  PetscObjectAllocateFortranPointers(*pc,5);
>> src/ksp/pc/impls/shell/ftn-custom/zshellpcf.c:  PetscObjectAllocateFortranPointers(*pc,5);
>> src/ksp/pc/impls/shell/ftn-custom/zshellpcf.c:  PetscObjectAllocateFortranPointers(*pc,5);
>> src/ksp/pc/impls/shell/ftn-custom/zshellpcf.c:  PetscObjectAllocateFortranPointers(*pc,5);
>> src/mat/impls/mffd/ftn-custom/zmffdf.c:  PetscObjectAllocateFortranPointers(*mat,2);
>> src/mat/impls/shell/ftn-custom/zshellf.c:  PetscObjectAllocateFortranPointers(*mat,11);
>> src/mat/interface/ftn-custom/zmatrixf.c:  PetscObjectAllocateFortranPointers(*sp,1);
>> src/snes/interface/ftn-custom/zsnesf.c:  PetscObjectAllocateFortranPointers(*snes,14);
>> src/snes/interface/ftn-custom/zsnesf.c:  PetscObjectAllocateFortranPointers(*snes,14);
>> src/snes/interface/ftn-custom/zsnesf.c:  PetscObjectAllocateFortranPointers(*snes,14);
>> src/snes/interface/ftn-custom/zsnesf.c:  PetscObjectAllocateFortranPointers(*snes,14);
>> src/snes/interface/ftn-custom/zsnesf.c:  PetscObjectAllocateFortranPointers(*snes,14);
>> src/snes/linesearch/impls/shell/ftn-custom/zlinesearchshellf.c:  PetscObjectAllocateFortranPointers(*linesearch,3);
>> src/snes/linesearch/interface/ftn-custom/zlinesearchf.c:  PetscObjectAllocateFortranPointers(*linesearch,3);
>> src/snes/linesearch/interface/ftn-custom/zlinesearchf.c:  PetscObjectAllocateFortranPointers(*linesearch,3);
>> src/sys/draw/utils/ftn-custom/zzoomf.c:  PetscObjectAllocateFortranPointers(*draw,1);
>> src/ts/interface/ftn-custom/ztsf.c:  PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);
>> src/ts/interface/ftn-custom/ztsf.c:  PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);
>> src/ts/interface/ftn-custom/ztsf.c:    PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);
>> src/ts/interface/ftn-custom/ztsf.c:    PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);
>> src/ts/interface/ftn-custom/ztsf.c:  PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);
>> src/ts/interface/ftn-custom/ztsf.c:  PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);
>> src/ts/interface/ftn-custom/ztsf.c:  PetscObjectAllocateFortranPointers(*ts,OUR_COUNT);
> 
> 
> -- 
> Richard Tran Mills, Ph.D.
> Computational Earth Scientist      | Joint Assistant Professor
> Hydrogeochemical Dynamics Team     | EECS and Earth & Planetary Sciences
> Oak Ridge National Laboratory      | University of Tennessee, Knoxville
> E-mail: 
> rmills at ornl.gov  V: 865-241-3198 http://climate.ornl.gov/~rmills
> 
>