[Users] Code failure apparently due to changes in Reduction.c

Roland Haas rhaas at illinois.edu
Tue Aug 17 14:55:04 CDT 2021


Hello Yosef,

> Thanks. One final question, when using CCTK_Reduce, which should we
> use CCTK_ReductionArrayHandle to get the handle?
CCTK_Reduce is "old" inerface but for grid-functions (and grid arrays)
but not local arrays. For for CCTK_Reduce you must use
CCTK_ReductionHandle and use the handle returned by it.

The reason for two different types of handles and two different
functions (CCTK_ReductionArrayHandle and CCTK_ReductionHandle) is that
these are actually different reduction operator functions registered by
CarpetReduce.

The handle number depends on the order in which they are registered. It
just so happens that Carpet registers functions for operations in
CCTK_Reduce and CCTK_ReduceReduceLocalArray1D in the same order (and
supports the same operations for both). So eg the "sum" name ended up
being the same handle integer for both. This was *purely* by accident
and *entirely* dependent on the order in which Carpet called the two
respective Registration functions and in fact the registered functions
(for CCTK_Reduce and CCTK_ReduceReduceLocalArray1D) are different.

The respective CarpetReduce code (in reduce.c) is:

  CCTK_RegisterReductionOperator(count_GVs, "count");
  CCTK_RegisterReductionOperator(minimum_GVs, "minimum");
  CCTK_RegisterReductionOperator(maximum_GVs, "maximum");
  CCTK_RegisterReductionOperator(product_GVs, "product");
  CCTK_RegisterReductionOperator(sum_GVs, "sum");
  CCTK_RegisterReductionOperator(sum_abs_GVs, "sum_abs");
  CCTK_RegisterReductionOperator(sum_squared_GVs, "sum_squared");
  CCTK_RegisterReductionOperator(sum_abs_squared_GVs, "sum_abs_squared");
  CCTK_RegisterReductionOperator(average_GVs, "average");
  CCTK_RegisterReductionOperator(norm1_GVs, "norm1");
  CCTK_RegisterReductionOperator(norm2_GVs, "norm2");
  CCTK_RegisterReductionOperator(norm_inf_GVs, "norm_inf");

[...]

  CCTK_RegisterReductionArrayOperator(count_arrays, "count");
  CCTK_RegisterReductionArrayOperator(minimum_arrays, "minimum");
  CCTK_RegisterReductionArrayOperator(maximum_arrays, "maximum");
  CCTK_RegisterReductionArrayOperator(product_arrays, "product");
  CCTK_RegisterReductionArrayOperator(sum_arrays, "sum");
  CCTK_RegisterReductionArrayOperator(sum_abs_arrays, "sum_abs");
  CCTK_RegisterReductionArrayOperator(sum_squared_arrays, "sum_squared");
  CCTK_RegisterReductionArrayOperator(sum_abs_squared_arrays,
                                      "sum_abs_squared");
  CCTK_RegisterReductionArrayOperator(average_arrays, "average");
  CCTK_RegisterReductionArrayOperator(norm1_arrays, "norm1");
  CCTK_RegisterReductionArrayOperator(norm2_arrays, "norm2");
  CCTK_RegisterReductionArrayOperator(norm_inf_arrays, "norm_inf");


Yours,
Roland

