Trac

trac@lists.einsteintoolkit.org

8708 discussions

#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

#2616: Add NRPyEllipticET to the Einstein Toolkit
by Cheng-Hsin Cheng 15 Sep '22

15 Sep '22

#2616: Add NRPyEllipticET to the Einstein Toolkit Reporter: Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Cheng-Hsin Cheng): @{557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22} yes, I would like to confirm that we concluded the review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2616/add-nrpyelliptice…

1 0

#2616: Add NRPyEllipticET to the Einstein Toolkit
by Leonardo Werneck 15 Sep '22

15 Sep '22

#2616: Add NRPyEllipticET to the Einstein Toolkit Reporter: Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Leonardo Werneck): Hi all. Here are the updates made to `NRPyEllipticET` based on the reviewers' comments: * A brief `README` file has been added; * `uuGF`'s description has been updated in `interface.ccl`; * `info_output_freq`'s comment has been updated in `param.ccl`; * `N2`'s “forbidden value” has been removed, as it was unused; * `initialize_offdiagonal_metric_to_zero` was indeed an old parameter and has been removed; * All instances of `fprintf(stderr,...); exit();` have been replaced by either `CCTK_*ERROR` or `CCTK_*WARN`; * We have added a new parameter called `residual_integration_radius`, with a proper description of what it does; * Some of the algorithms are hard to describe using brief code comments. We recommend looking at the NRPy\+ Jupyter notebooks for the complete description of such algorithms; * Thank you for pointing out that `CFL_FACTOR` was missing in `find_timestep.c`; this was actually a bug fix; * Unfortunately the code in `wavespeed_gf_all_points.c` depends on `dt` $the result of `find_timestep.c`$ at every grid point and thus the two cannot be decoupled; * The reason why the `rfm` parameters have the unused attribute is similar to the reason why parameters have the attribute, i.e., not every function that uses the `rfm` includes will use _all_ of the included parameters, which could lead to warnings; * All instances of `__attribute__((unused))` have been replaced with `CCTK_ATTRIBUTE_UNUSED`; * I have removed the empty files in `conformally_flat_BBH/rfm_files/` manually and am trying to figure out a way of automating this; * `apply_bcs_curvilinear_radiation.c` and `set_Cparameters-SIMD.h` have been removed for now; * `xx_to_Cart.c` and `set_Cparameters-nopointer.h` have _not_ been removed. Although currently unused by the thorn, they provide useful functionality that new users might want to use. A general comment: the Jupyter notebook that generates `NRPyEllipticET` was very outdated. I am currently pushing on getting it up to speed, but at the moment we do not have a notebook that regenerates the latest version of the thorn. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2616/add-nrpyelliptice…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac