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.
Thanks.
Comer
On 1 Sep 2015, at 16:01, Comer Duncan comer.duncan@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.
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@aei.mpg.de wrote:
On 1 Sep 2015, at 16:01, Comer Duncan comer.duncan@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
I have pasted the attempted build to pastebin: http://pastebin.com/YNDgRKNV
There are several complaints there which may be either due to unseen errors in my Kranc script or other unrelated things. Please let me know if you see something. Thanks very much.
Comer
On Fri, Sep 4, 2015 at 9:14 AM, Comer Duncan comer.duncan@gmail.com wrote:
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
PTRACE_ATTACH, PTRACE_CONT, PTRACE_TRACEME
'namespace CT_BrillAnalytic { }' redeclared as different kind of symbol,
/Users/comerduncan/Cactus/arrangements/Cosmology/CT_BrillAnalytic/src/CT_BrillAnalytic.cc:28:83: error: 'GetBoundaryWidth' was not declared in this scope,
/Users/comerduncan/Cactus/arrangements/Cosmology/CT_BrillAnalytic/src/CT_BrillAnalytic.cc:223:84: error: 'sqrtdetg' was not declared in this scope,
/Users/comerduncan/Cactus/arrangements/Cosmology/CT_BrillAnalytic/src/CT_BrillAnalytic.cc:735:60: error: 'AssertGroupStorage' was not declared in this scope,
/Users/comerduncan/Cactus/arrangements/Cosmology/CT_BrillAnalytic/src/CT_BrillAnalytic.cc:737:56: error: 'EnsureStencilFits' was not declared in this scope,
/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@aei.mpg.de wrote:
On 1 Sep 2015, at 16:01, Comer Duncan comer.duncan@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
On 4 Sep 2015, at 16:11, Comer Duncan comer.duncan@gmail.com wrote:
I have pasted the attempted build to pastebin: http://pastebin.com/YNDgRKNV
There are several complaints there which may be either due to unseen errors in my Kranc script or other unrelated things. Please let me know if you see something. Thanks very much.
Aha! You have a calculation with a name which is the same as the thorn name. Kranc uses the thorn name as a C++ namespace, and calculation names as C++ function names, and these are not allowed to conflict. This is the error you are seeing:
• In file included from /Users/comerduncan/Cactus/arrangements/Cosmology/CT_BrillAnalytic/src/CT_BrillAnalytic.cc:14:0: • /Users/comerduncan/Cactus/arrangements/Cosmology/CT_BrillAnalytic/src/Kranc.hh:10:28: error: 'namespace CT_BrillAnalytic { }' redeclared as different kind of symbol • namespace CT_BrillAnalytic { • ^ • In file included from /Users/comerduncan/Cactus/configs/sim/bindings/include/CT_BrillAnalytic/cctk.h:6:0, • from /Users/comerduncan/Cactus/arrangements/Cosmology/CT_BrillAnalytic/src/CT_BrillAnalytic.cc:11: • /Users/comerduncan/Cactus/configs/sim/bindings/include/CT_BrillAnalytic/cctk_ScheduleFunctions.h:35:6: note: previous declaration 'void CT_BrillAnalytic(cGH*)' • void CT_BrillAnalytic (CCTK_ARGUMENTS) CCTK_ATTRIBUTE_NONNULL(1); • ^
I had never thought of this issue before; Kranc should prevent you from doing this and give an error at Kranc time. I just created in issue for this: https://github.com/ianhinder/Kranc/issues/132. You should just be able to change the name of the calculation from thornName to thornName <> "_<something>".
In general, I would recommend prefixing all calculation names with the thorn name, to avoid possible conflicts with other thorns. Cactus doesn't have any thorn-based scoping mechanism, so all scheduled functions are in the same namespace. You have some calculations called "formgk" and "gupper". Probably they are fine, but in principle they could conflict with other thorns, so prefixing the names with the thorn name is much safer.
Ideally, I think I would like Kranc to automatically add such a prefix, but this would break backward compatibility. Maybe Kranc should print a warning if the calculation name does not start with the thorn name (https://github.com/ianhinder/Kranc/issues/133).
users@lists.einsteintoolkit.org