Trac September 2022

trac@lists.einsteintoolkit.org

1 participants
67 discussions

#2640: NRPyEllipticET fails to compile on Stampede2
by Leonardo Werneck 19 Sep '22

19 Sep '22

#2640: NRPyEllipticET fails to compile on Stampede2 Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: blocker Component: Comment (by Leonardo Werneck): @{557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22} the issue has been fixed by commit [46f6a27](https://github.com/assumpcaothiago/NRPyElliptic/commit/46f6a2750c3… in [https://github.com/assumpcaothiago/NRPyElliptic](https://github.com/assumpc…. Thanks for letting us know! -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2640/nrpyellipticet-fa…

1 0

#2639: CarpetLib internal error with PreSync and analysis thorns
by Steven R. Brandt 19 Sep '22

19 Sep '22

#2639: CarpetLib internal error with PreSync and analysis thorns Reporter: Samuel Cupp Status: new Milestone: Version: development version Type: bug Priority: major Component: Carpet Comment (by Steven R. Brandt): One thing I sometimes try when nothing is making sense is to run the code through valgrind. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2639/carpetlib-interna…

1 0

#2640: NRPyEllipticET fails to compile on Stampede2
by Leonardo Rosa Werneck 19 Sep '22

19 Sep '22

#2640: NRPyEllipticET fails to compile on Stampede2 Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: blocker Component: Comment (by Leonardo Rosa Werneck): Interesting. Thanks for pointing it out @{557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22} . It seems that our check is not working properly. I’ll fix it tomorrow and let you know. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2640/nrpyellipticet-fa…

1 0

#2640: NRPyEllipticET fails to compile on Stampede2
by Roland Haas 19 Sep '22

19 Sep '22

#2640: NRPyEllipticET fails to compile on Stampede2 Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: blocker Component: Comment (by Roland Haas): @{6228f1ddb7e7c700715a7695} please take a look. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2640/nrpyellipticet-fa…

1 0

#2640: NRPyEllipticET fails to compile on Stampede2
by Roland Haas 19 Sep '22

19 Sep '22

#2640: NRPyEllipticET fails to compile on Stampede2 Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: blocker Component: ``` Building thorns 'NRPyEllipticET' of configuration sim Checking status of thorn NRPyEllipticET COMPILING EinsteinInitialData/NRPyEllipticET/src/conformally_flat_BBH/NRPyEllipticET_conformally_flat_BBH_Hyperbolic_Relaxation.c /work2/00945/rhaas/stampede2/skx/ET_Next/arrangements/EinsteinInitialData/NRPyEllipticET/src/conformally_flat_BBH/NRPyEllipticET_conformally_flat_BBH_Hyperbolic_Relaxation.c(178): error: incomplete type is not allowed struct timespec start, end; ^ /work2/00945/rhaas/stampede2/skx/ET_Next/arrangements/EinsteinInitialData/NRPyEllipticET/src/conformally_flat_BBH/NRPyEllipticET_conformally_flat_BBH_Hyperbolic_Relaxation.c(178): error: incomplete type is not allowed struct timespec start, end; ^ /work2/00945/rhaas/stampede2/skx/ET_Next/arrangements/EinsteinInitialData/NRPyEllipticET/src/conformally_flat_BBH/NRPyEllipticET_conformally_flat_BBH_Hyperbolic_Relaxation.c(179): warning #266: function "clock_gettime" declared implicitly clock_gettime(CLOCK_REALTIME, &start); ^ /work2/00945/rhaas/stampede2/skx/ET_Next/arrangements/EinsteinInitialData/NRPyEllipticET/src/conformally_flat_BBH/NRPyEllipticET_conformally_flat_BBH_Hyperbolic_Relaxation.c(179): error: identifier "CLOCK_REALTIME" is undefined clock_gettime(CLOCK_REALTIME, &start); ^ compilation aborted for /work2/00945/rhaas/stampede2/skx/ET_Next/configs/sim/build/NRPyEllipticET/conformally_flat_BBH/NRPyEllipticET_conformally_flat_BBH_Hyperbolic_Relaxation.c (code 2) make[3]: *** [NRPyEllipticET_conformally_flat_BBH_Hyperbolic_Relaxation.c.o] Error 2 make[2]: *** [conformally_flat_BBH/make.checked] Error 2 make[1]: *** [/work2/00945/rhaas/stampede2/skx/ET_Next/configs/sim/lib/libthorn_NRPyEllipticET.a] Error 2 ``` Prevents compilation of whole ET on common cluster. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2640/nrpyellipticet-fa…

