Oh - that explains the confusion - I must have made some changes in mpinetcdf.f90 before I realized that it was the wrong file, and because the pnetcdf.F90 needs to be added to the repository it wasn't included in the patch.<br>
<br>I've attached the pnetcdf.F90 file here. <br><br><div class="gmail_quote">On Thu, Dec 31, 2009 at 2:36 PM, Wei-keng Liao <span dir="ltr"><<a href="mailto:wkliao@ece.northwestern.edu">wkliao@ece.northwestern.edu</a>></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;">Jim,<br>
<br>
I did not see pnetcdf.F90 in your patch, but can see your changes<br>
in mpinetcdf.f90. If you suggest to remove mpinetcdf.f90, why bother<br>
of changing it?<br><font color="#888888">
<br>
<br>
Wei-keng</font><div><div></div><div class="h5"><br>
<br>
On Dec 31, 2009, at 2:01 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;">
<br>
<br>
On Thu, Dec 31, 2009 at 12:53 PM, Wei-keng Liao <<a href="mailto:wkliao@ece.northwestern.edu" target="_blank">wkliao@ece.northwestern.edu</a>> wrote:<br>
Jim,<br>
<br>
I should probably explain how pnetcdf.F90 is produced.<br>
<br>
This file is created at "make" time, by concatenating files<br>
pnetcdf.inc and pnetcdf_api.interface. Then pnetcdf.F90 is<br>
compiled to produce pnetcdf.mod. I think you have already seen<br>
this in src/libf/Makefile.in<br>
<br>
I figured that out - but see no reason for the separate pnetcdf_api.interface file. I think that the change I made here simplifies things - is there anything wrong with it?<br>
<br>
<br>
I don't think src/libf/mpinetcdf.f90 is used anymore. So, if<br>
you see anything needs to change, please use pnetcdf.inc and<br>
pnetcdf_api.interface.<br>
<br>
Right - need to remove it.<br>
<br>
<br>
<br>
You are right about the pnetcdf.inc breaking the F77 programs.<br>
I saved the original external declaration for all APIs in file<br>
pnetcdf_api.external. Another way solve the F77 problem is to<br>
append that file to pnetcdf.inc after the F90 module is created.<br>
But then, we have to keep the two files pnetcdf_api.external and<br>
pnetcdf_api.interface consistent manually.<br>
<br>
I am not good at Fortran, but think your approach of using<br>
#ifndef F90_INTERFACE can be a good idea.<br>
<br>
I'll try this next week.<br>
<br>
As for your observation on the scalar arguments, one possibility<br>
is to use Fortran90 function/subroutine overloading. I have never<br>
tried it before, but merely know its availability.<br>
<br>
I think that's the same thing I said - I'll give it a try next week.<br>
<br>
<br>
Wei-keng<br>
<br>
<br>
On Dec 31, 2009, at 12:51 PM, Jim Edwards wrote:<br>
<br>
Hi Wei-keng,<br>
<br>
Here is a modification of the F90 interface - I think that it can still be improved upon but I'd like your feedback before going any further. There are a couple of issues that I haven'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>
On Wed, Dec 30, 2009 at 5:48 PM, Jim Edwards <<a href="mailto:edwards.jim@gmail.com" target="_blank">edwards.jim@gmail.com</a>> wrote:<br>
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'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't contain it, it won't work for my app. I do think that I know how to add this though, I'll look into it and get back to you.<br>
<br>
Happy New Year,<br>
<br>
Jim<br>
<br>
<br>
<br>
On Wed, Dec 30, 2009 at 4:41 PM, Wei-keng Liao <<a href="mailto:wkliao@ece.northwestern.edu" target="_blank">wkliao@ece.northwestern.edu</a>> wrote:<br>
<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>
<br>
<br>
Wei-keng<br>
<br>
<br>
On Dec 30, 2009, at 4:24 PM, Jim Edwards wrote:<br>
<br>
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'm afraid what you have there won'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'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 <<a href="mailto:wkliao@ece.northwestern.edu" target="_blank">wkliao@ece.northwestern.edu</a>> 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'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'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'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 "version = 1.1.0 of 02 November 2009";<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>
<br>
<br>
<br>
<f90interface.patch><br>
<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br>