[petsc-users] Fortran interface -- low level access to petsc data
Jed Brown
jedbrown at mcs.anl.gov
Mon Oct 28 09:45:09 CDT 2013
Hossein Talebi <talebi.hossein at gmail.com> writes:
> Exactly, I personally look for:
>
> 1) type checking during the function calls. This helps also not looking
> into the manual for every single petsc function call.
>
> 2) low level access to petsc data structure. For example in my own code I
> already have my own hadnling of parallel vectors and matrices. When I use
> petsc, I have to always copy in/out all the data which is not optimal. So,
> it would be great if I can share or be change the petsc data in my Fortran
> code i.e. not through the petsc function calls. I understand this might be
> dangerous or not duable etc. But, I see no other solution.
1. You really need to profile. Copying a vector is cheap.
2. If you make your functions (to evaluate residuals, etc) take their
inputs as explicit arguments, you can just pass the PETSc objects (or
get the arrays from PETSc).
3. Parallel matrix assembly is almost certainly not something for which
you want to hard-code the data structure. PETSc provides generic
interfaces for _incrementally_ assembling matrices, so that there is
no extra storage and so the resulting data structure can be chosen at
run-time. I challenge you to find evidence that you can do this
better.
4. If you really want to use _your_ storage for a Vec or Mat, you can
use VecCreateMPIWithArray, MatCreateMPIAIJWithSplitArrays, and the
like.
All of the above are available through _public_ interfaces that are
already available to Fortran callers. Please don't use F2003 to expose
the _private_ struct definitions that we do not even offer to C callers.
> 3) easy definitions of petsc namespace through the Fortran modules, so I
> can choose what to import (using the Fortran 'only' statement).
PETSc uses prefixes for namespaces. You can use "only" with the normal
modules, but I can't tell if you are suggesting changing the names to
avoid the prefix (which I don't think is a good idea and will lead to
some collisions).
> There is no general automatic interface generation for Fortran, as much as
> I'm aware of. The gtk-fortran project, they wrote a python script to
> generate this interface automatically and it really works nicely. I could
> not imagine writiing such nice GTK GUI with Fortran.
Hmm, it may be interesting to look at that script and see if it can be adapted.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20131028/dbad11e3/attachment.pgp>
More information about the petsc-users
mailing list