filename prefixes

[Jim Edwards]

Hi Johnny,

I think that the real problem may be that WRF uses the colon character in
filenames and the filesystem reserves this same character for special use.
I think that there is a compile option for wrf not to use colons.

Jim

On Wed, Aug 11, 2010 at 4:44 PM, Johnny Chang <Johnny.Chang at nasa.gov> wrote:

> Hello,
>
> I am helping a user trouble-shoot a runtime error using
> parallel-netcdf version 1.1.1 and mvapich2/1.2p1/intel-PIC.
>
> The error message is:
>
>  0: MPI_File_open : File does not exist, error stack:
> ADIO_RESOLVEFILETYPE_PREFIX(546): Invalid file name
> wrfout_d01_2006-07-25_00:00:00
>  open_hist_w : error opening wrfout_d01_2006-07-25_00:00:00 for writing.
> ***
>
> While googling the ADIO_RESOLVEFILETYPE_PREFIX error, we found the
> ad_fstype.c code containing:
>
> 477     /*
> 478       ADIO_FileSysType_prefix - determines file system type for a file
> using
> 479       a prefix on the file name.  upper layer should have already
> determined
> 480       that a prefix is present.
> 481
> 482     Input Parameters:
> 483     . filename - path to file, including prefix (xxx:)
> 484
> 485     Output Parameters:
> 486     . fstype - pointer to integer in which to store file system type
> (ADIO_XXX)
> 487     . error_code - pointer to integer in which to store error code
> 488
> 489       Returns MPI_SUCCESS in error_code on success.  Filename not
> having a prefix
> 490       is considered an error. Except for on Windows systems where the
> default is NTFS.
> 491
> 492      */
> 493     static void ADIO_FileSysType_prefix(char *filename, int *fstype,
> int *error_code)
> 494     {
> 495         static char myname[] = "ADIO_RESOLVEFILETYPE_PREFIX";
> 496         *error_code = MPI_SUCCESS;
> 497
> 498         if (!strncmp(filename, "pfs:", 4) || !strncmp(filename, "PFS:",
> 4)) {
> 499             *fstype = ADIO_PFS;
> 500         }
>
>         ...
>
>
> 557     #else
> 558             *fstype = 0;
> 559             /* --BEGIN ERROR HANDLING-- */
> 560             *error_code = MPIO_Err_create_code(MPI_SUCCESS,
> MPIR_ERR_RECOVERABLE,
> 561                                                myname, __LINE__,
> MPI_ERR_NO_SUCH_FILE,
> 562                                                "**filename",
> "**filename %s", filename);
> 563             /* --END ERROR HANDLING-- */
> 564     #endif
> 565         }
> 566     }
>
> which seems to indicate that the MVAPICH2 library is expecting
> parallel-netcdf
> to pre-pend a prefix on the filename passed to the MVAPICH2 library.
>
> We are running on a Lustre filesystem.  So, we think that the
> parallel-netcdf
> library should have passed the "lustre:" or "LUSTRE:" prefix along with the
> actual filename.  Are we right in this interpretation of the error?
>
> If so, then perhaps the parallel-netcdf library was not built correctly?
>
> Here is the beginning part of config.log:
>
> ------------------------------------------------------------------------
>
> This file contains any messages produced by compilers while
> running configure, to aid debugging if configure makes a mistake.
>
> It was created by configure, which was
> generated by GNU Autoconf 2.61.  Invocation command line was
>
>  $ ./configure --prefix=/nasa/parallel-netcdf/1.1.1/mvapich2
> --with-mpi=/nasa/mvapich2/1.2p1/intel-PIC
>
> ## --------- ##
> ## Platform. ##
> ## --------- ##
>
> hostname = pbspl1
> uname -m = x86_64
> uname -r = 2.6.16.60-0.42.5.03schamp-nasa
> uname -s = Linux
> uname -v = #1 SMP Tue Nov 10 20:46:20 UTC 2009
>
> /usr/bin/uname -p = unknown
> /bin/uname -X     = unknown
>
> /bin/arch              = x86_64
> /usr/bin/arch -k       = unknown
> /usr/convex/getsysinfo = unknown
> /usr/bin/hostinfo      = unknown
> /bin/machine           = unknown
> /usr/bin/oslevel       = unknown
> /bin/universe          = unknown
>
> PATH: /nasa/intel/Compiler/11.1/046/bin/intel64
> PATH: /nasa/intel/Compiler/11.1/046/mkl/tools/environment
> PATH: /nasa/mvapich2/1.2p1/intel-PIC/bin
> PATH: /u/jrappley/bin
>
> If the problem is in the parallel-netcdf build, let us know
> what is the fix.
>
> Thanks in advance!
>
> Johnny
> --
> Johnny Chang
> 650-604-4356
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/parallel-netcdf/attachments/20100811/57594efc/attachment.htm>