Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2647: incorrect WENO coefficient in GRHydro WENO reconstruction code
by Roland Haas 27 Sep '22

27 Sep '22

#2647: incorrect WENO coefficient in GRHydro WENO reconstruction code Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Changes (by Roland Haas): status: open (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2647/incorrect-weno-co…

1 0

#2647: incorrect WENO coefficient in GRHydro WENO reconstruction code
by Roland Haas 27 Sep '22

27 Sep '22

#2647: incorrect WENO coefficient in GRHydro WENO reconstruction code Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Please review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2647/incorrect-weno-co…

1 0

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

27 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): So, the heart of the problem comes from $I think$ the function ``` th::regrid() ``` in repos/carpet/CarpetLib/src/th.cc:51. When this runs, it sets the ``` deltas.AT(ml).AT(rl) ``` object to 1.0 $possibly divided by the timereffacts$, which then causes an incorrect cctk\_time. This seems to be polluting some functions which call get\_time. This happens without PreSync, but by miracle $design?$ it gets reset to the right value before anything tries to use it. This does not occur in time with PreSync. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2639/carpetlib-interna…

1 0

#2647: incorrect WENO coefficient in GRHydro WENO reconstruction code
by Roland Haas 27 Sep '22

27 Sep '22

#2647: incorrect WENO coefficient in GRHydro WENO reconstruction code Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: major Component: EinsteinToolkit thorn The GRHydro WENO reconstruction code selected by `GRHydro::recon_method = "weno"` employs incorrect values for the `weno_coeffs` array that is constructed from the WENO $omega\_r$ values. The current values are in fact WENO interpolation instead of WENO reconstruction. Pull request [https://bitbucket.org/einsteintoolkit/einsteinevolve/pull-requests/17/rhaas… corrects the coefficients, re-computing them from the original publication used to implement the code $“WHAM paper”, [https://arxiv.org/abs/0704.2608](https://arxiv.org/abs/0704.2608)$ and updates the test data as well. The attached stand-alone test $extracted code from GRHydro$ demonstrates the issue and shows that only WENO-Z and WHAM’s WENO do show the WENO property of exactly reconstructing smooth data of low order polynomials $2nd order in the test, but should be up to 5th order$. It also shows that WENO as implemented by GRHydro is actually WENO interpolation. This effectively reduces WENO to a 2nd order accurate scheme similar to a basic tvd scheme I would guess. attachment: weno.cc (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2…) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2647/incorrect-weno-co…

1 0

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

26 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): Great work tracking this down! -- 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 26 Sep '22

26 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): I’ve made some progress in tracking down the source of this error. The if$time within times min/max$ statement tracks back to checking if ``` const CCTK_REAL time = cctkGH->cctk_time (carpet/Carpet/src/Comm.cc:253) ``` is inside ``` times.AT(i) = t.get_time(ml2, rl2, tl2s.AT(i)) (carpet/CarpetLib/src/ggf.cc:540) ``` which has the length of ``` tl2s: tl2s.resize(prolongation_order_time + 1) (carpet/CarpetLib/src/ggf.cc:379) ``` In this parfile, the first several reflevels are not subcycling, so they should all step at the same iterations. I’m printing out a lot of stuff since its inside these functions, so the first times I’m seeing for reflevel 0 are 0.15, and 0.3 $presumably its also running at the rk4 half-step, which is why i’m getting two times for each iteration on a single level$. If I run it with PreSync off, I see these same times appear for all the ones moving in lockstep, and it then goes into smaller time discretizations once it reaches the subcycled reflevels. However, this does not happen with PreSync. Instead, when it gets to reflevel 1, cctk\_time returns a value of 1 instead of 0.15, which is not inside the bounds of that vector of times, causing the error. So somehow PreSync is affecting what `cctkGH->cctk_time` is. I’m going to try to construct a simpler test case that still reproduces this now that I have concrete behavior to look for to making debugging easier. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2639/carpetlib-interna…

1 0

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

22 Sep '22

#2616: Add NRPyEllipticET to the Einstein Toolkit Reporter: Status: new Milestone: Version: Type: enhancement Priority: major Component: Comment (by Leonardo Werneck): @{557058:59e031ba-9bb5-4298-a472-7b99d0ae6f22} I have added a `test` directory to `NRPyEllipticET`. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2616/add-nrpyelliptice…

1 0

#2646: Replace error/warning messages by CCTK_ERROR/CCTK_WARN in IllinoisGRMHD
by Leonardo Werneck 22 Sep '22

22 Sep '22

#2646: Replace error/warning messages by CCTK_ERROR/CCTK_WARN in IllinoisGRMHD Reporter: Leonardo Werneck Status: new Milestone: Version: Type: task Priority: minor Component: Commits [f3202a7](https://bitbucket.org/zach_etienne/wvuthorns/commits/f3202a79db276… and [78143cb](https://bitbucket.org/zach_etienne/wvuthorns/commits/78143cb3f8f6e… to the master branch of `wvuthorns` provide updates to `IllinoisGRMHD` that have been previously suggested. These are: * The sequence `printf(error_message); exit(1)` in `harm_primitives_lowlevel.C` of `IllinoisGRMHD` has been replaced by `CCTK_VERROR(error_message)`; * A warning messaged printed using `printf(...)` in `inlined_functions.C` has been replaced by the appropriate call to `CCTK_VWARN(CCTK_WARN_ALERT, ...)`. Cheers, Leo -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2646/replace-error-war…

