[Developers] should we document that CCTK_MyProc(NULL) works?

Tom Goodale goodale at cct.lsu.edu
Fri Jan 12 10:48:49 CST 2007


Hi,

I'd forgotten that this could happen when I driver is present as well. 
Good point.  Drivers should certainly deal with this case.  So 
documentaing for users that the result is 'undefined' but that drivers 
will do their best is probably the best way to go.

Cheers,

Tom


On Fri, 12 Jan 2007, Erik Schnetter wrote:

> Err, not documenting it at all is not a good idea.  This means that driver 
> developers have to find out the hard way why their drivers crash, and why 
> passing a null pointer is necessary.  I would document it as "MyProc and 
> nProcs have to handle that case without crashing", but also telling the user 
> that the results may not be as expected.
>
> -erik
>
> On Jan 12, 2007, at 10:36:36, Tom Goodale wrote:
>
>> The only problem is that in principle drivers could be using a different
>> processor mapping - e.g. when using MPI the driver could use a different
>> communicator - which would give a different result with NULL than with a
>> cGH, so I would prefer to not document that NULL is acceptable.  It is
>> only used in the flesh in extreme cases, which are mainly before a driver
>> has been initialised.
>> 
>> Cheers,
>> 
>> Tom
>> 
>> On Fri, 12 Jan 2007, David Rideout wrote:
>> 
>>> If it is guaranteed to work then there is no need for the argument.
>>> Perhaps you might write that most drivers behave this way, but there
>>> is no guarantee?  And that the calling routine might check that it
>>> returns a valid (non-negative) value?
>>> 
>>> Cheers,
>>> David
>>> 
>>> On 1/12/07, Jonathan Thornburg <jthorn at aei.mpg.de> wrote:
>>>> Hi,
>>>> 
>>>> With all current drivers (or at least all known to the people I've
>>>> talked to), it's legal to call CCTK_MyProc() with a NULL GH pointer,
>>>> and doing so works (CCTK_MyProc() returns the correct result).
>>>> 
>>>> IMHO this is very useful behavior.  For example, it lets code which
>>>> doesn't have a GH still generate unique filenames for logging debug
>>>> data.  The problem is, right now this behavior is not documented in
>>>> the Cactus Reference Manual.
>>>> 
>>>> Does anyone object to my documenting the current behavior in the
>>>> Cactus Reference Manual?  Should we go farther and also promise
>>>> (document) that this is guaranteed to work for any driver?
>>>> 
>>>> ciao,
>>>> 
>>>> --
>>>> -- Jonathan Thornburg <jthorn at aei.mpg.de>
>>>>   Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
>>>>   Golm, Germany, "Old Europe"     http://www.aei.mpg.de/~jthorn/home.html
>>>>   "Washing one's hands of the conflict between the powerful and the
>>>>    powerless means to side with the powerful, not to be neutral."
>>>>                                      -- quote by Freire / poster by Oxfam
>>>> 
>>>> _______________________________________________
>>>> Developers mailing list
>>>> Developers at cactuscode.org
>>>> http://www.cactuscode.org/mailman/listinfo/developers
>>>> 
>>> _______________________________________________
>>> Developers mailing list
>>> Developers at cactuscode.org
>>> http://www.cactuscode.org/mailman/listinfo/developers
>>> 
>> _______________________________________________
>> Developers mailing list
>> Developers at cactuscode.org
>> http://www.cactuscode.org/mailman/listinfo/developers
>> 
>
>
>


More information about the Developers mailing list