parallel netcdf version info

Jim Edwards edwards.jim at gmail.com
Thu Dec 31 12:51:20 CST 2009


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
>>>
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/parallel-netcdf/attachments/20091231/8061f007/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: f90interface.patch
Type: text/x-patch
Size: 15419 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/parallel-netcdf/attachments/20091231/8061f007/attachment.bin>


More information about the parallel-netcdf mailing list