parallel netcdf version info

Jim Edwards edwards.jim at gmail.com
Wed Dec 30 16:24:44 CST 2009


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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/parallel-netcdf/attachments/20091230/9a5fd907/attachment.htm>


More information about the parallel-netcdf mailing list