parallel netcdf version info

Thu Dec 31 15:45:42 CST 2009

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.

I've attached the pnetcdf.F90 file here.

On Thu, Dec 31, 2009 at 2:36 PM, Wei-keng Liao
<wkliao at ece.northwestern.edu>wrote:

> Jim,
>
> I did not see pnetcdf.F90 in your patch, but can see your changes
> in mpinetcdf.f90. If you suggest to remove mpinetcdf.f90, why bother
> of changing it?
>
>
> Wei-keng
>
>
> On Dec 31, 2009, at 2:01 PM, Jim Edwards wrote:
>
>
>>
>> On Thu, Dec 31, 2009 at 12:53 PM, Wei-keng Liao <
>> wkliao at ece.northwestern.edu> wrote:
>> Jim,
>>
>> I should probably explain how pnetcdf.F90 is produced.
>>
>> This file is created at "make" time, by concatenating files
>> pnetcdf.inc and pnetcdf_api.interface. Then pnetcdf.F90 is
>> compiled to produce pnetcdf.mod. I think you have already seen
>> this in src/libf/Makefile.in
>>
>> 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?
>>
>>
>> I don't think src/libf/mpinetcdf.f90 is used anymore. So, if
>> you see anything needs to change, please use pnetcdf.inc and
>> pnetcdf_api.interface.
>>
>> Right - need to remove it.
>>
>>
>>
>> You are right about the pnetcdf.inc breaking the F77 programs.
>> I saved the original external declaration for all APIs in file
>> pnetcdf_api.external. Another way solve the F77 problem is to
>> append that file to pnetcdf.inc after the F90 module is created.
>> But then, we have to keep the two files pnetcdf_api.external and
>> pnetcdf_api.interface consistent manually.
>>
>> I am not good at Fortran, but think your approach of using
>> #ifndef F90_INTERFACE can be a good idea.
>>
>> I'll try this next week.
>>
>> As for your observation on the scalar arguments, one possibility
>> is to use Fortran90 function/subroutine overloading. I have never
>> tried it before, but merely know its availability.
>>
>> I think that's the same thing I said - I'll give it a try next week.
>>
>>
>> Wei-keng
>>
>>
>> On Dec 31, 2009, at 12:51 PM, Jim Edwards wrote:
>>
>> Hi Wei-keng,
>>
>> 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
>>
>> 1.  The current form of pnetcdf.inc breaks the f77 interface because the
>> function declarations need to be in the include file.
>>   I think that in order to solve this in pnetcdf.inc we can use a #ifndef
>> F90_INTERFACE around the
>>   f77 function declarations and define F90_INTERFACE at the top of
>> pnetcdf.F90
>>
>> 2. The F90 compiler is okay with declarations of the form
>>  real :: var(*)
>>  it allows var to be any dimension without complaint - except when var is
>> a scalar.   You can overcome this on intent(in)
>>  variables by using (/var/) in the call, but on intent(out) variables it
>> requires an extra copy.
>>  I would like to find  a solution that would not require this change, it
>> might mean adding some dummy routines to the
>>  pnetcdf.F90 module.
>>
>> - Jim
>>
>>
>>
>> On Wed, Dec 30, 2009 at 5:48 PM, Jim Edwards <edwards.jim at gmail.com>
>> wrote:
>> Wei-keng,
>>
>> 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.
>>
>> Happy New Year,
>>
>> Jim
>>
>>
>>
>> On Wed, Dec 30, 2009 at 4:41 PM, Wei-keng Liao <
>> wkliao at ece.northwestern.edu> wrote:
>>
>> In the Fortran interface I wrote, all pnetcdf APIs are indeed functions,
>> not subroutines.
>>
>> Those APIs without a data type in their names are not supposed to be
>> visible to users. Each pnetcdf API is designed for a specific data
>> type, so it is easy to keep a file portable. I did not add
>> nfmpi_get_var_all to the interface on purpose.
>>
>> Actually, pnetcdf does not have nfmpi_put_var_all, in which this API
>> makes little sense (every process writes the entire variable).
>>
>>
>> Wei-keng
>>
>>
>> On Dec 30, 2009, at 4:24 PM, Jim Edwards wrote:
>>
>> 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
>> 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.
>>
>> 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
>> 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.
>>
>>
>>
>>
>>
>>
>> On Wed, Dec 30, 2009 at 2:50 PM, Wei-keng Liao <
>> wkliao at ece.northwestern.edu> wrote:
>> Hi, Jim,
>>
>> I just uploaded a few changes to pnetcdf SVN. The most notable is the
>> Fortran module that contains the declaration of all the APIs and their
>> arguments. They should be able to detected most of the argument type
>> mismatch.
>>
>> This is my first attempt and may contain hidden problems.
>> Please give it a try and let me know.
>>
>> As for your suggestion on the library version, I think it is
>> a good idea. But I am not familiar with configure utility.
>> I will leave it to Rob Latham.
>>
>> Wei-keng
>>
>>
>> On Dec 30, 2009, at 9:32 AM, Jim Edwards wrote:
>>
>> I'm working on porting pio from parallel-netcdf 1.0.2 to 1.1.0 -
>> the fortran API changed a length variable from type default integer to
>> type mpi_offset_kind.  This caused some errors
>> that were a bit difficult to track down.
>>
>> So now my updated PIO won't work with an earlier version of pnetcdf and I
>> want to build this into
>> configure.ac   Does anyone on this list already have this test?   The
>> string provided by the  pnetcdf library
>> isn't very parser friendly and the string in the svn trunk version is the
>> same as the 1.1.0 release...
>>
>> const char *
>> ncmpi_inq_libvers(void) {
>> return "version = 1.1.0 of 02 November 2009";
>> }
>>
>>
>> Can I request a more parser friendly function and perhaps an svn generated
>> version number so that we can distinguish between the
>> release version and a repository check out?
>>
>> Thanks,
>> Jim
>>
>>
>>
>>
>>
>>
>> <f90interface.patch>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/parallel-netcdf/attachments/20091231/29e0bf6a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pnetcdf.F90
Type: application/octet-stream
Size: 81447 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/parallel-netcdf/attachments/20091231/29e0bf6a/attachment-0001.obj>