1. You really need to profile. Copying a vector is cheap. >>>You are right. Maybe I make a big thing for this copy in/out and it is not that problematic or slow even for the whole 2D matrix. I have to test it with a large one to see.
> 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). > >>>I did not understand this completely. > > 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. > > >>>Well, no wonder petsc is a very general and mature solution. I have coded this already and it works fine with couple of other solvers. I cannot say it is faster/better than petsc and I even don't think the comparison would be correct. Though I would accept the challenge if I had time :-). I have the single code/single language strategy so my code should be able to compile and run without any external library. I attach many external libraries for additional tasks. Anyhow, my primary aim is to use petsc for its nice linear equation solvers. > 4. If you really want to use _your_ storage for a Vec or Mat, you can > use VecCreateMPIWithArray, MatCreateMPIAIJWithSplitArrays, and the > like. > This looks to be a solution. Thank you. > 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. > > >>>I agree. > > 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). > >>>Not to change the namespace but to limit it. When I put C-type include statements it brings all mostly unnecessary namespace which might collide with others, as you mentioned.