On 17 Dec 2015, at 20:38, Erik Schnetter <[email protected]> wrote:
> Michael > > This is likely caused by your grid structure. Some refinement levels probably > have several components (maybe one component surrounding each black hole in a > binary system), and the code in question probably has not yet been extended > to handle this case. > > The loop is there to set up certain internal variables correctly. This > particular routine would work fine with multiple local components, but others > will not. You see e.g. that the signature of the function Device_CopyPreSync > accepts a variable index, refinement level, and time level as input. All > other indices must therefore be trivial (multigrid level, component, map > index) since the called routine has no way of determining them. It should be > relatively straightforward but tedious to extend the API to handle these as > well. I think it would be better if these details were made abstract. The code outside Carpet doesn't need to know the details of multigrid level, component, map index, refinement level, it just needs a way to refer to such tuples. It's rare for code outside Carpet to do anything to these values except pass them (tediously!) from function to function. There could be an opaque handle to such a "block" of the grid, with a lookup-table internal to Carpet, so that only Carpet needs to know these details. If some code outside Carpet does need the details, there could be a function to obtain them from the handle. -- Ian Hinder http://members.aei.mpg.de/ianhin
_______________________________________________ Users mailing list [email protected] http://cactuscode.org/mailman/listinfo/users
