On 7 Sep 2015, at 16:40, Comer Duncan comer.duncan@gmail.com wrote:
Hi Ian,
Thanks for noticing that I don't have the naming correct. I believe I fixed it. I am attaching the revised script. However, I still get a crash. Here is the last part of the make with a complaint about sqrtdetg which I don't understand, as it seems that sqrtdetg is properly mentioned and computed in the script. Can you or someone in the list please let me know what's the matter now?
Hi Comer,
(added CC to mailing list which was lost)
The problem is that you are taking a derivative of a shorthand; this isn't possible because shorthands are only defined pointwise. To take a derivative (finite difference), the variable needs to be a grid function. sqrtdetg is declared as a shorthand in CT_BrillAnalyticCoefficients.
You could expand the definition of sqrtdetg in terms of the metric, then differentiate it symbolically wrt the metric, and then the required numerical derivatives could be taken of the metric, which is a grid function. Alternatively, and much more simply, you could add a grid function which you initialise using sqrtdetg in a previous calculation, and then finite-difference it as you are currently doing. These will have different numerical truncation errors, but this probably doesn't matter in your case.
Kranc should have detected the attempt to use PD on a shorthand. I have created an issue for this: https://github.com/ianhinder/Kranc/issues/134.
Checking status of thorn CT_BrillAnalytic COMPILING arrangements/Cosmology/CT_Analytic/src/Boundaries.cc COMPILING arrangements/Cosmology/CT_Analytic/src/CT_Analytic_BY_Calc.cc COMPILING arrangements/Cosmology/CT_BrillAnalytic/src/Boundaries.cc COMPILING arrangements/Cosmology/CT_BrillAnalytic/src/CT_BrillAnalyticCoefficients.cc COMPILING arrangements/Cosmology/CT_Analytic/src/CT_Analytic_ExactBoundary.cc In file included from /Users/comerduncan/Cactus/arrangements/Cosmology/CT_BrillAnalytic/src/CT_BrillAnalyticCoefficients.cc:14:0: /Users/comerduncan/Cactus/arrangements/Cosmology/CT_BrillAnalytic/src/CT_BrillAnalyticCoefficients.cc: In function 'void CT_BrillAnalytic::CT_BrillAnalyticCoefficients_Body(const cGH*, int, int, const CCTK_REAL8*, const CCTK_REAL8*, const CCTK_REAL8*, const int*, const int*, int, CCTK_REAL8* const __restrict__*)': /Users/comerduncan/Cactus/arrangements/Cosmology/CT_BrillAnalytic/src/CT_BrillAnalyticCoefficients.cc:220:84: error: 'sqrtdetg' was not declared in this scope const CCTK_REAL PDstandardNth1sqrtdetg CCTK_ATTRIBUTE_UNUSED = PDstandardNth1(&sqrtdetg[index]); ^ /Users/comerduncan/Cactus/arrangements/Cosmology/CT_BrillAnalytic/src/Kranc.hh:120:39: note: in definition of macro 'KRANC_GFOFFSET3D' (*(CCTK_REAL const*)&((char const*)(var))[cdi*(i)+cdj*(j)+cdk*(k)]) ^ /Users/comerduncan/Cactus/arrangements/Cosmology/CT_BrillAnalytic/src/CT_BrillAnalyticCoefficients.cc:220:68: note: in expansion of macro 'PDstandardNth1' const CCTK_REAL PDstandardNth1sqrtdetg CCTK_ATTRIBUTE_UNUSED = PDstandardNth1(&sqrtdetg[index]); ^ make[3]: *** [CT_BrillAnalyticCoefficients.cc.o] Error 1 make[2]: *** [make.checked] Error 2 make[1]: *** [/Users/comerduncan/Cactus/configs/sim/lib/libthorn_CT_BrillAnalytic.a] Error 2 make[1]: *** Waiting for unfinished jobs.... COMPILING arrangements/Cosmology/CT_Analytic/src/CT_Analytic_Exact_Calc.cc COMPILING arrangements/Cosmology/CT_Analytic/src/CT_Analytic_ExpandingLattice_Calc.cc COMPILING arrangements/Cosmology/CT_Analytic/src/CT_Analytic_LumpBoundary.cc COMPILING arrangements/Cosmology/CT_Analytic/src/CT_Analytic_Lump_Calc.cc COMPILING arrangements/Cosmology/CT_Analytic/src/CT_Analytic_Poisson_Calc.cc COMPILING arrangements/Cosmology/CT_Analytic/src/Kranc.cc COMPILING arrangements/Cosmology/CT_Analytic/src/RegisterMoL.cc COMPILING arrangements/Cosmology/CT_Analytic/src/RegisterSymmetries.cc COMPILING arrangements/Cosmology/CT_Analytic/src/Startup.cc Creating /Users/comerduncan/Cactus/configs/sim/lib/libthorn_CT_Analytic.a make: *** [sim] Error 2
Here is the last
Thanks for your help.
Comer
On Mon, Sep 7, 2015 at 6:21 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
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).
-- Ian Hinder http://members.aei.mpg.de/ianhin
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
<CT_BrillAnalytic.m>
Hi,
I was able to get ET to build with the Brill example. However, after constructing a par file (attached) I have found that the execution crashes. The main complaint seems to be that there are not enough prolongation levels associated with the grid functions. One is assigned and Carpet seems to say it needs at least 2. I am attaching the .err file (short) so you'll get a hint of what I see. I can perhaps post the .out file to pastebin if that would help. Indeed all time levels for the grid functions is set to 1. What could be responsible? Am I missing something in the par file or is there something in the generated code which needs tweaking? Also, the CT method I use needs the Robin outer bc, which is set in the par file. More needed?
Thanks.
Comer
On Mon, Sep 7, 2015 at 11:16 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 7 Sep 2015, at 16:40, Comer Duncan comer.duncan@gmail.com wrote:
Hi Ian,
Thanks for noticing that I don't have the naming correct. I believe I fixed it. I am attaching the revised script. However, I still get a crash. Here is the last part of the make with a complaint about sqrtdetg which I don't understand, as it seems that sqrtdetg is properly mentioned and computed in the script. Can you or someone in the list please let me know what's the matter now?
Hi Comer,
(added CC to mailing list which was lost)
The problem is that you are taking a derivative of a shorthand; this isn't possible because shorthands are only defined pointwise. To take a derivative (finite difference), the variable needs to be a grid function. sqrtdetg is declared as a shorthand in CT_BrillAnalyticCoefficients.
You could expand the definition of sqrtdetg in terms of the metric, then differentiate it symbolically wrt the metric, and then the required numerical derivatives could be taken of the metric, which is a grid function. Alternatively, and much more simply, you could add a grid function which you initialise using sqrtdetg in a previous calculation, and then finite-difference it as you are currently doing. These will have different numerical truncation errors, but this probably doesn't matter in your case.
Kranc should have detected the attempt to use PD on a shorthand. I have created an issue for this: https://github.com/ianhinder/Kranc/issues/134.
Checking status of thorn CT_BrillAnalytic COMPILING arrangements/Cosmology/CT_Analytic/src/Boundaries.cc COMPILING arrangements/Cosmology/CT_Analytic/src/CT_Analytic_BY_Calc.cc COMPILING arrangements/Cosmology/CT_BrillAnalytic/src/Boundaries.cc COMPILING arrangements/Cosmology/CT_BrillAnalytic/src/CT_BrillAnalyticCoefficients.cc COMPILING arrangements/Cosmology/CT_Analytic/src/CT_Analytic_ExactBoundary.cc In file included from /Users/comerduncan/Cactus/arrangements/Cosmology/CT_BrillAnalytic/src/CT_BrillAnalyticCoefficients.cc:14:0: /Users/comerduncan/Cactus/arrangements/Cosmology/CT_BrillAnalytic/src/CT_BrillAnalyticCoefficients.cc: In function 'void CT_BrillAnalytic::CT_BrillAnalyticCoefficients_Body(const cGH*, int, int, const CCTK_REAL8*, const CCTK_REAL8*, const CCTK_REAL8*, const int*, const int*, int, CCTK_REAL8* const __restrict__*)': /Users/comerduncan/Cactus/arrangements/Cosmology/CT_BrillAnalytic/src/CT_BrillAnalyticCoefficients.cc:220:84: error: 'sqrtdetg' was not declared in this scope const CCTK_REAL PDstandardNth1sqrtdetg CCTK_ATTRIBUTE_UNUSED = PDstandardNth1(&sqrtdetg[index]);
^/Users/comerduncan/Cactus/arrangements/Cosmology/CT_BrillAnalytic/src/Kranc.hh:120:39: note: in definition of macro 'KRANC_GFOFFSET3D' (*(CCTK_REAL const*)&((char const*)(var))[cdi*(i)+cdj*(j)+cdk*(k)]) ^ /Users/comerduncan/Cactus/arrangements/Cosmology/CT_BrillAnalytic/src/CT_BrillAnalyticCoefficients.cc:220:68: note: in expansion of macro 'PDstandardNth1' const CCTK_REAL PDstandardNth1sqrtdetg CCTK_ATTRIBUTE_UNUSED = PDstandardNth1(&sqrtdetg[index]); ^ make[3]: *** [CT_BrillAnalyticCoefficients.cc.o] Error 1 make[2]: *** [make.checked] Error 2 make[1]: *** [/Users/comerduncan/Cactus/configs/sim/lib/libthorn_CT_BrillAnalytic.a] Error 2 make[1]: *** Waiting for unfinished jobs.... COMPILING arrangements/Cosmology/CT_Analytic/src/CT_Analytic_Exact_Calc.cc COMPILING arrangements/Cosmology/CT_Analytic/src/CT_Analytic_ExpandingLattice_Calc.cc COMPILING arrangements/Cosmology/CT_Analytic/src/CT_Analytic_LumpBoundary.cc COMPILING arrangements/Cosmology/CT_Analytic/src/CT_Analytic_Lump_Calc.cc COMPILING arrangements/Cosmology/CT_Analytic/src/CT_Analytic_Poisson_Calc.cc COMPILING arrangements/Cosmology/CT_Analytic/src/Kranc.cc COMPILING arrangements/Cosmology/CT_Analytic/src/RegisterMoL.cc COMPILING arrangements/Cosmology/CT_Analytic/src/RegisterSymmetries.cc COMPILING arrangements/Cosmology/CT_Analytic/src/Startup.cc Creating /Users/comerduncan/Cactus/configs/sim/lib/libthorn_CT_Analytic.a make: *** [sim] Error 2
Here is the last
Thanks for your help.
Comer
On Mon, Sep 7, 2015 at 6:21 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
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).
-- Ian Hinder http://members.aei.mpg.de/ianhin
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
<CT_BrillAnalytic.m>
-- Ian Hinder http://members.aei.mpg.de/ianhin
On 09/09/15 22:36, Comer Duncan wrote:
Hi,
I was able to get ET to build with the Brill example. However, after constructing a par file (attached) I have found that the execution crashes. The main complaint seems to be that there are not enough prolongation levels associated with the grid functions. One is assigned and Carpet seems to say it needs at least 2. I am attaching the .err file (short) so you'll get a hint of what I see. I can perhaps post the .out file to pastebin if that would help. Indeed all time levels for the grid functions is set to 1. What could be responsible? Am I missing something in the par file or is there something in the generated code which needs tweaking? Also, the CT method I use needs the Robin outer bc, which is set in the par file. More needed?
Hi Comer!
I think you forgot to attach the .err file... which grid functions are affected by the prolongation error?
Also, do you need the Robin BCs for the initial data only, or during the evolution too?
Eloisa
Hi Eloisa,
On the question of the Robin boundary condition on \psi, I definitely know I need it for the initial data. For subsequent evolution using McLachlan, I am not so sure. Is that outer bc used by ET users?
Also, note that I am trying to get Robin used since the mass is not knowable until the converged \psi is determined by solving the Ham constraint. So, please let me know what is existing practice with McLachlan.
Comer
On Thu, Sep 10, 2015 at 7:12 AM, Eloisa Bentivegna < eloisa.bentivegna@ct.infn.it> wrote:
On 09/09/15 22:36, Comer Duncan wrote:
Hi,
I was able to get ET to build with the Brill example. However, after constructing a par file (attached) I have found that the execution crashes. The main complaint seems to be that there are not enough prolongation levels associated with the grid functions. One is assigned and Carpet seems to say it needs at least 2. I am attaching the .err file (short) so you'll get a hint of what I see. I can perhaps post the .out file to pastebin if that would help. Indeed all time levels for the grid functions is set to 1. What could be responsible? Am I missing something in the par file or is there something in the generated code which needs tweaking? Also, the CT method I use needs the Robin outer bc, which is set in the par file. More needed?
Hi Comer!
I think you forgot to attach the .err file... which grid functions are affected by the prolongation error?
Also, do you need the Robin BCs for the initial data only, or during the evolution too?
Eloisa
On 9 Sep 2015, at 22:36, Comer Duncan comer.duncan@gmail.com wrote:
Hi,
I was able to get ET to build with the Brill example. However, after constructing a par file (attached) I have found that the execution crashes. The main complaint seems to be that there are not enough prolongation levels associated with the grid functions. One is assigned and Carpet seems to say it needs at least 2. I am attaching the .err file (short) so you'll get a hint of what I see. I can perhaps post the .out file to pastebin if that would help. Indeed all time levels for the grid functions is set to 1. What could be responsible? Am I missing something in the par file or is there something in the generated code which needs tweaking? Also, the CT method I use needs the Robin outer bc, which is set in the par file. More needed?
Hi Comer,
I think you forgot to attach the err file; I could only see the par file. Yes, if you put everything you have on pastebin, it will help to diagnose the problem.
Sorry! I have attached the .err file and the larger .out file is http://pastebin.com/JLPRb2sw and I hope this helps.
Thanks.
Comer
On Thu, Sep 10, 2015 at 7:50 AM, Ian Hinder ian.hinder@aei.mpg.de wrote:
On 9 Sep 2015, at 22:36, Comer Duncan comer.duncan@gmail.com wrote:
Hi,
I was able to get ET to build with the Brill example. However, after constructing a par file (attached) I have found that the execution crashes. The main complaint seems to be that there are not enough prolongation levels associated with the grid functions. One is assigned and Carpet seems to say it needs at least 2. I am attaching the .err file (short) so you'll get a hint of what I see. I can perhaps post the .out file to pastebin if that would help. Indeed all time levels for the grid functions is set to 1. What could be responsible? Am I missing something in the par file or is there something in the generated code which needs tweaking? Also, the CT method I use needs the Robin outer bc, which is set in the par file. More needed?
Hi Comer,
I think you forgot to attach the err file; I could only see the par file. Yes, if you put everything you have on pastebin, it will help to diagnose the problem.
-- Ian Hinder http://members.aei.mpg.de/ianhin
On 10 Sep 2015, at 15:10, Comer Duncan comer.duncan@gmail.com wrote:
Sorry! I have attached the .err file and the larger .out file is http://pastebin.com/JLPRb2sw and I hope this helps.
Hi Comer,
In the parameter file, you have set
Carpet::prolongation_order_time = 2
and Carpet is simply checking the number of timelevels for all variables that have prolongation enabled, and aborting because there are some such variables with only one timelevel (3 are required).
In your case, since you are only using prolongation for multigrid, I don't think that time interpolation is required, and additional timelevels should not be necessary. I think it would be better if Carpet only checked this if time interpolation actually happened, i.e. during the run.
There are many aspects of timelevel handling in Cactus/Carpet which are not ideal; there was some recent work on this, but it's not quite there yet.
The first thing to try is setting
Carpet::prolongation_order_time = 0
This seems like the cleanest solution, in the absence of Carpet relaxing its too-strict checks, at least for a parameter file which just constructs initial data.
If this doesn't work (something else might go wrong), take a look in the param.ccl file of CT_BrillAnalytic. You should find a "timelevels" parameter which you can try setting to 3.
users@lists.einsteintoolkit.org
-
Comer Duncan -
Eloisa Bentivegna -
Ian Hinder