> 
> 
> On 8/17/21 3:01 PM, Roland Haas wrote:
> > Hello Yosef,
> >  
> >> We were using Carpet and the actual call was to
> >>
> >> CCTK_ReduceLocArrayToArray1D
> >>
> >> Is this valid in Carpet?  
> > No, unfortunately this is not valid in Carpet.
> >
> > For two reasons actually:
> >
> > The combination CCTK_LocalArrayReductionHandle and
> > CCTK_ReduceLocArrayToArray1D is never valid, since
> > CCTK_LocalArrayReductionHandle  is "new" interface, while
> > CCTK_ReduceLocArrayToArray1D is "old" interface. You can see it
> > among the list of functions in my previous email.
> >
> > Further "CCTK_LocalArrayReductionHandle", being "new" interface, is
> > never valid for Carpet, since Carpet only supports the "old"
> > interface.
> >
> > So "no", "no".
> >
> > "CCTK_ReduceLocArrayToArray1D" however is "old" interface, so is
> > valid with Carpet, but you must use "CCTK_ReductionArrayHandle" to
> > get the reduction handle for it. You must *not* use
> > "CCCTK_ReductionHandle" or "CCTK_LocalArrayReductionHandle" to get
> > a handle to use with "CCTK_ReduceLocArrayToArray1D".
> >
> > Nope this helps. The functions names a confusing, unfortunately,
> > and the fact that the "old" interface, which is the only one Carpet
> > supports, is not fully documented in the CCTK reference anymore,
> > does not really help.
> >
> > Yours,
> > Roland
> >  
> >> On 8/17/21 12:59 PM, Roland Haas wrote:  
> >>> Hello Yosef,
> >>>
> >>> there's a couple different reduction interfaces and the handle
> >>> you get must match.
> >>>
> >>> It depends a bit on the drive you are using.
> >>>
> >>> Carpet only supports the "old style" reduction interface that
> >>> uses:
> >>>
> >>> CCTK_Reduce
> >>> CCTK_ReductionHandle
> >>>
> >>> CCTK_ReduceLocalScalar
> >>> CCTK_ReductionArrayHandle
> >>> and:
> >>> CCTK_ReduceArray
> >>> CCTK_ReduceLocalArray1D
> >>>
> >>> it does not support the new interface
> >>> CCTK_LocalArrayReductionHandle at all.
> >>>
> >>> PUGH supports the new one and (I think) the old one as well. The
> >>> new one uses:
> >>>
> >>> CTK_LocalArrayReductionHandle
> >>> CCTK_ReduceLocalArrays
> >>>
> >>> See
> >>> https://urldefense.com/v3/__https://www.einsteintoolkit.org/referencemanual/ReferenceManual.html*x1-1000A__;Iw!!DZ3fjg!vO69j0_NDEC1JMkgMyZSdz57Nk1EjyHTBh3FU214vo8W15081AZ6_X93p6b5_AlO$
> >>>  and search for A488.
> >>>
> >>> So are you using this with PUGH or Carpet? With Carpet it must
> >>> fail (not supported at all), with PUGH it should work as long as
> >>> you sue the correct set of calls ie
> >>> CCTK_LocalArrayReductionHandle + CCTK_ReduceLocalArrays (for PUGH
> >>> only).
> >>>
> >>> Yours,
> >>> Roland  
> >>>   >>>> Hi,  
> >>>>
> >>>>     A code that we are using seems to no longer work with
> >>>> Cactus. The issue seems to be that the code called
> >>>> CCTK_LocalArrayReductionHandle. The code, as checked out,
> >>>> produces errors because the appropriate handle isn't found. If I
> >>>> modify the function as below,  I no longer get the error message
> >>>>
> >>>>
> >>>>
> >>>> int CCTK_LocalArrayReductionHandle(const char *reduction)
> >>>> {
> >>>>      int handle;
> >>>>
> >>>>
> >>>>      handle = Util_GetHandle(LocalArrayReductionOperators,
> >>>> reduction, NULL); if (handle < 0)
> >>>>      {
> >>>>        CCTK_VWarn(1,__LINE__,__FILE__,"Cactus",
> >>>>                   "CCTK_LocalArrayReductionHandle: No handle:
> >>>> '%d' found for reduction operator "
> >>>>                   "'%s'", handle, reduction);
> >>>>      }
> >>>>
> >>>>      handle += ARRAY_OPERATOR_HANDLE_OFFSET; //// MY changes
> >>>>
> >>>>      return handle;
> >>>> }
> >>>>
> >>>>
> >>>> Should we no longer use CCTK_LocalArrayReductionHandle?  
> >>>>   >>>   >  
> >  



-- 
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from http://pgp.mit.edu .
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20210817/bd0b39fb/attachment.bin 


More information about the Users mailing list