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/... 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?
>> >