Memory leaks - Upwelling

[bernacosenza]

Hi

I am new to roms and i'm trying to make sure the installation was done properly by running the upwelling test case.
I was able to compile without errors and the romsG file was created, then when i try to run it (./romsG < roms_upwelling.in) everything seems okay it even shows "ROMS/TOMS: DONE..."at the end but right after that i have several memory leaks. Besides that the 4 .nc files were created (avg, dia, his, rst). Also if i change Ntimes the number of bytes and allocations doesn't change.
I was following tutorials and tried to keep it very simple, below you can see my configs and the output with the leaks.
I didnt modify the input file (just varinfo path and ntimes)

My build_roms.sh contains the following:

#the whole cpp options was commented
export which_MPI=openmpi
export FORT=gfortran
export USE_DEBUG=on
export USE_LARGE=on
export STATIC=on
export EXEC=on
export USE_NETCDF4=on
didn't touch in the ESM section
#export USE_MY_LIBS=no
export USE_MY_LIBS=yes I tried both default and customized lib paths

Compiler and libs:

GNU Fortran (Ubuntu 11.2.0-19ubuntu1) 11.2.0
gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0
netCDF 4.8.1
netCDF-Fortran 4.5.4
GNU Make 4.3 - Built for x86_64-pc-linux-gnu

How can i fix this leak message, can i ignore it? The roms parser reads the yaml file twice, is it just telling me that?
I'm also new to linux (ubuntu 22.04) so sorry if im missing something very simple.


Kind regards!

[fmoraes]

Hey,

I am also trying to run this UPWELLING TEST CASE and got the same kind of error associated with Memory Leak.
I noticed that the created .nc have contents that are really similar to the examples in the https://www.myroms.org/wiki/UPWELLING_CASE, so my question is,:
Can I ignore this memory leak error or it's something important to solve?

Best regards,
Francisco Moraes

[jcwarner]

not sure what these are, but if you got a netcdf output file, then the model ran fine.
can you post
Build/mod_arrays.f90
that seems to come up a lot.
thanks
j

[bernacosenza]

Hello jcwarner
Thank you so much for trying to help with this issue!
The Build/mod_arrays.f90 file is attached.

Kind regards,
Bernardo

[jcwarner]

ok i need another one. Build/mod_ocean.f90
-j

[arango]

What version of gfortran are you using? I don't have any memory leaks with gfortran and the upwelling test case. Anyway, you get what you pay for the compiler. I have to make some modifications to the YAML parser because gfortran does not support some features of Fortran-2003. It is ridiculous how bad the compiler is for Object Oriented Programming and recursivity. If you have access to ifort, I will recommend it. I think that there are versions of ifort that are free. You may find that compiler is much better.

[bernacosenza]

Dear jcwarner and arango,
Thank you very much for your replies!

I will try to get access to ifort soon, my current version of gfortran is:
gfortran --version
GNU Fortran (Ubuntu 11.2.0-19ubuntu1) 11.2.0

The Build/mod_ocean.f90 file is attached.

Thanks again for your help, i will make another post of my results when i try it with ifort.

Bernardo

[jcwarner]

all those 'mem leaks' are for calls to allocate state variables such as

