> Yep. What are these raw-data tests of the MPI driver all about?
Sorry, I'm afraid I don't know. We've lost some of our parallel I/O expertise
lately, so
all I can suggest is that you try building a later version of mpich2, if
available. You
could at least run "make check" with that, to see if it also fails.
--Russ
> Craig
>
> *** Testing parallel IO for raw-data with MPIPOSIX-IO (driver)...
> =====================================================================================
> = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
> = EXIT CODE: 11
> = CLEANING UP REMAINING PROCESSES
> = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES
> =====================================================================================
> APPLICATION TERMINATED WITH THE EXIT STRING: Segmentation fault: 11 (signal
> 11)
> FAIL: run_par_test.sh
> ================================================
> 1 of 51 tests failed
> Please report to address@hidden
> ================================================
> gnumake[2]: *** [check-TESTS] Error 1
> gnumake[1]: *** [check-am] Error 2
> make: *** [check-recursive] Error 1
> address@hidden:/netcdf-4.2-snapshot2012022722/{122}>
>
>
>
> On Feb 28, 2012, at 2:47 PM, Unidata netCDF Support wrote:
>
> > Hi Craig,
> >
> > Does "make check" still fail reliably with a sementation fault?
> >
> > --Russ
> >
> >> Update:
> >>
> >> I ignored the errors and installed the build, then built the C++ and
> >> Fortran interfaces without a hitch.
> >>
> >> The parallel test program builds and runs correctly (below). Guess
> >> everything is okay?
> >>
> >> Craig
> >>
> >>> set NETCDF_INC = "-I${NETCDF}/include"
> >>> set NETCDF_LIB = "-L${NETCDF}/lib -lnetcdf -lnetcdff"
> >>> ${FC} ${FFLAGS} ${NETCDF_INC} ${NETCDF_LIB} -o simple_xy_par_wr
> >>> simple_xy_par_wr.f90
> >>
> >>> mpirun -np 16 ./simple_xy_par_wr
> >> *** SUCCESS writing example file simple_xy_par.nc!
> >>
> >>> ncdump simple_xy_par.nc
> >> netcdf simple_xy_par {
> >> dimensions:
> >> x = 16 ;
> >> y = 16 ;
> >> variables:
> >> int data(x, y) ;
> >> data:
> >>
> >> data =
> >> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> >> 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
> >> 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2,
> >> 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3,
> >> 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4,
> >> 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5,
> >> 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6,
> >> 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
> >> 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8,
> >> 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
> >> 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10,
> >> 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11, 11,
> >> 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12,
> >> 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13, 13,
> >> 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14, 14,
> >> 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15, 15 ;
> >> }
> >>
> >> On Feb 28, 2012, at 1:28 PM, Dr. Craig A. Mattocks wrote:
> >>
> >>> Hi again, Russ,
> >>>
> >>> Back to 64-bit mode on Mac OS X 10.7.3, trying to build the NetCDF C
> >>> interface (netcdf-4.2-snapshot2012022722) with the latest Intel compilers
> >>> (Version 12.1.3.289 Build 20120130). Any idea what the error below,
> >>> regarding the MPI-IO driver, means? Do I need to re-build mpich2?
> >>>
> >>> Thank you!
> >>> Craig
> >>>
> >>> Testing simple parallel I/O with 16 processors...
> >>>
> >>> *** Testing more advanced parallel access.
> >>> *** Testing parallel IO for raw-data with MPI-IO (driver)...ok.
> >>> *** Testing parallel IO for meta-data with MPI-IO (driver)...ok.
> >>> *** Testing parallel IO for different hyperslab selections with MPI-IO
> >>> (driver)...ok.
> >>> *** Testing parallel IO for raw-data with MPIPOSIX-IO (driver)...
> >>> =====================================================================================
> >>> = BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
> >>> = EXIT CODE: 11
> >>> = CLEANING UP REMAINING PROCESSES
> >>> = YOU CAN IGNORE THE BELOW CLEANUP MESSAGES
> >>> =====================================================================================
> >>> APPLICATION TERMINATED WITH THE EXIT STRING: Segmentation fault: 11
> >>> (signal 11)
> >>> FAIL: run_par_test.sh
> >>> ================================================
> >>> 1 of 51 tests failed
> >>> Please report to address@hidden
> >>> ================================================
> >>> gnumake[2]: *** [check-TESTS] Error 1
> >>> gnumake[1]: *** [check-am] Error 2
> >>> make: *** [check-recursive] Error 1
> >>>
> >>> On Feb 13, 2012, at 1:19 PM, Unidata netCDF Support wrote:
> >>>
> >>>> Hi Craig,
> >>>>
> >>>>> I am trying to build a 32-bit version of NetCDF-4 with the Intel
> >>>>> compilers on Mac OS X Lion (10.7.3) for a numerical model that does not
> >>>>> run on 64-bit platforms yet.
> >>>>>
> >>>>> I have successfully built 32-bit versions of szip and hdf5.
> >>>>
> >>>> Did you run "make check" on HDF5, and was it version 1.8.8?
> >>>> I've found that "make check" fails using the llvm-based C compiler that
> >>>> comes with the Xcode-4.2.1 developer tools, but that if you build with
> >>>> the gcc-4.6 that is available from Macports, the HDF5 library passes all
> >>>> the tests from "make check". I haven't had a chance to check if the
> >>>> resulting library works with the latest netCDF-4.2.snapshot yet.
> >>>>
> >>>>> When I run 'make check | & tee check.log' after building the C version
> >>>>> of NetCDF-4.2, I get the following error:
> >>>>>
> >>>>> *** Testing NetCDF-4 with user-supplied sample file.
> >>>>> *** testing creation of sample file...ok.
> >>>>> *** Tests successful!
> >>>>> PASS: tst_files4
> >>>>> /bin/sh: line 1: 76866 Segmentation fault: 11 ${dir}$tst
> >>>>> FAIL: tst_vars
> >>>>>
> >>>>> . . .
> >>>>>
> >>>>> ================================================
> >>>>> 1 of 50 tests failed
> >>>>> Please report to address@hidden
> >>>>> ================================================
> >>>>> gnumake[2]: *** [check-TESTS] Error 1
> >>>>> gnumake[1]: *** [check-am] Error 2
> >>>>> make: *** [check-recursive] Error 1
> >>>>>
> >>>>> How can I track down this error? Is it catastrophic or can I plow ahead?
> >>>>
> >>>> I wouldn't advise proceeding without knowing which test in tst_files4
> >>>> failed,
> >>>> and that would require duplicating the problem and doing some debugging.
> >>>> Sometimes the problems are in the tests, but more often they indicate a
> >>>> real
> >>>> bug. Which exact version of netCDF are you using, netCDF-4.2-rc1 or the
> >>>> daily snapshot?
> >>>>
> >>>>> Fortran build fails too.
> >>>>>
> >>>>> What is missing in the link process?
> >>>>
> >>>> It looks like you're using ifort, and the error is
> >>>>
> >>>>> Undefined symbols for architecture i386:
> >>>>> "_netcdf_mp_nf90_create_", referenced from:
> >>>>> _MAIN__ in f90tst_vars.o
> >>>>
> >>>> Can you see what architecture f90tst_vars.o is compiled for, using
> >>>>
> >>>> otool -L f90tst_vars.o
> >>>>
> >>>> Are you using the procedure described here for building the separate
> >>>> Fortran library:
> >>>>
> >>>> http://www.unidata.ucar.edu/mailing_lists/archives/netcdfgroup/2012/msg00019.html
> >>>>
> >>>> --Russ
> >>>>
> >>>>
> >>>>
> >>>> Russ Rew UCAR Unidata Program
> >>>> address@hidden http://www.unidata.ucar.edu
> >>>>
> >>>>
> >>>>
> >>>> Ticket Details
> >>>> ===================
> >>>> Ticket ID: GNF-884914
> >>>> Department: Support netCDF
> >>>> Priority: Normal
> >>>> Status: Closed
> >>>>
> >>>
> >>
> >>
> >
> > Russ Rew UCAR Unidata Program
> > address@hidden http://www.unidata.ucar.edu
> >
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: GNF-884914
> > Department: Support netCDF
> > Priority: Urgent
> > Status: Closed
> >
>
>
Russ Rew UCAR Unidata Program
address@hidden http://www.unidata.ucar.edu
Ticket Details
===================
Ticket ID: GNF-884914
Department: Support netCDF
Priority: Urgent
Status: Closed
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.