Compilation issue: libmpfr

[skastner]

Hello friendly ROMS forum denizens,

I am having an issue with compilation with the latest version of ROMS. More accurately, I have installed ROMS in two places (1) on my HOME directory on the HPC I have been using and (2) in a different dfs drive location that was recommended to me by my IT department. Installation (1), my home directory, compiles (although the actual runs crash due to memory leaks), while installation (2), on the dfs drive, does not compile. Here's the output:

rm -f -r core *.ipo /dfs6/pub/skastner/ROMS/trunk/test/upwelling/Build_romsG /data/homezvol0/skastner/make_macros.mk
cp -f /opt/apps/netcdf-c/4.7.0/gcc/8.4.0/include/netcdf.mod /dfs6/pub/skastner/ROMS/trunk/test/upwelling/Build_romsG
cp -f /opt/apps/netcdf-c/4.7.0/gcc/8.4.0/include/typesizes.mod /dfs6/pub/skastner/ROMS/trunk/test/upwelling/Build_romsG
cp -p /data/homezvol0/skastner/make_macros.mk /dfs6/pub/skastner/ROMS/trunk/test/upwelling/Build_romsG
/usr/bin/cpp -P -traditional -w -DMPI -DLINUX -DX86_64 -DGFORTRAN -D'ROOT_DIR="/dfs6/pub/skastner/ROMS/trunk"' -DUPWELLING -D'HEADER="upwelling.h"' -D'ROMS_HEADER="/dfs6/pub/skastner/ROMS/trunk/test/upwelling/upwelling.h"' -DAVERAGES -DDIAGNOSTICS_TS -DDIAGNOSTICS_UV -DSTATIONS -DFLOATS -DFLOAT_VWALK -DUV_VIS2 -DMIX_S_UV -DUV_LDRAG -DUV_DRAG_GRID -DANA_DRAG -DBIO_FENNEL -DNestedGrids= -D'ANALYTICAL_DIR="/dfs6/pub/skastner/ROMS/trunk/test/upwelling"' -D'MY_ANALYTICAL="on"' -D'SVN_URL="https://www.myroms.org/svn/src"' -D'SVN_REV="1143"' -IROMS/Include -I/dfs6/pub/skastner/ROMS/trunk/test/upwelling -IROMS/Nonlinear -IROMS/Nonlinear/Biology -IROMS/Nonlinear/Sediment -IROMS/Utility -IROMS/Drivers -IROMS/Functionals -I/dfs6/pub/skastner/ROMS/trunk/test/upwelling -IMaster -ICompilers -D'HEADER_DIR="/dfs6/pub/skastner/ROMS/trunk/test/upwelling"' -DAVERAGES -DDIAGNOSTICS_TS -DDIAGNOSTICS_UV -DSTATIONS -DFLOATS -DFLOAT_VWALK -DUV_VIS2 -DMIX_S_UV -DUV_LDRAG -DUV_DRAG_GRID -DANA_DRAG -DBIO_FENNEL ROMS/Nonlinear/interp_floats.F > /dfs6/pub/skastner/ROMS/trunk/test/upwelling/Build_romsG/interp_floats.f90
/usr/libexec/gcc/x86_64-redhat-linux/8/cc1: error while loading shared libraries: libmpfr.so.6: cannot open shared object file: No such file or directory
make: *** [ROMS/Nonlinear/Module.mk:14: /dfs6/pub/skastner/ROMS/trunk/test/upwelling/Build_romsG/interp_floats.f90] Error 1

I have bolded the error message for emphasis.

To my relatively untrained eye, it looks like there's an issue with finding libmpfr---how do I tell ROMS where to look for this?

Thanks in advance for your help.

[robertson]

Is that the full output of the build attempt? What command and options are you using to build? Are there any other differences between the build in your home directory and dfs? For example, different modules loaded or a different compiler, etc.

What does the command '/usr/bin/cpp --version' give you?

How about 'rpm -qa | grep mpfr'?

