parallel netcdf version info

[Wei-keng Liao]

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>
>
>