[petsc-dev] Counting Fortran function pointers

[Jed Brown]

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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130109/535cbaaa/attachment.html>