1 0

#2639: CarpetLib internal error with PreSync and analysis thorns
by Samuel Cupp 17 Sep '22

17 Sep '22

#2639: CarpetLib internal error with PreSync and analysis thorns Reporter: Samuel Cupp Status: new Milestone: Version: development version Type: bug Priority: major Component: Carpet Comment (by Samuel Cupp): That's what I thought, which is why I don't have any good guesses as to the source of the problem. Do you have suggestions for what I should look at Monday for this? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2639/carpetlib-interna…

1 0

#2639: CarpetLib internal error with PreSync and analysis thorns
by Roland Haas 17 Sep '22

17 Sep '22

#2639: CarpetLib internal error with PreSync and analysis thorns Reporter: Samuel Cupp Status: new Milestone: Version: development version Type: bug Priority: major Component: Carpet Comment (by Roland Haas): IO triggers a SYNC so if things are output it will SYNC. Also, there’s a forced SYNC before time level cycling. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2639/carpetlib-interna…

1 0

#2639: CarpetLib internal error with PreSync and analysis thorns
by Samuel Cupp 16 Sep '22

16 Sep '22

#2639: CarpetLib internal error with PreSync and analysis thorns Reporter: Samuel Cupp Status: new Milestone: Version: development version Type: bug Priority: major Component: Carpet I’ve found a strange error involving variables from analysis thorns with multiple timelevels $such as WeylScal4 and ML\_ADMConstraints$. The error is ``` WARNING level 0 from host r1i6n25.ib0.sawtooth.inl.gov process 0 in thorn CarpetLib, file /home/cuppsamu/toolkit/Cactus/arrangements/Carpet/CarpetLib/src/gdata.cc:315: -> Internal error: extrapolation in time. variable=ML_ADMCONSTRAINTS::H time=0.040625000000000001 times=[0.018749999999999999,0,-0.018749999999999999] cactus_intel19: /home/cuppsamu/toolkit/Cactus/arrangements/Carpet/Carpet/src/helpers.cc:275: int Carpet::Abort(const _cGH *, int): Assertion `0' failed. Rank 0 with PID 185127 received signal 6 ``` This error comes from repos/carpet/CarpetLib/src/gdata.cc: ```c++ void gdata::find_source_timelevel(vector<CCTK_REAL> const &times, CCTK_REAL const time, int const order_time, operator_type const op, int &timelevel0, int &ntimelevels) const { // Ensure that the times are consistent assert(times.size() > 0); assert(order_time >= 0); CCTK_REAL const eps = 1.0e-12; CCTK_REAL const min_time = *min_element(times.begin(), times.end()); CCTK_REAL const max_time = *max_element(times.begin(), times.end()); // TODO: Use a real delta-time from somewhere instead of 1.0 CCTK_REAL const some_time = std::fabs(min_time) + std::fabs(max_time) + 1.0; if (op != op_copy) { if (time < min_time - eps * some_time or time > max_time + eps * some_time) { ostringstream buf; buf << setprecision(17) << "Internal error: extrapolation in time."; if (varindex >= 0) { char *const fullname = CCTK_FullName(varindex); buf << " variable=" << fullname; ::free(fullname); } buf << " time=" << time << " times=" << times; CCTK_ERROR(buf.str().c_str()); } } ``` I attached the backtrace, as well as the thornlist and parfile I am using. If I comment out ML\_ADMConstraints, I get the same error for WeylScal4. If I also comment out WeylScal4, the simulation proceeds until I hit an error related to the read/writes I’m working on. Since this is happening in CycleTimeLevels → SyncProlongateGroups, it should be related to how we’re handling the timelevels for these variables. Even though these are analysis variables, my understanding of why they need multiple timelevels is because the IO thorns may try to output at an iteration where the coarsest level isn’t available, so it has to interpolate in time to get the values. However, these variables are only for analysis and are therefore only ever written except for IO. Since the error only happens if I turn on PreSync $Cactus::presync\_mode = "mixed-error"$, I am thinking this could somehow connect to how we’re handling the automation of ghost zones/outer boundaries $no syncs automatically triggered since there’s no READs for these variables$, but I don’t have a clear picture of how that could affect this. ‌ More confusingly, if I just add ML\_ADMConstraints to magnetizedTOV-Baikal.par in Baikal, it doesn’t error out. I don’t have a guess for what is causing the behavior, or what triggers it in this parfile. attachment: backtrace.1.txt (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2…) attachment: bbh.par (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2…) attachment: thornlist.th (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2…) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2639/carpetlib-interna…