1 0

#2645: Major update to Baikal/BaikalVacuum
by Zach Etienne 22 Sep '22

22 Sep '22

#2645: Major update to Baikal/BaikalVacuum Reporter: Zach Etienne Status: new Milestone: Version: Type: enhancement Priority: major Component: Changes (by Zach Etienne): First off, there are no new features or new parameters/parameter defaults in this update. All math kernels are identical as well. This is strictly the result of a modernization of the code generation infrastructure. The codegen of `Baikal` and `BaikalVacuum` has been updated to conform to the latest NRPy\+ standards, which emphasize registration of C functions with NRPy\+ instead of oodles of `.h` files that can be hard to track. Parallel codegen is far more robust, and maintainability has been greatly improved $`./run_Jupyter_notebook.sh Tutorial-ETK_thorn-BaikalETK.ipynb` is the only means to generate the thorns; before the Jupyter notebook contents were completely copied into separate Python modules$. Here are the steps needed to validate this latest version against the original: 1. Clone the latest NRPy\+ repo: git clone [https://github.com/zachetienne/nrpytutorial.git](https://github.com/zacheti… 2. Make sure you have jupyter and sympy installed $pip install jupyter sympy$ 3. Make sure you have downloaded the latest ET _release_ [https://einsteintoolkit.org/download.html](https://einsteintoolkit.org/down… 4. Go into the nrpytutorial directory and type ./convert\_jupyter\_to\_python\_and\_run.sh Tutorial-ETK\_thorn-BaikalETK.ipynb 5. Step 4 above should've generated the updated Baikal & BaikalVacuum thorns. 6. E.g., go into BaikalVacuum/src/ and diff a RHS file against the latest ET release version via: diff -w rhs\_eval\_BaikalVacuum\_order\_4.c \[path to latest ET release\]/arrangements/WVUThorns/BaikalVacuum/src/BSSN\_RHSs\_enable\_Tmunu\_False\_FD\_order\_4.c notice that -w ignores whitespace differences, which is important since the latest version does proper tabbing. You'll see that the math kernel is _identical_, and the only differences include things like adding CCTK\_ATTRIBUTE\_UNUSED to various automatically generated constants, which may not be used and using NGHOSTS=cctk\_nghostzones\[0\] consistently. Other RHS orders, Ricci evaluations, and constraint calculations can be compared in a similar fashion. The pull request is here: [https://bitbucket.org/zach\_etienne/wvuthorns/pull-requests/12/modernize-ba… I will merge this pull request on Tuesday Sept 27, unless there are objections. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2645/major-update-to-b…

1 0

#2645: Major update to Baikal/BaikalVacuum
by Zach Etienne 22 Sep '22

22 Sep '22

#2645: Major update to Baikal/BaikalVacuum Reporter: Zach Etienne Status: new Milestone: Version: Type: enhancement Priority: major Component: First off, there are no new features or new parameters/parameter defaults in this update. All math kernels are identical as well. This is strictly the result of a modernization of the code generation infrastructure. The codegen of `Baikal` and `BaikalVacuum` has been updated to conform to the latest NRPy\+ standards, which emphasize registration of C functions with NRPy\+ instead of oodles of `.h` files that can be hard to track. Parallel codegen is far more robust, and maintainability has been greatly improved $`./run_Jupyter_notebook.sh Tutorial-ETK_thorn-BaikalETK.ipynb` is the only means to generate the thorns; before the Jupyter notebook contents were completely copied into separate Python modules$. Here are the steps needed to validate this latest version against the original: 1. Clone the latest NRPy\+ repo: git clone [https://github.com/zachetienne/nrpytutorial.git](https://github.com/zacheti… 2. Make sure you have jupyter and sympy installed $pip install jupyter sympy$ 3. Make sure you have downloaded the latest ET _release_ [https://einsteintoolkit.org/download.html](https://einsteintoolkit.org/down… 4. Go into the nrpytutorial directory and type ./convert\_jupyter\_to\_python\_and\_run.sh Tutorial-BaikalETK\_new\_way.ipynb 5. Step 4 above should've generated the updated Baikal & BaikalVacuum thorns. 6. E.g., go into BaikalVacuum/src/ and diff a RHS file against the latest ET release version via: diff -w rhs\_eval\_BaikalVacuum\_order\_4.c \[path to latest ET release\]/arrangements/WVUThorns/BaikalVacuum/src/BSSN\_RHSs\_enable\_Tmunu\_False\_FD\_order\_4.c notice that -w ignores whitespace differences, which is important since the latest version does proper tabbing. You'll see that the math kernel is _identical_, and the only differences include things like adding CCTK\_ATTRIBUTE\_UNUSED to various automatically generated constants, which may not be used and using NGHOSTS=cctk\_nghostzones\[0\] consistently. Other RHS orders, Ricci evaluations, and constraint calculations can be compared in a similar fashion. The pull request is here: [https://bitbucket.org/zach\_etienne/wvuthorns/pull-requests/12/modernize-ba… I will merge this pull request on Tuesday Sept 27, unless there are objections. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2645/major-update-to-b…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac