Memory leaks - Upwelling
-
- Posts: 3
- Joined: Sat May 07, 2022 2:50 pm
- Location: University of the Estate of Rio de Janeiro
Memory leaks - Upwelling
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!
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!
- Attachments
-
output.txt
- (380.95 KiB) Downloaded 414 times
Re: Memory leaks - Upwelling
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
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
Re: Memory leaks - Upwelling
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
can you post
Build/mod_arrays.f90
that seems to come up a lot.
thanks
j
-
- Posts: 3
- Joined: Sat May 07, 2022 2:50 pm
- Location: University of the Estate of Rio de Janeiro
Re: Memory leaks - Upwelling
Hello jcwarner
Thank you so much for trying to help with this issue!
The Build/mod_arrays.f90 file is attached.
Kind regards,
Bernardo
Thank you so much for trying to help with this issue!
The Build/mod_arrays.f90 file is attached.
Kind regards,
Bernardo
- Attachments
-
mod_arrays.f90
- (9.6 KiB) Downloaded 372 times
Re: Memory leaks - Upwelling
ok i need another one. Build/mod_ocean.f90
-j
-j
- arango
- Site Admin
- Posts: 1356
- Joined: Wed Feb 26, 2003 4:41 pm
- Location: DMCS, Rutgers University
- Contact:
Re: Memory leaks - Upwelling
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.
-
- Posts: 3
- Joined: Sat May 07, 2022 2:50 pm
- Location: University of the Estate of Rio de Janeiro
Re: Memory leaks - Upwelling
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
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
- Attachments
-
mod_ocean.f90
- (13.13 KiB) Downloaded 393 times
Re: Memory leaks - Upwelling
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
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
- Site Admin
- Posts: 1356
- Joined: Wed Feb 26, 2003 4:41 pm
- Location: DMCS, Rutgers University
- Contact:
Re: Memory leaks - Upwelling
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:
The routine ROMS_deallocate_arrays in (mod_arrays.f90) has
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!
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:
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.
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)
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
Code: Select all
!
!-----------------------------------------------------------------------
! Deallocate derived-type OCEAN structure.
!-----------------------------------------------------------------------
!
IF (ng.eq.Ngrids) THEN
IF (allocated(OCEAN)) deallocate ( OCEAN )
END IF
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)