[Carpet] memory allocation in global loop-local mode?
Bela Szilagyi
szilagyi at aei.mpg.de
Thu Aug 24 15:29:32 CEST 2006
OK, then should I post a formal bug-report? In case it helps remind you.
Bela.
On Thursday 24 August 2006 15:15, Erik Schnetter wrote:
> On Aug 24, 2006, at 06:26:31, Bela Szilagyi wrote:
> > my_var is a gridfunction. Given that I don't know the meaning of
> > "global
> > loop-local" I can't tell whether this implies (according to your
> > reply) if
> > memory should be there or not.
> >
> > My current work-around is a static storage request. Is this the
> > best one can
> > do?
> >
> > Bela.
> >
> > On Wednesday 23 August 2006 21:21, Erik Schnetter wrote:
> >> On Aug 23, 2006, at 13:59:13, Bela Szilagyi wrote:
> >>> In one of my thorns (taken after AHFinderDirect's mask-setter
> >>> routine schedule
> >>> bing) I had
> >>>
> >>>
> >>> schedule my_routine in my_group
> >>> {
> >>> lang: C
> >>> storage: my_var
> >>> options: global loop-local
> >>> } "..."
> >>>
> >>>
> >>> while the parfile says
> >>>
> >>> Carpet::enable_all_storage = no
> >>>
> >>> The routine ended up being called, at least once within the first
> >>> course
> >>> time-step worth of time, with my_var being set to NULL.
> >>>
> >>> A bit of peaking into it with gdb has shown that not all calls to
> >>> the routine
> >>> were lacking the memory, but, in the one case this variable would
> >>> have been
> >>> used, the memory was not there.
> >>>
> >>> Is this a bug or a feature? In other terms -- does "global loop-
> >>> local" imply
> >>> that one should not assume memory associated with tmp_var ?
> >>
> >> That depends on what my_var is. If it is a grid function, then in
> >> local mode, memory should always be there, otherwise not. If it is a
> >> grid arrays or grid scalar, then memory should always be there.
>
> global loop-local means that the routine is called in local mode.
> That means that storage should be there.
>
> -erik
--
Bela Szilagyi
Max-Planck-Institut für Gravitationsphysik
Albert-Einstein-Institut
Tel: +49 331 567 7632
Fax: +49 331 567 7649
More information about the developers
mailing list