Re: NCL Wrapit + memory question

From: jonathan meyer <tallj03_at_nyahnyahspammersnyahnyah>
Date: Mon Nov 18 2013 - 15:06:36 MST

Hi Dennis,
Thanks for pointing this out. I have fixed the argument declaration but still see the memory growing with each loop iteration.
After doing some simplification of the script (read gutting everything and adding one line each time to find which variable is causing the memory to grow) I found that just by reading in the 'Z' variable from the addfiles variable, the memory is growing.

The following two simplified code snippets show 1) code with the memory growth issue, and 2) no memory growth issues.
1)do yy = s_yy, e_yy f_list = systemfunc("ls " + dir1 + yy + "/pgbhnl/*.grb2") f_in = addfiles(f_list, "r") ListSetType(f_in, "join") do z = 0, n_lev-1
          ****define .nc attributes
           Z = f_in[:]->HGT_P0_L100_GLL0(:,z,::-1,:)
           ncf->Ua = (/Z(:,::-1,:)/) delete([/Z, ncf/]) end do
      delete([/f_list, f_in/])end do

2)do yy = s_yy, e_yy f_list = systemfunc("ls " + dir1 + yy + "/pgbhnl/*.grb2") f_in = addfiles(f_list, "r") ListSetType(f_in, "join") do z = 0, n_lev-1 ****define .nc attributes

         Z = new((/n_time,n_lat,n_lon/), float) Z = random_normal(10,1.5,(/n_time,n_lat,n_lon/))
         ncf->Ua = (/Z(:,::-1,:)/) delete([/Z, ncf/]) end do
      delete([/f_list, f_in/])end do
As you can see, the only difference is that the code that resets the memory each 'z' iteration is not using the f_in addfiles pointer, but a generic (yet same sized) variable created within the loop. Is it possible for the addfiles function to keep something stored in memory?
Thanks for all your time and effort!!!
Jon

> Date: Mon, 18 Nov 2013 10:00:41 -0700
> From: shea@ucar.edu
> To: tallj03@hotmail.com; ncl-talk@ucar.edu
> Subject: Re: NCL Wrapit + memory question
>
> I think
>
> C NCLFORTSTART
> SUBROUTINE UGEO (N_T,N_LAT,LAT,N_LON,LAT_BDYN,LAT_BDYS,UGRAD,UG)
> REAL UGRAD(N_LON,N_LAT,N_T),UG(N_LON,N_LAT,N_T)
> REAL LAT(N_LAT)
> REAL F_PARAM(N_LON,N_LAT,N_T)
> REAL G_CONST, OMEGA, PI, LAT_BDYN, LAT_BDYS
> C NCLEND
>
> should be
>
> C NCLFORTSTART
> SUBROUTINE UGEO (N_T,N_LAT,LAT,N_LON,LAT_BDYN,LAT_BDYS,UGRAD,UG)
> REAL UGRAD(N_LON,N_LAT,N_T),UG(N_LON,N_LAT,N_T)
> REAL LAT(N_LAT)
> REAL G_CONST, OMEGA, PI, LAT_BDYN, LAT_BDYS
> C NCLEND
> REAL F_PARAM(N_LON,N_LAT,N_T)
>
> ================================
>
> The variable 'F' is not an argument being passed from the NCL to
> the fortran subroutine. Rather, it is an automatic array. It should
> not be included between the the NCLFORTSTART/NCLEND delimeters.
> Only arguments being passed should be included between the delimiters.
>
> I speculate that is causing the issue.
>
> Good Luck
>
>
>
> On 11/15/13 2:15 PM, jonathan meyer wrote:
> > Hi,
> > I've been quite happy to learn how useful the wrapit functionality can be in NCL. While I've successfully gotten wrapit to work, I am seeing memory usage grow with each call to my subroutines.
> > I've checked to make sure unused ncl variables are being deleted each time through my loop.
> > Being rather green with the workings of fortran memory allocation, I'm wondering if there is something I'm missing in my fortran code that is allowing the arrays to remain in memory? I was under the impression that non-allocated memory in the subroutine would be removed at the 'end' command, but maybe this isn't the case for how I've coded mine.
> > Attached is a code snippet of the NCL code for the loop the wrapit is being used, as well as the .f script containing my subroutines.
> > As always, thanks in advance.
> > Jon
> >
> >
> >
> > _______________________________________________
> > ncl-talk mailing list
> > List instructions, subscriber options, unsubscribe:
> > http://mailman.ucar.edu/mailman/listinfo/ncl-talk
> >
                                               

_______________________________________________
ncl-talk mailing list
List instructions, subscriber options, unsubscribe:
http://mailman.ucar.edu/mailman/listinfo/ncl-talk
Received on Mon Nov 18 15:06:52 2013

This archive was generated by hypermail 2.1.8 : Fri Nov 22 2013 - 09:36:32 MST