From tradke at aei.mpg.de Tue Mar 4 03:07:25 2008 From: tradke at aei.mpg.de (Thomas Radke) Date: Tue, 04 Mar 2008 10:07:25 +0100 Subject: [Developers] Support mesh refinement and multi-patch systems in CartGrid3D In-Reply-To: <8A6268C8-451E-4775-B3A7-74E2CBE676A7@cct.lsu.edu> References: <8A6268C8-451E-4775-B3A7-74E2CBE676A7@cct.lsu.edu> Message-ID: <47CD114D.8080505@aei.mpg.de> Erik Schnetter wrote: > Thorn CactusBase/CartGrid3D initialises the coordinate arrays and > registers the coordinate ranges with the flesh. It currently assumes > that it is called on all refinement levels and on all patches of a > multi-patch evolution. This is not so with certain AMR schemes (e.g. > with Paramesh) or if a multi-patch simulation distributes different > patches to different processors. > > Since CartGrid3D does not actually know anything about mesh refinement > or multi-patch setups, I found no way to make things work cleanly in > all cases. I therefore suggest to introduce two new parameters as > work-around. These parameters select in which mode the coordinate > range registration is called: level mode, singlemap mode, or local mode: > > BOOLEAN set_ranges_on_all_levels "Set the coordinate ranges on all levels" > BOOLEAN set_ranges_on_all_maps "Set the coordinate ranges on all maps" > > The default behaviour is the current behaviour, namely initialisation > in local mode. Paramesh simulations would use > "set_ranges_on_all_levels", while multi-patch simulations would use > "set_ranges_on_all_maps". Sounds good to me. How about introducing a single keyword parameter instead of the suggested booleans ? -- Cheers, Thomas. From tradke at aei.mpg.de Mon Mar 10 03:16:38 2008 From: tradke at aei.mpg.de (Thomas Radke) Date: Mon, 10 Mar 2008 10:16:38 +0100 Subject: [Developers] Making WaveToy use InitBase In-Reply-To: References: Message-ID: <47D4FC76.7040209@aei.mpg.de> Erik Schnetter wrote: > The IDScalarWave thorns currently initialise exactly two time levels. > This is inconvenient for mesh refinement: If three time levels are > needed, then Carpet has to perform an additional initialisation step > and cannot rely on the analytic solution for initial data. > Furthermore, if this is not done, the third time level remains > uninitialised, leading to problems that are very difficult to detect, > since people typically don't output past time levels. > > I suggest to make IDScalarWave use the InitBase infrastructure to > detect this problem. In particular, if InitBase specifies that only a > single time level is to be initialised, IDScalarWave should do so, and > if all time levels should be initialised, IDScalarWave should either > also do so, or abort with an error message during parameter checking. Hi Erik, the attached patch for CactusWave/IDScalarWaveC checks how many timelevels are currently active, and initialises them. This should make it work again with Carpet. Note that InitBase is not (explicitely) used for the check; do you think it should be ? If the patch is good I'll apply it also to the other IDScalarWave thorns in CactusWave. -- Cheers, Thomas. -------------- next part -------------- A non-text attachment was scrubbed... Name: IDScalarWaveC.patch Type: text/x-patch Size: 5062 bytes Desc: not available Url : http://www.cactuscode.org/pipermail/developers/attachments/20080310/611d060a/attachment-0001.bin From schnetter at cct.lsu.edu Tue Mar 11 12:36:29 2008 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Tue, 11 Mar 2008 13:36:29 -0500 Subject: [Developers] Making WaveToy use InitBase In-Reply-To: <47D4FC76.7040209@aei.mpg.de> References: <47D4FC76.7040209@aei.mpg.de> Message-ID: <1642F464-63DC-42A7-B9A8-89E3229839DF@cct.lsu.edu> On Mar 10, 2008, at 04:16:38, Thomas Radke wrote: > Erik Schnetter wrote: >> The IDScalarWave thorns currently initialise exactly two time >> levels. This is inconvenient for mesh refinement: If three time >> levels are needed, then Carpet has to perform an additional >> initialisation step and cannot rely on the analytic solution for >> initial data. Furthermore, if this is not done, the third time >> level remains uninitialised, leading to problems that are very >> difficult to detect, since people typically don't output past time >> levels. >> I suggest to make IDScalarWave use the InitBase infrastructure to >> detect this problem. In particular, if InitBase specifies that >> only a single time level is to be initialised, IDScalarWave should >> do so, and if all time levels should be initialised, IDScalarWave >> should either also do so, or abort with an error message during >> parameter checking. > > Hi Erik, > > the attached patch for CactusWave/IDScalarWaveC checks how many > timelevels are currently active, and initialises them. This should > make it work again with Carpet. > Note that InitBase is not (explicitely) used for the check; do you > think it should be ? Hmm. With your patch, WaveToy initialises all possible time levels. I can't think of a way in which this could be unsafe. It could be too much work if something else overwrites the past time levels later on, but this doesn't really matter since WaveToy's initialisation is fast enough. However, WaveToy is also supposed to be an example, so checking InitBase may be good educationally. I think there should be a check when InitBase requests all time levels to be initialised. WaveToy will never initialise more than 3 time levels. If someone uses 5 time levels (e.g. for a fourth order accurate time interpolation scheme), then Wavetoy will leave uninitialised time levels. Instead, it should emit an error message (since we don't want to implement the code for initialising further time levels). However, it is currently not possible to activate more than 3 time levels without changing WaveToy's interface.ccl -- the danger would be that someone makes this change without updating the source code. I also notice that you only initialise the _p variables when there are 3 time levels active. These should be initialised when there are two or more time levels active. -erik -- Erik Schnetter http://www.cct.lsu.edu/~eschnett/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from www.keyserver.net. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.cactuscode.org/pipermail/developers/attachments/20080311/f928296a/attachment.bin From schnetter at cct.lsu.edu Thu Mar 13 22:21:43 2008 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Thu, 13 Mar 2008 23:21:43 -0500 Subject: [Developers] PATCH: add new schedule bin CCTK_EVOL_CONTROL In-Reply-To: <470E3809.7090409@aei.mpg.de> References: <470E3809.7090409@aei.mpg.de> Message-ID: On Oct 11, 2007, at 09:49:45, Thomas Radke wrote: > Hi, > > following up the thread "when to schedule steering methods" on the > developers mailing list > (http://www.cactuscode.org/old/pipermail/developers/2007-October/005439.html > ), > here is the according patch (for the flesh and PUGH) to add a new > schedule bin at the very end of an evolution step. As the > documentation > says, it should be used for routines which potentially alter the > status > of the simulation, eg. by interaction with users to steer runtime > parameters. > > Note that I changed the name of the new bin from STEER to EVOL_CONTROL > which I thought would be more appropriate. But I'm open for better > suggestions. I think your patch adds the bin directly after poststep, which is before analysis, and thus not at the "very end". -erik -- Erik Schnetter http://www.cct.lsu.edu/~eschnett/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from www.keyserver.net. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.cactuscode.org/pipermail/developers/attachments/20080313/9cea7b13/attachment.bin From tradke at aei.mpg.de Mon Mar 17 10:35:15 2008 From: tradke at aei.mpg.de (Thomas Radke) Date: Mon, 17 Mar 2008 17:35:15 +0100 Subject: [Developers] PATCH: add new schedule bin CCTK_EVOL_CONTROL Message-ID: <47DE9DC3.3080303@aei.mpg.de> > On Oct 11, 2007, at 09:49:45, Thomas Radke wrote: > >> Hi, >> >> following up the thread "when to schedule steering methods" on the >> developers mailing list >> (http://www.cactuscode.org/old/pipermail/developers/2007-October/005439.html ), >> here is the according patch (for the flesh and PUGH) to add a new >> schedule bin at the very end of an evolution step. As the documentation >> says, it should be used for routines which potentially alter the status >> of the simulation, eg. by interaction with users to steer runtime >> parameters. >> >> Note that I changed the name of the new bin from STEER to EVOL_CONTROL >> which I thought would be more appropriate. But I'm open for better >> suggestions. > > > > I think your patch adds the bin directly after poststep, which is before analysis, and thus not at the "very end". Sorry about that ! The corrected patch is appended (to the patches mailing list). -- Cheers, Thomas. --- StripMime Report -- processed MIME parts --- multipart/mixed text/plain (text body -- kept) text/x-patch --- From tradke at aei.mpg.de Mon Mar 17 10:52:38 2008 From: tradke at aei.mpg.de (Thomas Radke) Date: Mon, 17 Mar 2008 17:52:38 +0100 Subject: [Developers] [Flesh-cvs] DEVELOPMENT CVS "Cactus/doc/ReferenceManual CCTKReference.tex" In-Reply-To: <20080317164754.3E4D681A6@asylum.cct.lsu.edu> References: <20080317164754.3E4D681A6@asylum.cct.lsu.edu> Message-ID: <47DEA1D6.8040205@aei.mpg.de> Thomas Radke (tradke) wrote: > Update of /cactusdevcvs/Cactus/doc/ReferenceManual > In directory asylum.cct.lsu.edu:/tmp/cvs-serv4771 > > Modified Files: > CCTKReference.tex > Log Message: > /tmp/cvsNXUw0h Sorry, wrong option to 'cvs ci'. The commit message should read: - added description for Fortran binding of CCTK_ParameterSet() - fixed its parameter description -- Cheers, Thomas. From schnetter at cct.lsu.edu Wed Mar 19 19:48:09 2008 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Wed, 19 Mar 2008 20:48:09 -0500 Subject: [Developers] Problems with 4D grid arrays Message-ID: Cactus has currently a problem if one uses grid arrays of dimension D while grid functions have a dimension less than D. During initialisation, Cactus sets cctk_dim to the largest dimension of all grid variables in all active thorns. This is arguably wrong; cctk_dim should be set to the (maximum) dimension of the grid functions. The enclosed patch adds a new function to the flesh CCTK_MaxGFDim which returns the (maximum) dimension of all grid functions. This function is used to set cctk_dim. -erik -- Erik Schnetter http://www.cct.lsu.edu/~eschnett/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from www.keyserver.net. --- StripMime Report -- processed MIME parts --- multipart/mixed text/plain (text body -- kept) application/octet-stream text/plain (text body -- kept) --- From tradke at aei.mpg.de Tue Mar 25 06:39:52 2008 From: tradke at aei.mpg.de (Thomas Radke) Date: Tue, 25 Mar 2008 13:39:52 +0100 Subject: [Developers] LocalReduce calculating wrong L{2, 3, 4} norms for complex variables ? Message-ID: <47E8F298.9000301@aei.mpg.de> Hi, comparing them with the code in CactusPUGH/PUGHReduce and Carpet/CarpetReduce, I believe the reduction operators implemented in CactusBase/LocalReduce calculate wrong values for the L2/L3/L4 norms for complex variables: they only take the real part into account. Has someone successfully used these operators before ? -- Cheers, Thomas. From tradke at aei.mpg.de Tue Mar 25 06:43:46 2008 From: tradke at aei.mpg.de (Thomas Radke) Date: Tue, 25 Mar 2008 13:43:46 +0100 Subject: [Developers] Problems with 4D grid arrays In-Reply-To: References: Message-ID: <47E8F382.7080203@aei.mpg.de> Erik Schnetter wrote: > Cactus has currently a problem if one uses grid arrays of dimension D > while grid functions have a dimension less than D. During > initialisation, Cactus sets cctk_dim to the largest dimension of all > grid variables in all active thorns. This is arguably wrong; cctk_dim > should be set to the (maximum) dimension of the grid functions. > > The enclosed patch adds a new function to the flesh CCTK_MaxGFDim > which returns the (maximum) dimension of all grid functions. This > function is used to set cctk_dim. The patch looks good to me. -- Cheers, Thomas. From tradke at aei.mpg.de Tue Mar 25 07:01:13 2008 From: tradke at aei.mpg.de (Thomas Radke) Date: Tue, 25 Mar 2008 14:01:13 +0100 Subject: [Developers] [Patches] PATCH: add new schedule bin CCTK_EVOL_CONTROL In-Reply-To: <1D2852B3-A99B-4E00-B51B-4F97FD623967@cct.lsu.edu> References: <47DE9DC3.3080303@aei.mpg.de> <1D2852B3-A99B-4E00-B51B-4F97FD623967@cct.lsu.edu> Message-ID: <47E8F799.5080602@aei.mpg.de> Another fix of my latest patch which now actually compiles ;-) -- Cheers, Thomas. --- StripMime Report -- processed MIME parts --- multipart/mixed text/plain (text body -- kept) text/x-patch --- From schnetter at cct.lsu.edu Tue Mar 25 07:34:05 2008 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Tue, 25 Mar 2008 08:34:05 -0500 Subject: [Developers] LocalReduce calculating wrong L{2, 3, 4} norms for complex variables ? In-Reply-To: <47E8F298.9000301@aei.mpg.de> References: <47E8F298.9000301@aei.mpg.de> Message-ID: <4C544A4E-83EC-44E2-893D-E08D3495D326@cct.lsu.edu> On Mar 25, 2008, at 07:39:52, Thomas Radke wrote: > Hi, > > comparing them with the code in CactusPUGH/PUGHReduce and > Carpet/CarpetReduce, I believe the reduction operators implemented in > CactusBase/LocalReduce calculate wrong values for the L2/L3/L4 norms > for > complex variables: they only take the real part into account. > > Has someone successfully used these operators before ? Yes, these operators contain some errors. They are also hand-written, containing much duplicated code for the different data types. Some time ago we prepared a version which uses the C preprocessor to emulate templates, simplifying the code considerably. Unfortunately this project didn't proceed, I believe because there are some missing parts in the new reduction interface for mesh refinement. -erik -- Erik Schnetter http://www.cct.lsu.edu/~eschnett/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from www.keyserver.net. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.cactuscode.org/pipermail/developers/attachments/20080325/50d82938/attachment.bin From schnetter at cct.lsu.edu Tue Mar 25 07:38:25 2008 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Tue, 25 Mar 2008 08:38:25 -0500 Subject: [Developers] [Patches] PATCH: add new schedule bin CCTK_EVOL_CONTROL In-Reply-To: <47E8F799.5080602@aei.mpg.de> References: <47DE9DC3.3080303@aei.mpg.de> <1D2852B3-A99B-4E00-B51B-4F97FD623967@cct.lsu.edu> <47E8F799.5080602@aei.mpg.de> Message-ID: On Mar 25, 2008, at 08:01:13, Thomas Radke wrote: > Another fix of my latest patch which now actually compiles ;-) I second the patch. -erik -- Erik Schnetter http://www.cct.lsu.edu/~eschnett/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from www.keyserver.net. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.cactuscode.org/pipermail/developers/attachments/20080325/da8a5c2c/attachment.bin From yye00 at cct.lsu.edu Tue Mar 25 07:39:43 2008 From: yye00 at cct.lsu.edu (Yaakoub El Khamra) Date: Tue, 25 Mar 2008 08:39:43 -0500 Subject: [Developers] LocalReduce calculating wrong L{2, 3, 4} norms for complex variables ? In-Reply-To: <4C544A4E-83EC-44E2-893D-E08D3495D326@cct.lsu.edu> References: <47E8F298.9000301@aei.mpg.de> <4C544A4E-83EC-44E2-893D-E08D3495D326@cct.lsu.edu> Message-ID: <1206452383.3673.7.camel@localhost.localdomain> Actually the new reduction operators for PUGHReduce have been completed a while ago, they just have not been moved over from AlphaThorns. On Tue, 2008-03-25 at 08:34 -0500, Erik Schnetter wrote: > On Mar 25, 2008, at 07:39:52, Thomas Radke wrote: > > Hi, > > > > comparing them with the code in CactusPUGH/PUGHReduce and > > Carpet/CarpetReduce, I believe the reduction operators implemented in > > CactusBase/LocalReduce calculate wrong values for the L2/L3/L4 norms > > for > > complex variables: they only take the real part into account. > > > > Has someone successfully used these operators before ? > > > Yes, these operators contain some errors. They are also hand-written, > containing much duplicated code for the different data types. Some > time ago we prepared a version which uses the C preprocessor to > emulate templates, simplifying the code considerably. Unfortunately > this project didn't proceed, I believe because there are some missing > parts in the new reduction interface for mesh refinement. > > -erik > > _______________________________________________ > Developers mailing list > Developers at cactuscode.org > http://www.cactuscode.org/mailman/listinfo/developers From yye00 at cct.lsu.edu Tue Mar 25 07:41:33 2008 From: yye00 at cct.lsu.edu (Yaakoub El Khamra) Date: Tue, 25 Mar 2008 08:41:33 -0500 Subject: [Developers] Problems with 4D grid arrays In-Reply-To: <47E8F382.7080203@aei.mpg.de> References: <47E8F382.7080203@aei.mpg.de> Message-ID: <1206452493.3673.10.camel@localhost.localdomain> I second this patch. It would make life easier for people using the Funwave thorns (coastal modeling code). On Tue, 2008-03-25 at 13:43 +0100, Thomas Radke wrote: > Erik Schnetter wrote: > > Cactus has currently a problem if one uses grid arrays of dimension D > > while grid functions have a dimension less than D. During > > initialisation, Cactus sets cctk_dim to the largest dimension of all > > grid variables in all active thorns. This is arguably wrong; cctk_dim > > should be set to the (maximum) dimension of the grid functions. > > > > The enclosed patch adds a new function to the flesh CCTK_MaxGFDim > > which returns the (maximum) dimension of all grid functions. This > > function is used to set cctk_dim. > > The patch looks good to me. > From tradke at aei.mpg.de Wed Mar 26 05:45:52 2008 From: tradke at aei.mpg.de (Thomas Radke) Date: Wed, 26 Mar 2008 12:45:52 +0100 Subject: [Developers] LocalReduce calculating wrong L{2, 3, 4} norms for complex variables ? In-Reply-To: <1206452383.3673.7.camel@localhost.localdomain> References: <47E8F298.9000301@aei.mpg.de> <4C544A4E-83EC-44E2-893D-E08D3495D326@cct.lsu.edu> <1206452383.3673.7.camel@localhost.localdomain> Message-ID: <47EA3770.50609@aei.mpg.de> Yaakoub El Khamra wrote: > Actually the new reduction operators for PUGHReduce have been completed > a while ago, they just have not been moved over from AlphaThorns. Should they be moved then ? What mesh refinement parts are still missing in there ? I just used AlphaThorns/LocalReduce as a substitute for CactusBase/LocalReduce to run the testsuites of CactusTest/TestComplex, and that produced the correct results. Anyway, I also fixed CactusBase/LocalReduce to compute correct L2/L3/L4 norms for complex grid variables - but only for the (most common) case of reducing a CCTK_COMPLEX datatype to a CCTK_REAL datatype. It's just way too much code to fix all the other cases without accidentally introducing new bugs. -- Cheers, Thomas. From schnetter at cct.lsu.edu Wed Mar 26 11:04:20 2008 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Wed, 26 Mar 2008 12:04:20 -0500 Subject: [Developers] LocalReduce calculating wrong L{2, 3, 4} norms for complex variables ? In-Reply-To: <47EA3770.50609@aei.mpg.de> References: <47E8F298.9000301@aei.mpg.de> <4C544A4E-83EC-44E2-893D-E08D3495D326@cct.lsu.edu> <1206452383.3673.7.camel@localhost.localdomain> <47EA3770.50609@aei.mpg.de> Message-ID: <793DB6F9-DC91-4B4D-B36B-F212346EADB3@cct.lsu.edu> On Mar 26, 2008, at 06:45:52, Thomas Radke wrote: > Yaakoub El Khamra wrote: >> Actually the new reduction operators for PUGHReduce have been >> completed >> a while ago, they just have not been moved over from AlphaThorns. > > Should they be moved then ? What mesh refinement parts are still > missing > in there ? If it works, then yes, let's move it. The local reduction operators need to talk to the global reduction operators, which are part of the driver. This interface isn't complete for AMR, which needs masks and may have several components per processor etc. -erik -- Erik Schnetter http://www.cct.lsu.edu/~eschnett/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from www.keyserver.net. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.cactuscode.org/pipermail/developers/attachments/20080326/e7b7adf1/attachment.bin From tradke at aei.mpg.de Wed Mar 26 11:47:03 2008 From: tradke at aei.mpg.de (Thomas Radke) Date: Wed, 26 Mar 2008 18:47:03 +0100 Subject: [Developers] LocalReduce calculating wrong L{2, 3, 4} norms for complex variables ? In-Reply-To: <793DB6F9-DC91-4B4D-B36B-F212346EADB3@cct.lsu.edu> References: <47E8F298.9000301@aei.mpg.de> <4C544A4E-83EC-44E2-893D-E08D3495D326@cct.lsu.edu> <1206452383.3673.7.camel@localhost.localdomain> <47EA3770.50609@aei.mpg.de> <793DB6F9-DC91-4B4D-B36B-F212346EADB3@cct.lsu.edu> Message-ID: <47EA8C17.8010503@aei.mpg.de> Erik Schnetter wrote: > On Mar 26, 2008, at 06:45:52, Thomas Radke wrote: > >> Yaakoub El Khamra wrote: >> >>> Actually the new reduction operators for PUGHReduce have been completed >>> a while ago, they just have not been moved over from AlphaThorns. >> >> >> Should they be moved then ? What mesh refinement parts are still missing >> in there ? > > > If it works, then yes, let's move it. > > The local reduction operators need to talk to the global reduction > operators, which are part of the driver. This interface isn't complete > for AMR, which needs masks and may have several components per > processor etc. Sorry, my tests were still with CactusBase/LocalReduce. AlphaThorns/LocalReduce does not work. While the operators seem to be all there, they aren't registered yet because their interface doesn't (quite) match the flesh reduction API. -- Cheers, Thomas. From yye00 at cct.lsu.edu Wed Mar 26 12:48:29 2008 From: yye00 at cct.lsu.edu (Yaakoub El-Khamra) Date: Wed, 26 Mar 2008 13:48:29 -0500 Subject: [Developers] LocalReduce calculating wrong L{2, 3, 4} norms for complex variables ? In-Reply-To: <47EA8C17.8010503@aei.mpg.de> References: <47E8F298.9000301@aei.mpg.de> <4C544A4E-83EC-44E2-893D-E08D3495D326@cct.lsu.edu> <1206452383.3673.7.camel@localhost.localdomain> <47EA3770.50609@aei.mpg.de> <793DB6F9-DC91-4B4D-B36B-F212346EADB3@cct.lsu.edu> <47EA8C17.8010503@aei.mpg.de> Message-ID: <1206557309.12861.1.camel@fmws01.cct.lsu.edu> Yes, I sent the patches around to PUGHReduce to make everything play nice. This was about a year ago. On Wed, 2008-03-26 at 18:47 +0100, Thomas Radke wrote: > Erik Schnetter wrote: > > On Mar 26, 2008, at 06:45:52, Thomas Radke wrote: > > > >> Yaakoub El Khamra wrote: > >> > >>> Actually the new reduction operators for PUGHReduce have been completed > >>> a while ago, they just have not been moved over from AlphaThorns. > >> > >> > >> Should they be moved then ? What mesh refinement parts are still missing > >> in there ? > > > > > > If it works, then yes, let's move it. > > > > The local reduction operators need to talk to the global reduction > > operators, which are part of the driver. This interface isn't complete > > for AMR, which needs masks and may have several components per > > processor etc. > > Sorry, my tests were still with CactusBase/LocalReduce. > AlphaThorns/LocalReduce does not work. While the operators seem to be > all there, they aren't registered yet because their interface doesn't > (quite) match the flesh reduction API. >