Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory isn't deallocated in some of the init_interp code #1032

Closed
ekluzek opened this issue Jun 5, 2020 · 2 comments
Closed

Memory isn't deallocated in some of the init_interp code #1032

ekluzek opened this issue Jun 5, 2020 · 2 comments
Assignees
Labels
enhancement new capability or improved behavior of existing capability

Comments

@ekluzek
Copy link
Collaborator

ekluzek commented Jun 5, 2020

This was noticed in looking at #1010. Some of the memory allocated in running init_interp is NOT deallocated afterwards. For example, there are local pointer's that allocate memory that should become allocatable so that memory will be deallocated after it goes out of scope. This is in init_interp.F90.

@ekluzek ekluzek added enhancement new capability or improved behavior of existing capability code health improving internal code structure to make easier to maintain (sustainability) labels Jun 5, 2020
@ekluzek ekluzek self-assigned this Jun 5, 2020
@billsacks billsacks changed the title Memory isn't allocated in some of the init_interp code Memory isn't deallocated in some of the init_interp code Jun 5, 2020
@billsacks
Copy link
Member

Copying over some thoughts from #1010 that are relevant here:

As @ekluzek mentioned above: where possible, rather than adding explicit deallocate statements, I think it would be better to change pointer variables to allocatables. Then they will automatically be deallocated. If they are pointers because something else is pointing to them, then they can be declared as allocatable, target. At a glance, it looks like this may be possible for the pointers declared in initInterp.F90, but it likely isn't possible for some / all of the pointers in derived types (because you can't use the target attribute for a pointer in a derived type).

My initial thought is that, for every pointer in the init_interp code, we need to either: (a) deallocate it (possibly with a final subroutine), or (b) change it to an allocatable.

The main trickiness is that I think some of the derived types that I added, which use pointers, need final subroutines to deallocate their pointer components.

@billsacks billsacks removed the code health improving internal code structure to make easier to maintain (sustainability) label Jun 5, 2020
@billsacks billsacks assigned billsacks and unassigned ekluzek Jun 7, 2020
@billsacks
Copy link
Member

@ekluzek I'll take this. I'm going to work on it today. I have a hunch that this actually might solve the initial problem, but that there are actually two separate issues and so the second might have masked the first in your testing. More soon....

ekluzek added a commit to ekluzek/CTSM that referenced this issue Jun 10, 2020
Deallocate memory after running init_interp

Many of the pointer arrays in init_interp were not being deallocated
when init_interp finished. This was a particular problem because some of
these arrays were allocated for the full global source grid on each
processor, so the memory use was significant. This tag fixes this issue.

This issue is documented in ESCOMP#1010
and ESCOMP#1032.

Resolves ESCOMP#1032 (Memory isn't deallocated in some of the
init_interp code)
samsrabin pushed a commit to samsrabin/CTSM that referenced this issue Sep 17, 2024
…porting

Land use change version 1

The patch-level land use labels are extended from their prior values of
only primary or secondary lands to also include pasture, rangeland, and
crops. Land use change in FATES is treated as a disturbance rate (in
area/time units) from existing patches with a given land use label to
new patches with the new land use label. Thus a fourtg distinct type
of disturbances is added to the existing treefall, fire, and logging
types.

The driving data for this run mode is from the Land Use Harmonization 2
state and transition datasets.  The workflow tool for processing this
input was previously developed with pull request ESCOMP#1032.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement new capability or improved behavior of existing capability
Projects
Status: Done (non release/external)
Development

No branches or pull requests

2 participants