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>
