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