1 0

#2638: documentation.tex assume to be a specific location relative to Cactus root directory
by Roland Haas 16 Sep '22

16 Sep '22

#2638: documentation.tex assume to be a specific location relative to Cactus root directory Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: Currently the LaTeX documentation files must include a relative path to `cactus.sty` like so: ``` \usepackage{../../../../doc/latex/cactus} ``` which, assuming the “typical” directory layout, accidentally works both when calling `pdflatex` directly $and manually$ on the LaTeX input file in the source code location and via the various `-ThornDoc` and `-ThornGuide` make targets. This is however fragile and fails if e.g. the thorn lives in a git repository of its own so that the directory layout is: ```text Cactus | +- repos | +- ThornRepo | +- doc | +- documenation.tex ``` rather than the expected ``` Cactus | +- repos | +- ArrRepo | +- Thorn | +- doc | +- documenation.tex ``` or $the initially envisioned one assumes$: ``` Cactus | +- arrangements | +- ArrangeMent | +- Thorn | +- doc | +- documenation.tex ``` One way to handle this is to use conditionals to try both locations: ```tex \IfFileExists{../../../doc/latex/cactus.sty} % then {\usepackage{../../../doc/latex/cactus}} % else {\usepackage{../../../../doc/latex/cactus}} ``` which is somewhat cumbersome and only works for those two locations so must be adjusted for each thorn. Another, likely the officially suggested way, is to the `TEXINPUTS` such that `cactus.sty` is directly found. E.g. something like: ``` export TEXTIPUTS=$TOP/doc/latex/: ``` in the Makefile and then use `\usepackage{cactus}` in `documentation.tex`. This however means one can no longer run `pdflatex` directly on the LaTeX sources. There is, since TeX does not actually itself do the searching, no way to set `TEXINPUTS` or a similar thing in TeX files it seems. `\IfFileExists` may rely on LuaTeX features $not sure$ and one may even have to resort to pure TeX for say tex4ht to work $[https://tex.stackexchange.com/questions/98203/can-i-test-if-a-file-exists](https://tex.stackexchange.com/questions/98203/can-i-test-if-a-file-exists)$. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2638/documentationtex-…

1 0

#2485: include complex and real scalar evolution code from Canuda in ET
by Taishi Ikeda 15 Sep '22

15 Sep '22

#2485: include complex and real scalar evolution code from Canuda in ET Reporter: Roland Haas Status: open Milestone: Version: Type: task Priority: major Component: Comment (by Taishi Ikeda): > @Taishi Ikeda could you confirm for the record that the review concluded? I finished my review process for the thorn -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2485/include-complex-a…

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac September 2022