allocate ( OCEAN(ng) % rubar(LBi:UBi,LBj:UBj,2) )
allocate ( OCEAN(ng) % rvbar(LBi:UBi,LBj:UBj,2) )
allocate ( OCEAN(ng) % rzeta(LBi:UBi,LBj:UBj,2) )
allocate ( OCEAN(ng) % ubar(LBi:UBi,LBj:UBj,3) )
allocate ( OCEAN(ng) % vbar(LBi:UBi,LBj:UBj,3) )
allocate ( OCEAN(ng) % zeta(LBi:UBi,LBj:UBj,3) )
allocate ( OCEAN(ng) % pden(LBi:UBi,LBj:UBj,N(ng)) )
allocate ( OCEAN(ng) % rho(LBi:UBi,LBj:UBj,N(ng)) )
allocate ( OCEAN(ng) % ru(LBi:UBi,LBj:UBj,0:N(ng),2) )
allocate ( OCEAN(ng) % rv(LBi:UBi,LBj:UBj,0:N(ng),2) )
allocate ( OCEAN(ng) % t(LBi:UBi,LBj:UBj,N(ng),3,NT(ng)) )
allocate ( OCEAN(ng) % u(LBi:UBi,LBj:UBj,N(ng),2) )
allocate ( OCEAN(ng) % v(LBi:UBi,LBj:UBj,N(ng),2) )
allocate ( OCEAN(ng) % W(LBi:UBi,LBj:UBj,0:N(ng)) )
allocate ( OCEAN(ng) % wvel(LBi:UBi,LBj:UBj,0:N(ng)) )

These are standard allocations.
I found this:
https://stackoverflow.com/questions/680 ... rogramming

A "leak" is when you create or allocate a resource, but not destroy or free it. Like when you call malloc but never free. That's a leak.

so maybe the model is not deallocating rubar, rvbar etc upon termination and the leak sanitizer program thinks it is a leak, but it happens upon exit, we are done, so does it really matter.
the output should be as expected.

-j

[arango]

Well, that is peculiar. If you are using a relative new version of ROMS, you will notice that in the Build_roms directory, the master.f90 file has:

Code: Select all

!
!-----------------------------------------------------------------------
!  Terminate ocean model execution: flush and close all IO files.
!-----------------------------------------------------------------------
!
      CALL ROMS_finalize
      CALL finalize_pio
      CALL ROMS_deallocate_arrays
      CALL mpi_finalize (MyError)

The routine ROMS_deallocate_arrays in (mod_arrays.f90) has

Code: Select all

!
!-----------------------------------------------------------------------
!  Deallocate all structures.
!-----------------------------------------------------------------------
!
      DO ng=1,Ngrids
        CALL deallocate_average (ng)
        CALL deallocate_boundary (ng)
        IF (LallocateClima.or.Lclimatology(ng)) THEN
          CALL deallocate_clima (ng)
        END IF
        CALL deallocate_coupling (ng)
        CALL deallocate_diags (ng)
        CALL deallocate_forces (ng)
        CALL deallocate_grid (ng)
        CALL deallocate_mixing (ng)
        CALL deallocate_ocean (ng)
        IF (LuvSrc(ng).or.LwSrc(ng).or.ANY(LtracerSrc(:,ng))) THEN
          CALL deallocate_sources (ng)
        END IF
      END DO
!
!  Deallocate I/O derived-type structures.
!
      CALL deallocate_iounits
!
!  Deallocate main configuration dimensions and associated parameters.
!
      CALL deallocate_param

For the UPWELLING test case. So, every single array in the derived-type structures is deallocated at the computations' end. It is just that gfortran is having hallucinations and indigestions when deallocating. I think that this is where you are having a problem. It is a compiler bug. In Fortran, nowadays, if you deallocate the derived-type structure, the compiler must deallocate ALL the arrays that it contains, according to the standard!

Code: Select all

!
!-----------------------------------------------------------------------
!  Deallocate derived-type OCEAN structure.
!-----------------------------------------------------------------------
!
      IF (ng.eq.Ngrids) THEN
        IF (allocated(OCEAN)) deallocate ( OCEAN )
      END IF

As I mentioned before, gfortan has many bugs. It is a free, temperamental compiler with good and bad things. I ran the UPWELLING test case with gfortran and I cannot reproduce your behavior.

I am using:

Code: Select all

COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin20/11.2.0/lto-wrapper
Target: x86_64-apple-darwin20
gcc version 11.2.0 (MacPorts gcc11 11.2.0_3)

So, your solution is acceptable. Some of the errors will go away when removing the aggressive compiling flags. We put those bold flags to check both ROMS and the compiler.