[Users] Code failure apparently due to changes in Reduction.c
Lorenzo Ennoggi
lorenzo.ennoggi at gmail.com
Mon Sep 13 11:32:01 CDT 2021
Dear Roland,
in the above you say that
> > 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.
but then
"CCTK_ReduceLocArrayToArray1D" however is "old" interface, so is valid
> with Carpet, but you must use "CCTK_ReductionArrayHandle" to get the
> reduction handle for it.
So is the call to CCTK_ReduceLocArrayToArray1D valid or not in Carpet? I'm
asking because in Spritz we use Carpet and we have a call to
CCTK_ReduceLocArrayToArray1D with the handle obtained from
CCTK_ReductionArrayHandle (which should work according to the second thing
you wrote) and this gives an error in reduction.
Thank you,
Lorenzo
Il giorno mar 17 ago 2021 alle ore 21:55 Roland Haas <rhaas at illinois.edu>
ha scritto:
> 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 .
> _______________________________________________
> Users mailing list
> Users at einsteintoolkit.org
> http://lists.einsteintoolkit.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20210913/b20d076d/attachment.html
More information about the Users
mailing list