benchmark case compile problem

[ywang152]

Hello everyone,

I am facing a problem when I tried to compile oceanM for benchmark case. I did get the executable file, oceanM, after running build script, attached below, but when I run it, I mentioned that the header file's name in the output log (attached below)was not right. It was "upwelling.h" instead of "benchmark.h".

• --------------------------------------------------------------------------------
  Model Input Parameters: ROMS/TOMS version 3.7
  Thursday - May 9, 2019 - 2:05:42 PM
  --------------------------------------------------------------------------------
  
  Benchmark Test, Idealized Southern Ocean, Small Grid
  
  Operating system : Linux
  CPU/hardware : x86_64
  Compiler system : gfortran
  Compiler command : /opt/openmpi401/bin/mpif90
  Compiler flags : -frepack-arrays -O3 -ffast-math -ffree-form -ffree-line-length-none -ffree-form -ffree-line-length-none -ffree-form -ffree-line-length-none
  
  Input Script : ocean_benchmark1.in
  
  SVN Root URL : https://www.myroms.org/svn/src/trunk
  SVN Revision : 904M
  
  Local Root : /home/ywang/roms/trunk
  Header Dir : /home/ywang/roms/Projects/Upwelling
  Header file : upwelling.h
  Analytical Dir: /home/ywang/roms/Projects/Upwelling
  
  Resolution, Grid 01: 0512x0064x030, Parallel Nodes: 4, Tiling: 002x002

The project path in build script was set to the right folder and the application name was right also. Since the corresponding header file of my oceanM was not right, running process failed.
What was interesting is that oceanG run successfully, but was followed by some message shown below:

• [ywang@riis retest_Benchmark]$ mpirun -np 4 oceanG ocean_benchmark1.in > test1_oceanG.log
  
  Program received signal 8 (SIGFPE): Floating-point exception.
  
  Program received signal 8 (SIGFPE): Floating-point exception.
  
  Program received signal 8 (SIGFPE): Floating-point exception.
  
  Backtrace for this error:
  + /lib64/libc.so.6() [0x3adc632510]
  + function wclock_off_ (0x496C5D)
  at line 238 of file timers.f90
  + function __ocean_control_mod_MOD_roms_finalize (0x403C51)
  at line 245 of file ocean_control.f90
  + in the main program
  at line 116 of file master.f90
  + /lib64/libc.so.6(__libc_start_main+0xfd) [0x3adc61ed1d]
  
  Backtrace for this error:
  + /lib64/libc.so.6() [0x3adc632510]
  + function wclock_off_ (0x496C5D)
  at line 238 of file timers.f90
  + function __ocean_control_mod_MOD_roms_finalize (0x403C51)
  at line 245 of file ocean_control.f90
  + in the main program
  at line 116 of file master.f90
  + /lib64/libc.so.6(__libc_start_main+0xfd) [0x3adc61ed1d]
  
  Backtrace for this error:
  + /lib64/libc.so.6() [0x3adc632510]
  + function wclock_off_ (0x496C5D)
  at line 238 of file timers.f90
  + function __ocean_control_mod_MOD_roms_finalize (0x403C51)
  at line 245 of file ocean_control.f90
  + in the main program
  at line 116 of file master.f90
  + /lib64/libc.so.6(__libc_start_main+0xfd) [0x3adc61ed1d]

The flag in build.bash for compiling oceanG is shown below.

Code: Select all

 export           USE_MPI=on            # distributed-memory parallelism
 export        USE_MPIF90=on            # compile with mpif90 script
#export         which_MPI=mpich         # compile with MPICH library
#export         which_MPI=mpich2        # compile with MPICH2 library
 export         which_MPI=openmpi       # compile with OpenMPI library

#export        USE_OpenMP=on            # shared-memory parallelism

#export              FORT=ifort
export              FORT=gfortran
#export              FORT=pgi

export         USE_DEBUG=on            # use Fortran debugging flags
export         USE_LARGE=on            # activate 64-bit compilation
export       USE_NETCDF4=on            # compile with NetCDF-4 library
export   USE_PARALLEL_IO=on            # Parallel I/O with Netcdf-4/HDF5

The only difference between the build.bash file I used for compiling oceanM and oceanG is the flag 'USE_DEBUG=on'. I guess the process of compile ROMS parallel with distributed-memory for benchmark case didn't finish in a right way, so the oceanM I got was for upwelling case, instead of benchmark?
I would be appreciated you could give some guidance about how to fix this problem. Thank you all in advance.


Best regards
Yifan

[robertson]

Hello,

Check the timestamp on your oceanM or oceanG perhaps your build failed and the executable is an older one from an upwelling test case. Though I don't believe this is contributing to your issue, you might consider setting MY_PROJECT_DIR to ${PWD} so your executable is always written to the directory you run your build script from. This will also make your build scripts more portable between applications.

Dave

[ywang152]

Hello,

Check the timestamp on your oceanM or oceanG perhaps your build failed and the executable is an older one from an upwelling test case. Though I don't believe this is contributing to your issue, you might consider setting MY_PROJECT_DIR to ${PWD} so your executable is always written to the directory you run your build script from. This will also make your build scripts more portable between applications.

Dave

Thanks for replying!
I have modified the build script by using MY_PRJECT_DIR=${PWD}. While the output oceanM still have running problem and the corresponding log file still shew wrong header file name and header path.
I also tested oceanG: compilation succeed and running finished, the log file of running shew a right header file and header path. This is really weird, why oceanM is special? Do you have idea about which process or script would influence the header path and header file name that shown in the log file of running? Is it possible that my parallel pre-work (installation of Netcdf, pnetcdf, hdf5 and so on) has any problem, though the compile process can be finished successfully?

Best regards
Yifan

[wilkin]

Delete the oceanM you have and redo the build.

Watch the output to screen during the build process - there is a lot of information there about what ROMS is actually doing as opposed to watch you thought you'd asked for.