Hi John,<br><br>I'm not sure if this will help in your case but what i do is:<br><br>#ifdef PNETCDF<br> use parallel_mod, only : nfsizekind=>mpi_offset_kind<br>#else<br> use kinds, only : nfsizekind=>int_kind<br>#endif
<br>then declare those variables with nfsizekind so that they work with either netcdf or pnetcdf. <br><br>Oh I think I see - you are writting your pnetcdf interface in c and calling from fortran?<br>How about sticking with fortran - is that an option?
<br><br><br><br><div><span class="gmail_quote">On 10/24/06, <b class="gmail_sendername">John Michalakes</b> <<a href="mailto:john@michalakes.us">john@michalakes.us</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm having a problem adapting parallel NetCDF as an option in the WRF<br>(Weather Research and Forecast) model I/O API. WRF currently supports<br>non-parallel NetCDF, and we're now trying to extend the model to use the new
<br>parallel NetCDF code. Have run into a problem with some of the arguments in<br>the API for parallel-NetCDF:<br><br>The original NetCDF Fortran API defines lengths, starts, and other arguments<br>as INTEGER. PnetCDF recasts some (but not all) of these arguments as
<br>MPI_Offset. We compile WRF with OBJECT_MODE 64 on the IBMs where<br>KIND=MPI_OFFSET_KIND works out to 8 bytes. Thus, the calls in WRF that pass<br>these arguments as 32-bit INTEGERs from Fortran are causing PNetCDF to see
<br>garbage in the high four bytes of the dummy argument. For example, the<br>length argument to NFMPI_DEF_DIM ends up being 73 + a very-large-garbage<br>value instead of 73.<br><br>I was hoping for a relatively quick drop-in of PnetCDF into WRF I/O API but
<br>this now seems unlikely. There is a large amount of NetCDF interface code in<br>WRF that will need to be gone through. Or I can write a wrapper lib for all<br>these routines.<br><br>Has anyone done this already? What's needed is for the wrapper routine to
<br>accept INTEGER arguments and copy them to INTEGER(KIND=MPI_OFFSET_KIND) to<br>be used as arguments to the actual NFMPI_* routines in PNetCDF and (in the<br>case of return values) copy them back to INTEGER again.<br><br>
Not arguing, but curious: since PNetCDF is supposed to be a parallel<br>implementation of the NetCDF API, why was the API altered this way to use<br>arguments of type MPI_Offset instead of INTEGER? At least for what I'm<br>
trying to do, it is a significant impediment.<br><br>I really appreciate that parallel NetCDF is being developed. It is very much<br>needed, especially now as we try moving to Petascale. Kudos to the<br>developers.<br><br>
John<br><br>-----------------------------------------------------------<br>John Michalakes, Software Engineer <a href="mailto:michalak@ucar.edu">michalak@ucar.edu</a><br>NCAR, MMM Division voice: +1 303 497 8199
<br>3450 Mitchell Lane fax: +1 303 497 8181<br>Boulder, Colorado 80301 U.S.A. cell: +1 720 209 2320<br> <a href="http://www.mmm.ucar.edu/individual/michalakes">http://www.mmm.ucar.edu/individual/michalakes
</a><br>-----------------------------------------------------------<br><br></blockquote></div><br>