<div dir="ltr">Dear Roland,<div>in the above you say that</div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im" style="color:rgb(80,0,80)">> We were using Carpet and the actual call was to<br></span><span class="gmail-im" style="color:rgb(80,0,80)">><br></span><span class="gmail-im" style="color:rgb(80,0,80)">> CCTK_ReduceLocArrayToArray1D<br></span><span class="gmail-im" style="color:rgb(80,0,80)">><br></span><span class="gmail-im" style="color:rgb(80,0,80)">> Is this valid in Carpet?<br></span>No, unfortunately this is not valid in Carpet.</blockquote><div> </div><div>but then</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">"<font face="monospace">CCTK_ReduceLocArrayToArray1D</font>" however is "old" interface, so is valid<br>with Carpet, but you must use "<font face="monospace">CCTK_ReductionArrayHandle</font>" to get the<br>reduction handle for it.</blockquote><div><br></div><div>So is the call to <span style="font-family:monospace">CCTK_ReduceLocArrayToArray1D</span><font face="arial, sans-serif"> valid or not in Carpet? I'm asking because i</font>n Spritz we use Carpet and we have a call to <font face="monospace">CCTK_ReduceLocArrayToArray1D</font> with the handle obtained from <font face="monospace">CCTK_ReductionArrayHandle </font>(which should work according to the second thing you wrote) and this gives an error in reduction.</div><div><br></div><div>Thank you,</div></div><div>Lorenzo</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mar 17 ago 2021 alle ore 21:55 Roland Haas <<a href="mailto:rhaas@illinois.edu">rhaas@illinois.edu</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Yosef,<br>
<br>
> Thanks. One final question, when using CCTK_Reduce, which should we<br>
> use CCTK_ReductionArrayHandle to get the handle?<br>
CCTK_Reduce is "old" inerface but for grid-functions (and grid arrays)<br>
but not local arrays. For for CCTK_Reduce you must use<br>
CCTK_ReductionHandle and use the handle returned by it.<br>
<br>
The reason for two different types of handles and two different<br>
functions (CCTK_ReductionArrayHandle and CCTK_ReductionHandle) is that<br>
these are actually different reduction operator functions registered by<br>
CarpetReduce.<br>
<br>
The handle number depends on the order in which they are registered. It<br>
just so happens that Carpet registers functions for operations in<br>
CCTK_Reduce and CCTK_ReduceReduceLocalArray1D in the same order (and<br>
supports the same operations for both). So eg the "sum" name ended up<br>
being the same handle integer for both. This was *purely* by accident<br>
and *entirely* dependent on the order in which Carpet called the two<br>
respective Registration functions and in fact the registered functions<br>
(for CCTK_Reduce and CCTK_ReduceReduceLocalArray1D) are different.<br>
<br>
The respective CarpetReduce code (in reduce.c) is:<br>
<br>
CCTK_RegisterReductionOperator(count_GVs, "count");<br>
CCTK_RegisterReductionOperator(minimum_GVs, "minimum");<br>
CCTK_RegisterReductionOperator(maximum_GVs, "maximum");<br>
CCTK_RegisterReductionOperator(product_GVs, "product");<br>
CCTK_RegisterReductionOperator(sum_GVs, "sum");<br>
CCTK_RegisterReductionOperator(sum_abs_GVs, "sum_abs");<br>
CCTK_RegisterReductionOperator(sum_squared_GVs, "sum_squared");<br>
CCTK_RegisterReductionOperator(sum_abs_squared_GVs, "sum_abs_squared");<br>
CCTK_RegisterReductionOperator(average_GVs, "average");<br>
CCTK_RegisterReductionOperator(norm1_GVs, "norm1");<br>
CCTK_RegisterReductionOperator(norm2_GVs, "norm2");<br>
CCTK_RegisterReductionOperator(norm_inf_GVs, "norm_inf");<br>
<br>
[...]<br>
<br>
CCTK_RegisterReductionArrayOperator(count_arrays, "count");<br>
CCTK_RegisterReductionArrayOperator(minimum_arrays, "minimum");<br>
CCTK_RegisterReductionArrayOperator(maximum_arrays, "maximum");<br>
CCTK_RegisterReductionArrayOperator(product_arrays, "product");<br>
CCTK_RegisterReductionArrayOperator(sum_arrays, "sum");<br>
CCTK_RegisterReductionArrayOperator(sum_abs_arrays, "sum_abs");<br>
CCTK_RegisterReductionArrayOperator(sum_squared_arrays, "sum_squared");<br>
CCTK_RegisterReductionArrayOperator(sum_abs_squared_arrays,<br>
"sum_abs_squared");<br>
CCTK_RegisterReductionArrayOperator(average_arrays, "average");<br>
CCTK_RegisterReductionArrayOperator(norm1_arrays, "norm1");<br>
CCTK_RegisterReductionArrayOperator(norm2_arrays, "norm2");<br>
CCTK_RegisterReductionArrayOperator(norm_inf_arrays, "norm_inf");<br>
<br>
<br>
Yours,<br>
Roland<br>
<br>
> <br>
> <br>
> On 8/17/21 3:01 PM, Roland Haas wrote:<br>
> > Hello Yosef,<br>
> > <br>
> >> We were using Carpet and the actual call was to<br>
> >><br>
> >> CCTK_ReduceLocArrayToArray1D<br>
> >><br>
> >> Is this valid in Carpet? <br>
> > No, unfortunately this is not valid in Carpet.<br>
> ><br>
> > For two reasons actually:<br>
> ><br>
> > The combination CCTK_LocalArrayReductionHandle and<br>
> > CCTK_ReduceLocArrayToArray1D is never valid, since<br>
> > CCTK_LocalArrayReductionHandle is "new" interface, while<br>
> > CCTK_ReduceLocArrayToArray1D is "old" interface. You can see it<br>
> > among the list of functions in my previous email.<br>
> ><br>
> > Further "CCTK_LocalArrayReductionHandle", being "new" interface, is<br>
> > never valid for Carpet, since Carpet only supports the "old"<br>
> > interface.<br>
> ><br>
> > So "no", "no".<br>
> ><br>
> > "CCTK_ReduceLocArrayToArray1D" however is "old" interface, so is<br>
> > valid with Carpet, but you must use "CCTK_ReductionArrayHandle" to<br>
> > get the reduction handle for it. You must *not* use<br>
> > "CCCTK_ReductionHandle" or "CCTK_LocalArrayReductionHandle" to get<br>
> > a handle to use with "CCTK_ReduceLocArrayToArray1D".<br>
> ><br>
> > Nope this helps. The functions names a confusing, unfortunately,<br>
> > and the fact that the "old" interface, which is the only one Carpet<br>
> > supports, is not fully documented in the CCTK reference anymore,<br>
> > does not really help.<br>
> ><br>
> > Yours,<br>
> > Roland<br>
> > <br>
> >> On 8/17/21 12:59 PM, Roland Haas wrote: <br>
> >>> Hello Yosef,<br>
> >>><br>
> >>> there's a couple different reduction interfaces and the handle<br>
> >>> you get must match.<br>
> >>><br>
> >>> It depends a bit on the drive you are using.<br>
> >>><br>
> >>> Carpet only supports the "old style" reduction interface that<br>
> >>> uses:<br>
> >>><br>
> >>> CCTK_Reduce<br>
> >>> CCTK_ReductionHandle<br>
> >>><br>
> >>> CCTK_ReduceLocalScalar<br>
> >>> CCTK_ReductionArrayHandle<br>
> >>> and:<br>
> >>> CCTK_ReduceArray<br>
> >>> CCTK_ReduceLocalArray1D<br>
> >>><br>
> >>> it does not support the new interface<br>
> >>> CCTK_LocalArrayReductionHandle at all.<br>
> >>><br>
> >>> PUGH supports the new one and (I think) the old one as well. The<br>
> >>> new one uses:<br>
> >>><br>
> >>> CTK_LocalArrayReductionHandle<br>
> >>> CCTK_ReduceLocalArrays<br>
> >>><br>
> >>> See<br>
> >>> <a href="https://urldefense.com/v3/__https://www.einsteintoolkit.org/referencemanual/ReferenceManual.html*x1-1000A__;Iw!!DZ3fjg!vO69j0_NDEC1JMkgMyZSdz57Nk1EjyHTBh3FU214vo8W15081AZ6_X93p6b5_AlO$" rel="noreferrer" target="_blank">https://urldefense.com/v3/__https://www.einsteintoolkit.org/referencemanual/ReferenceManual.html*x1-1000A__;Iw!!DZ3fjg!vO69j0_NDEC1JMkgMyZSdz57Nk1EjyHTBh3FU214vo8W15081AZ6_X93p6b5_AlO$</a><br>
> >>> and search for A488.<br>
> >>><br>
> >>> So are you using this with PUGH or Carpet? With Carpet it must<br>
> >>> fail (not supported at all), with PUGH it should work as long as<br>
> >>> you sue the correct set of calls ie<br>
> >>> CCTK_LocalArrayReductionHandle + CCTK_ReduceLocalArrays (for PUGH<br>
> >>> only).<br>
> >>><br>
> >>> Yours,<br>
> >>> Roland <br>
> >>> >>>> Hi, <br>
> >>>><br>
> >>>> A code that we are using seems to no longer work with<br>
> >>>> Cactus. The issue seems to be that the code called<br>
> >>>> CCTK_LocalArrayReductionHandle. The code, as checked out,<br>
> >>>> produces errors because the appropriate handle isn't found. If I<br>
> >>>> modify the function as below, I no longer get the error message<br>
> >>>><br>
> >>>><br>
> >>>><br>
> >>>> int CCTK_LocalArrayReductionHandle(const char *reduction)<br>
> >>>> {<br>
> >>>> int handle;<br>
> >>>><br>
> >>>><br>
> >>>> handle = Util_GetHandle(LocalArrayReductionOperators,<br>
> >>>> reduction, NULL); if (handle < 0)<br>
> >>>> {<br>
> >>>> CCTK_VWarn(1,__LINE__,__FILE__,"Cactus",<br>
> >>>> "CCTK_LocalArrayReductionHandle: No handle:<br>
> >>>> '%d' found for reduction operator "<br>
> >>>> "'%s'", handle, reduction);<br>
> >>>> }<br>
> >>>><br>
> >>>> handle += ARRAY_OPERATOR_HANDLE_OFFSET; //// MY changes<br>
> >>>><br>
> >>>> return handle;<br>
> >>>> }<br>
> >>>><br>
> >>>><br>
> >>>> Should we no longer use CCTK_LocalArrayReductionHandle? <br>
> >>>> >>> > <br>
> > <br>
<br>
<br>
<br>
-- <br>
My email is as private as my paper mail. I therefore support encrypting<br>
and signing email messages. Get my PGP key from <a href="http://pgp.mit.edu" rel="noreferrer" target="_blank">http://pgp.mit.edu</a> .<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@einsteintoolkit.org" target="_blank">Users@einsteintoolkit.org</a><br>
<a href="http://lists.einsteintoolkit.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.einsteintoolkit.org/mailman/listinfo/users</a><br>
</blockquote></div>