I may be overlooking something, but doesn't Fortran already keep track of whether arrays are allocated? There is no need to introduce a logical variable, one can call "allocated" instead.
Another point is that explicit memory management at shutdown isn't really useful. It adds more code, adds complexity to keep track of things, and delays the shutdown because extra things happen.
I would simply call "allocate" in ENOSetup, schedule the routine such that it is called only once, and leave it at this, removing about 20 or 30 lines of code and the possibility of error.
-erik
On Mon, Nov 21, 2011 at 10:45 AM, roland.haas@physics.gatech.edu wrote:
User: rhaas Date: 2011/11/21 09:45 AM
Modified: /trunk/ schedule.ccl /trunk/src/ GRHydro_ENOReconstruct.F90
Log: allocate/deallocate ENO scalars in global mode
really all I need is that this happens only once. Allocation was already protected by a grid scalar, unfortunately deallocation did not check/reset this scalar
File Changes:
Directory: /trunk/src/
File [modified]: GRHydro_ENOReconstruct.F90 Delta lines: +5 -2 =================================================================== --- trunk/src/GRHydro_ENOReconstruct.F90 2011-11-21 15:43:52 UTC (rev 300) +++ trunk/src/GRHydro_ENOReconstruct.F90 2011-11-21 15:45:12 UTC (rev 301) @@ -128,8 +128,11 @@
CCTK_INT :: deallocstat
- deallocate(eno_coeffs, STAT = deallocstat)
- if (deallocstat .ne. 0) call CCTK_WARN(0, "Failed to deallocate ENO coefficients.")
- if(coeffs_allocated) then
- deallocate(eno_coeffs, STAT = deallocstat)
- if (deallocstat .ne. 0) call CCTK_WARN(0, "Failed to deallocate ENO coefficients.")
- coeffs_allocated = .false.
- endif
end subroutine GRHydro_ENOShutdown
Directory: /trunk/
File [modified]: schedule.ccl Delta lines: +2 -0 =================================================================== --- trunk/schedule.ccl 2011-11-21 15:43:52 UTC (rev 300) +++ trunk/schedule.ccl 2011-11-21 15:45:12 UTC (rev 301) @@ -377,11 +377,13 @@
schedule GRHydro_ENOSetup AT CCTK_Basegrid {
- OPTIONS: global
LANG:Fortran } "Coefficients for ENO reconstruction"
schedule GRHydro_ENOShutdown AT CCTK_Terminate BEFORE Driver_Terminate {
- OPTIONS: global
LANG:Fortran } "Deallocate ENO coefficients"
Commits mailing list Commits@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/commits
Hello Erik,
I may be overlooking something, but doesn't Fortran already keep track of whether arrays are allocated? There is no need to introduce a logical variable, one can call "allocated" instead.
That is certainly true. The status variable is extra complication and one could simply use Fortran's ALLOCATED() function to check status.
Another point is that explicit memory management at shutdown isn't really useful. It adds more code, adds complexity to keep track of things, and delays the shutdown because extra things happen.
I agree that it adds extra complication and is not terribly useful. We can certainly remove it. I doubt calling the equivalent of free() slows down shutdown noticably though :-) I did the minimal change without modifying the initial intent of the author (since the status variable was already present).
I would simply call "allocate" in ENOSetup, schedule the routine such that it is called only once, and leave it at this, removing about 20 or 30 lines of code and the possibility of error.
Fine with me. If there are not protests I will do so near the end of the week.
Yours, Roland
On 21/11/11 16:20, Roland Haas wrote:
Another point is that explicit memory management at shutdown isn't really useful. It adds more code, adds complexity to keep track of things, and delays the shutdown because extra things happen.
I agree that it adds extra complication and is not terribly useful. We can certainly remove it. I doubt calling the equivalent of free() slows down shutdown noticably though :-) I did the minimal change without modifying the initial intent of the author (since the status variable was already present).
I would simply call "allocate" in ENOSetup, schedule the routine such that it is called only once, and leave it at this, removing about 20 or 30 lines of code and the possibility of error.
Fine with me. If there are not protests I will do so near the end of the week.
I protest!
Really, I know it's no big deal, but I'd be just as aesthetically offended with the lack of a free() as with the lack of a deallocate().
Ian
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Ian Hawke -
Roland Haas