Or 'ldd /usr/libexec/gcc/x86_64-redhat-linux/8/cc1'?

At first glance it looks like either 'mpfr' isn't installed or the version that is installed does not provide the 'so.6' version of the library. However, it's hard imagine the build in your home directory being successful unless something major is different between the two builds.

All that said, I would suggest copying the successfully built ROMS executable from your home directory to your dfs drive location with all the input and forcing files and run it from there.

[skastner]

Thanks for the quick response, David.

That was indeed the full output of the dfs build attempt. I had changed the way I was dealing with modules---on the dfs drive, I was loading openmpi and netcdf before compiling. On my home directory, I was not loading these before compiling. I went back to the dfs drive and compiled without loading those two modules, and the compilation process does not error out...

However, I still get the following error on running the upwelling test case:

ran1.f90:150: runtime error: signed integer overflow: -1832521919 + -2138245891 cannot be represented in type 'integer(kind=4)'

=================================================================
==3059707==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 12746752 byte(s) in 6224 object(s) allocated from:
#0 0x7fc1bed89790 in __interceptor_realloc (/opt/apps/gcc/8.4.0/lib64/libasan.so.5+0xec790)
#1 0x3643c87 in __yaml_parser_mod_MOD_yaml_assignstring /dfs6/pub/skastner/ROMS/trunk/test/upwelling/Build_romsG/yaml_parser.f90:1602
#2 0x365d5a6 in __yaml_parser_mod_MOD_yaml_tree_fill /dfs6/pub/skastner/ROMS/trunk/test/upwelling/Build_romsG/yaml_parser.f90:1060
#3 0x36889f0 in __yaml_parser_mod_MOD_yaml_tree_create /dfs6/pub/skastner/ROMS/trunk/test/upwelling/Build_romsG/yaml_parser.f90:495
#4 0x36891b4 in __yaml_parser_mod_MOD_yaml_initialize /dfs6/pub/skastner/ROMS/trunk/test/upwelling/Build_romsG/yaml_parser.f90:348
#5 0x3306a1f in __get_metadata_mod_MOD_io_metadata /dfs6/pub/skastner/ROMS/trunk/test/upwelling/Build_romsG/get_metadata.f90:882
#6 0x226ee2c in __mod_ncparam_MOD_initialize_ncparam /dfs6/pub/skastner/ROMS/trunk/test/upwelling/Build_romsG/mod_ncparam.f90:1160
#7 0x344fa88 in read_phypar_ /dfs6/pub/skastner/ROMS/trunk/test/upwelling/Build_romsG/read_phypar.f90:241
#8 0x1558058 in __inp_par_mod_MOD_inp_par /dfs6/pub/skastner/ROMS/trunk/test/upwelling/Build_romsG/inp_par.f90:113
#9 0x4096ea in __roms_kernel_mod_MOD_roms_initialize /dfs6/pub/skastner/ROMS/trunk/test/upwelling/Build_romsG/roms_kernel.f90:99
#10 0x40b5fe in myroms /dfs6/pub/skastner/ROMS/trunk/test/upwelling/Build_romsG/master.f90:97
#11 0x40bedf in main /dfs6/pub/skastner/ROMS/trunk/test/upwelling/Build_romsG/master.f90:50
#12 0x7fc1bd12ccf2 in __libc_start_main (/lib64/libc.so.6+0x3acf2)

And many more leaks, I'm attaching the full error and log file for completeness.

Before I went back to running the test case, I had had issues with openMPI (I think) in the runs of a more complicated model I'm doing research with--the initial condition was not being read in correctly by the multiprocessor setup. This is probably related, I'd imagine.

I'm also attaching my build paths and build script. The build script points to Compilers_sk, where I have stored Linux-gfortran.mk (unedited) and my build paths file.

Thanks for your help.

[robertson]

