[Users] bug or feature?

[Comer Duncan]

Hi Ian,

Thanks for taking a look.   I have no problem with whomever seeing the
script, so I am attaching it herein. If people see things wrong with the
script, I am happy to hear about it.

I am having issues building the thorn.  I get a crash of the build with
complaints about

1. PTRACE_ATTACH, PTRACE_CONT, PTRACE_TRACEME

2. 'namespace CT_BrillAnalytic { }' redeclared as different kind of symbol,

3.
 /Users/comerduncan/Cactus/arrangements/Cosmology/CT_BrillAnalytic/src/CT_BrillAnalytic.cc:28:83:
error: 'GetBoundaryWidth' was not declared in this scope,

4.
/Users/comerduncan/Cactus/arrangements/Cosmology/CT_BrillAnalytic/src/CT_BrillAnalytic.cc:223:84:
error: 'sqrtdetg' was not declared in this scope,

5.
/Users/comerduncan/Cactus/arrangements/Cosmology/CT_BrillAnalytic/src/CT_BrillAnalytic.cc:735:60:
error: 'AssertGroupStorage' was not declared in this scope,

6.
/Users/comerduncan/Cactus/arrangements/Cosmology/CT_BrillAnalytic/src/CT_BrillAnalytic.cc:737:56:
error: 'EnsureStencilFits' was not declared in this scope,

7.
/Users/comerduncan/Cactus/arrangements/Cosmology/CT_BrillAnalytic/src/CT_BrillAnalytic.cc:739:49:
error: 'LoopOverInterior' was not declared in this scope.

I am thus wondering whether there are other errors lurking in my script or,
perhaps less probable other issues that Kranc has.  Note that I am using
Mathematica 10.

I can of course put the log file for the build of the CT_BrillAnalytic
thorn on pastebin or could email a compressed version, whichever is
useful.  Just let me know.


Comer

On Fri, Sep 4, 2015 at 5:26 AM, Ian Hinder <ian.hinder at aei.mpg.de> wrote:

>
> On 1 Sep 2015, at 16:01, Comer Duncan <comer.duncan at gmail.com> wrote:
>
> I have a thorn I am constructing from a Kranc script. it compiles ok.
> However, upon looking at its schedule.inc file there is a section in which
> apparently doubling up occurs. Here is the section:
>
> schedule formgk AT CCTK_INITIAL before CT_MultiLevel
> {
>   LANG: C
>   SYNC: CT_g
>   READS: grid::x(Everywhere)
>   READS: grid::y(Everywhere)
>   READS: grid::z(Everywhere)
>   READS: grid::x(Everywhere)
>   READS: grid::y(Everywhere)
>   READS: grid::z(Everywhere)
>   WRITES: CT_BrillAnalytic::g11(Interior)
>   WRITES: CT_BrillAnalytic::g12(Interior)
>   WRITES: CT_BrillAnalytic::g13(Interior)
>   WRITES: CT_BrillAnalytic::g22(Interior)
>   WRITES: CT_BrillAnalytic::g23(Interior)
>   WRITES: CT_BrillAnalytic::g33(Interior)
> } "formgk"
>
>
> My question is how come there is a doubling of a READS grid::x(Everywhere)
> along with the same for y and z?  I don't see any problem in the script
> which obviously induces such behavior.  So, does this indicate that there
> is a problem somewhere or should I ignore the doubling of the READS for x,
> y, and z?  This script prepares initial data so this would not occur
> repeatedly.
>
>
> Hi Comer,
>
> This looks like a bug in Kranc.  Different parts of Kranc are probably
> contributing accesses to the coordinate variables, and Kranc is not
> de-duplicating them.  Since Cactus/Carpet currently don't look at these
> entries, it should be harmless for the moment.  I have created an issue on
> Kranc's issue tracker: https://github.com/ianhinder/Kranc/issues/131.
> Would you be OK with sending me the script which has this problem, so I can
> attach it to the issue?  Note that this would make the script
> publicly-available.  If this is not OK, you can just send it to me
> privately.
>
> --
> Ian Hinder
> http://members.aei.mpg.de/ianhin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.einsteintoolkit.org/pipermail/users/attachments/20150904/4867f661/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CT_BrillAnalytic.m
Type: application/octet-stream
Size: 11431 bytes
Desc: not available
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20150904/4867f661/attachment-0001.obj