parallel netcdf version info

[Jim Edwards]

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/dbe8b003/attachment.htm>