Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

Re: [Users] bug or feature?
by Ian Hinder 11 Sep '15

11 Sep '15

On 7 Sep 2015, at 16:40, Comer Duncan <comer.duncan(a)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(a)aei.mpg.de> wrote: > > On 4 Sep 2015, at 16:11, Comer Duncan <comer.duncan(a)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(a)einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/users > > > <CT_BrillAnalytic.m> -- Ian Hinder http://members.aei.mpg.de/ianhin

3 6

bug or feature?
by Comer Duncan 07 Sep '15

07 Sep '15

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

2 4

Einstein Toolkit Meeting
by Frank Loeffler 06 Sep '15

06 Sep '15

Hi, There will not be an Einstein Toolkit meeting coming Monday. The next meeting will be in about one week on Monday, September 14th, at the usual time. Frank Loeffler

1 0

Re: [Users] WaveToy a in functional, multi-threaded style
by Jonah Miller 01 Sep '15

01 Sep '15

Hello everyone, As a reminder, for those interested, I will describe my investigation of using futures and a functional style of programming in charm++ in the following google hangout now. https://plus.google.com/hangouts/_/calendar/am9uYWgubWF4d2VsbC5taWxsZXJAZ21… Best, Jonah Miller

1 3

SPH in EinsteinToolkit
by Stefan Ruehe 01 Sep '15

01 Sep '15

Hello everybody, I have not take a look on the problems Matt Kinsey mentioned yet, but I can do so. It seems to me, these are the importent things, which have to been solved first. My work until now was mainly about an approximation for the Tmunu data from the SPH and for my work needed SPH-equations. Regards, Stefan

1 0

New WVUThorns Arrangement; Code Review Request
by Zach Etienne 01 Sep '15

01 Sep '15

Hello everyone. I have just completed addressing all of Roland's points in his second round of IllinoisGRMHD code review, verifying that the new IllinoisGRMHD code generates results that agree to roundoff error with the pre-reviewed code. As per our recent mailing list and telecon discussion, IllinoisGRMHD and the two associated ET compatibility layer thorns are currently housed in the new, publicly-available WVUThorns arrangement: https://bitbucket.org/zach_etienne/wvuthorns If you currently have write access to the ET, please send me your BitBucket login info so I can grant you write access to WVUThorns as well. (Thanks!) While Roland and I work out any remaining issues with the IllinoisGRMHD thorn, I would appreciate if some of you would be willing to review the ET compatibility layer thorns in the new WVUThorns arrangement. The ET compatibility layer thorns are as follows: 1) ID_converter_ILGRMHD Size: 199 lines of C code Description: Converts HydroBase variables into IllinoisGRMHD variables, used only during initial data stage. Also checks that variables are in physical bounds. 2) convert_to_HydroBase Size: 41 lines of C code Description: Converts IllinoisGRMHD variables into HydroBase variables, used for compatibility with HydroBase-compatible diagnostic thorns. As you can see, there is not a lot of code to review. Thanks again for all of your help and support. -Zach * * * Zachariah Etienne Assistant Professor of Mathematics West Virginia University

1 0

SPH in EinsteinToolkit
by Stefan Ruehe 31 Aug '15

31 Aug '15

Hallo, long time ago i asked about a SPH modul in EinsteinToolkit for my PhD thesis. It took more time i thougt, but i am still working. First i have some questions about citing, because i will present a poster at a meeting and i will publish some prework. I want to mention the EinsteinToolkit, but there are no results using it yet. Should i taking something into account? Second i made necessery preparatory work and will now try to integrate the SPH algorithm. I am sure it could be helpful not working alone on it, so i could open a google group for communication, if somebody want. Thank you and best regards, Stefan Ruehe

5 6

Einstein Toolkit Meeting Reminder
by Frank Loeffler 28 Aug '15

28 Aug '15

Hi Please consider joining the weekly Einstein Toolkit phone call at 10 am US central time on Mondays. As usual, you can find instructions how to join on the following web site: http://einsteintoolkit.org/community/support/ In short: the number is (+1) 225-578-4942 and the conference id is 118682#. Frank Löffler

1 0

Interest in Null / Timelike geodesic integrator
by Yosef Zlochower 26 Aug '15

26 Aug '15

Hi, I have been working on an integrator for timelike and null geodesics that evolve the geodesics using MoL. With an RK4 integration, and a fourth-order interpolation stencil, the code should be third-order accurate (due to the lower-order accuracy obtained when interpolating derivatives). The code appears to work well with a typical moving boxes BBH simulation (I haven't actually tried null geodesics yet). It however, will not scale well to arbitrary numbers of geodesics as all processes need to know the locations of each geodesic. I'd be happy to share the code if there is some interest. -- Dr. Yosef Zlochower Center for Computational Relativity and Gravitation Associate Professor School of Mathematical Sciences Rochester Institute of Technology 85 Lomb Memorial Drive Rochester, NY 14623 Office:74-2067 Phone: +1 585-475-6103 yosef(a)astro.rit.edu CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

1 0

Re: [Users] Kranc and xAct
by Comer Duncan 25 Aug '15

25 Aug '15

Ian, Thanks for your note. I am still having trouble with the .m file and so am not needing the xAct way just yet. This is becoming more and more frustrating as I try to get the .m file in a shape more along your Weyl4 example. I am not wanting to whine to the list as I think that is a big waste of people's time. I do like the kranc approach and am convinced of its demonstrated utility relative to having to construct thorns from scratch. Sorry for bothering you and Eloisa about this. I do appreciate your help and do understand that your can't perform miracles... Best regards, Comer On Tue, Aug 25, 2015 at 8:17 AM, Ian Hinder <ian.hinder(a)aei.mpg.de> wrote: > > On 22 Jul 2015, at 21:00, Comer Duncan <comer.duncan(a)gmail.com> wrote: > > Ian, > > Yes, I'd like to see the example you mention. > > > Hi Comer, > > Sorry I have not had time to do this yet. It is on my task list. Do you > need it soon? > > > Thanks. > > Comer > > On Wed, Jul 22, 2015 at 11:26 AM, Ian Hinder <ian.hinder(a)aei.mpg.de> > wrote: > >> >> On 22 Jul 2015, at 16:04, Comer Duncan <comer.duncan(a)gmail.com> wrote: >> >> Do Kranc and xAct play well together? Just curious since sometimes I do >> things in xAct and then may want to do the same in Kranc and it would be >> nice if I could just say import xAct and the work done in it to a >> developing Kranc script. Of course, there are several pieces of xAct, so >> maybe my question is not formulated precisely enough, but what do you think? >> >> >> Hi, >> >> There is experimental support in Kranc for using xAct as an input >> language. However, it is not well-tested, and might be missing important >> functionality. This was added by Barry Wardell some time ago. In the >> past, I have converted xAct expressions into the format expected by Kranc >> using some simple replacement rules. Let me know if you would like an >> example. Barry might be able to provide more details of the xAct support >> in Kranc; I'm not sure of the current status. >> >> -- >> Ian Hinder >> http://members.aei.mpg.de/ianhin >> >> > > -- > Ian Hinder > http://members.aei.mpg.de/ianhin > >

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users