<div dir="ltr">1. You really need to profile.  Copying a vector is cheap.<br><div class="gmail_extra"><div class="gmail_quote"><div><br>>>>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.<br><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2. If you make your functions (to evaluate residuals, etc) take their<br>
   inputs as explicit arguments, you can just pass the PETSc objects (or </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">   get the arrays from PETSc).<br>

</blockquote><div><br></div><div>>>>I did not understand this completely. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
3. Parallel matrix assembly is almost certainly not something for which<br>
   you want to hard-code the data structure.  PETSc provides generic<br>
   interfaces for _incrementally_ assembling matrices, so that there is<br>
   no extra storage and so the resulting data structure can be chosen at<br>
   run-time.  I challenge you to find evidence that you can do this<br>
   better.<br>
<br></blockquote><div>>>>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. <br>

<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
4. If you really want to use _your_ storage for a Vec or Mat, you can<br>
   use VecCreateMPIWithArray, MatCreateMPIAIJWithSplitArrays, and the<br>
   like.<br></blockquote><div>This looks to be a solution. Thank you.  <br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
All of the above are available through _public_ interfaces that are<br>
already available to Fortran callers.  Please don't use F2003 to expose<br>
the _private_ struct definitions that we do not even offer to C callers.<br>
<div class="im"><br></div></blockquote><div>>>>I agree. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">


> 3) easy definitions of petsc namespace through the Fortran modules, so I<br>
> can choose what to import (using the Fortran 'only' statement).<br>
<br>
</div>PETSc uses prefixes for namespaces.  You can use "only" with the normal<br>
modules, but I can't tell if you are suggesting changing the names to<br>
avoid the prefix (which I don't think is a good idea and will lead to<br>
some collisions).<br>
<div></div></blockquote><div>>>>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.  <br clear="all">

</div></div><br><br></div></div>