In our experience "signed integer overflow" runtime error with gfortran is a non-fatal error and ROMS will continue to run. The real problem is likely the stack trace that comes next. My first guess would be that something is missing or mistyped in your .in and or varinfo.yaml file. If you are using the roms_upwelling.in and varinfo.yaml from an earlier version of ROMS I suggest you retrieve the latest versions from ROMS/External in your copy of the latest source code. The fact that the trace includes yaml_parser.f90 suggests that something happened while reading your model settings and or variable metadata.

[skastner]

Apologies for the slow response.

This error came about on a fresh installation of the latest version of ROMS. Nevertheless, I updated the directories involved, and got the same error (see the attached log files). I noticed that the test cases use a version of "varinfo.yaml" stored in the test/External/ directory, so I switched to the version stored in ROMS/External/, but got the same errors (also in the attached log files).

I've run both the upwelling test case and the river plume test case. The upwelling test case finishes, with the memory leak errors shown in the error/log combined file upwellinglog_romsexternalyaml.txt. The river plume test case blows up, with the memory leak errors shown in the error log/combined file riverplumelog_romsexternalyaml.txt.

I'm attaching to this post the .in files for both the upwelling and river plume test cases that I've been using, the error files mentioned above, and the two .yaml files mentioned above. Note that I've had to change the extension of the .yaml files to be .txt files in order to upload them here, I don't think this has changed the files in any other way. I don't see any major issues with the .yaml files, but I'm not sure I know what to look for aside from "are the variable names correct", which they appear to be. There are some minor differences between the .yaml files:

diff trunk/ROMS/External/varinfo.yaml trunk/test/External/varinfo.yaml
3c3
< #svn $Id: varinfo.yaml 1139 2022-09-28 16:04:42Z arango $
---
> #svn $Id: varinfo.yaml 1141 2022-10-04 18:30:18Z arango $
43c43
< svn_repository: $URL: https://www.myroms.org/svn/src/trunk/RO ... rinfo.yaml $
---
> svn_repository: $URL: https://www.myroms.org/svn/src/test/Ext ... rinfo.yaml $
241c241
< units: meter3 second-1 # [m3/s]
---
> units: meter3 second-1 # [m/s]
244a245,255
> type: w3dvar
> add_offset: 0.0d0
> scale: 1.0d0
>
> - variable: omega_implicit # Output
> standard_name: upward_sea_water_implicit_omega_velocity
> long_name: S-coordinate implicit vertical momentum component
> units: meter3 second-1 # [m/s]
> field: omega_implicit
> time: ocean_time
> index_code: idOvil

I don't think this is the source of my memory leak issue, though.

I'm wondering if this is a compiler issue based on this post: viewtopic.php?p=23811&hilit=memory+leak#p23811
Perhaps switching to iFort would be a good idea? Not sure what the way forward is here.

Thanks for your help.

[robertson]

If you have access to ifort I would definitely recommend using that rather than gfortran.

[subharsgis08]

First of all download this mprf package
https://centos.pkgs.org/8/centos-baseos ... 4.rpm.html
and install it using the following command
rpm -ivh mpfr-3.1.6-1.el8.x86_64.rpm

after installation finds this libmpfr.so.* (as an example libmpfr.so.6) file
default its in /usr/lib64/ path
then you try this command
ldd /usr/lib64/libmpfr.so.6

IF you already installed it then try with that with (example ldd /usr/lib64/libmpfr.so.6)

then you find something like this (as an example)
ldd /usr/lib64/libmpfr.so.4.1.1
linux-vdso.so.1 => (0x00007ffe41157000)
libgmp.so.10 => /lib64/libgmp.so.10 (0x00002b94e4d31000)
libc.so.6 => /lib64/libc.so.6 (0x00002b94e4fa9000)
/lib64/ld-linux-x86-64.so.2 (0x00002b94e48b2000)

check if anything is missing or not after that we will dig into the problem.
and post it here
Cheers!
Subhadeep Maishal
Indian Institute of Technology Kharagpur

[skastner]

Using ifort, as suggested above, fixed the memory leaks.