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 <[email protected]> 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 > [email protected] > http://lists.einsteintoolkit.org/mailman/listinfo/users >
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
