Hi Wei-keng,<br><br>Here is a modification of the F90 interface - I think that it can still be improved upon but I&#39;d like your feedback before going any further.  There are a couple of issues that I haven&#39;t yet addressed <br>
<br>1.  The current form of pnetcdf.inc breaks the f77 interface because the function declarations need to be in the include file.<br>     I think that in order to solve this in pnetcdf.inc we can use a #ifndef F90_INTERFACE around the<br>
    
f77 function declarations and define F90_INTERFACE at the top of pnetcdf.F90<br>
<br>2. The F90 compiler is okay with declarations of the form<br>    real :: var(*) <br>    it allows var to be any dimension without complaint - except when var is a scalar.   You can overcome this on intent(in)<br>    variables by using (/var/) in the call, but on intent(out) variables it requires an extra copy.<br>
    I would like to find  a solution that would not require this change, it might mean adding some dummy routines to the <br>    pnetcdf.F90 module.<br><br>- Jim<br><br><br><br><div class="gmail_quote">On Wed, Dec 30, 2009 at 5:48 PM, Jim Edwards <span dir="ltr">&lt;<a href="mailto:edwards.jim@gmail.com">edwards.jim@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Wei-keng,<br><br>I was looking at mpinetcdf.f90 - I now see that that was the wrong file (you should delete it from your repository).   I&#39;ll have a look at pnetcdf.F90 next week and get back to you.    But I do use nfmpi_get_var_all and if the interface doesn&#39;t contain it, it won&#39;t work for my app.    I do think that I know how to add this though, I&#39;ll look into it and get back to you.   <br>

<br>Happy New Year,<br><font color="#888888"><br>Jim   <br></font><div><div></div><div class="h5"><br><br><br><div class="gmail_quote">On Wed, Dec 30, 2009 at 4:41 PM, Wei-keng Liao <span dir="ltr">&lt;<a href="mailto:wkliao@ece.northwestern.edu" target="_blank">wkliao@ece.northwestern.edu</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
In the Fortran interface I wrote, all pnetcdf APIs are indeed functions,<br>
not subroutines.<br>
<br>
Those APIs without a data type in their names are not supposed to be<br>
visible to users. Each pnetcdf API is designed for a specific data<br>
type, so it is easy to keep a file portable. I did not add<br>
nfmpi_get_var_all to the interface on purpose.<br>
<br>
Actually, pnetcdf does not have nfmpi_put_var_all, in which this API<br>
makes little sense (every process writes the entire variable).<br><font color="#888888">
<br>
<br>
Wei-keng</font><div><div></div><div><br>
<br>
On Dec 30, 2009, at 4:24 PM, Jim Edwards wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I gave it a try to write something into configure but then realized that I would need to be able to link mpi in order to call the<br>
ncmpi_inq_libvers function which is something that you cannot do from configure on all platforms.     I added a call in my libraries init function to that function so that I will get a runtime failure with a descent error message if the version is too old.<br>


<br>
As for the f90 interface - I&#39;m afraid what you have there won&#39;t work.   All of the subroutines should be functions and you are<br>
missing the interface I am using - the  nfmpi_get_var_all and nfmpi_put_var_all types.    I&#39;m not sure yet but I think that I have something that will generate the f90 interfaces from a template file - let me give it a little thought, I may be able to contribute something here.<br>


<br>
<br>
<br>
<br>
<br>
<br>
On Wed, Dec 30, 2009 at 2:50 PM, Wei-keng Liao &lt;<a href="mailto:wkliao@ece.northwestern.edu" target="_blank">wkliao@ece.northwestern.edu</a>&gt; wrote:<br>
Hi, Jim,<br>
<br>
I just uploaded a few changes to pnetcdf SVN. The most notable is the<br>
Fortran module that contains the declaration of all the APIs and their<br>
arguments. They should be able to detected most of the argument type<br>
mismatch.<br>
<br>
This is my first attempt and may contain hidden problems.<br>
Please give it a try and let me know.<br>
<br>
As for your suggestion on the library version, I think it is<br>
a good idea. But I am not familiar with configure utility.<br>
I will leave it to Rob Latham.<br>
<br>
Wei-keng<br>
<br>
<br>
On Dec 30, 2009, at 9:32 AM, Jim Edwards wrote:<br>
<br>
I&#39;m working on porting pio from parallel-netcdf 1.0.2 to 1.1.0 -<br>
the fortran API changed a length variable from type default integer to type mpi_offset_kind.  This caused some errors<br>
that were a bit difficult to track down.<br>
<br>
So now my updated PIO won&#39;t work with an earlier version of pnetcdf and I want to build this into<br>
<a href="http://configure.ac" target="_blank">configure.ac</a>   Does anyone on this list already have this test?   The string provided by the  pnetcdf library<br>
isn&#39;t very parser friendly and the string in the svn trunk version is the same as the 1.1.0 release...<br>
<br>
const char *<br>
ncmpi_inq_libvers(void) {<br>
 return &quot;version = 1.1.0 of 02 November 2009&quot;;<br>
}<br>
<br>
<br>
Can I request a more parser friendly function and perhaps an svn generated version number so that we can distinguish between the<br>
release version and a repository check out?<br>
<br>
Thanks,<br>
Jim<br>
<br>
<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>