Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2518: retire BlueGene/Q support in thorn vectors
by Roland Haas 07 Mar '22

07 Mar '22

#2518: retire BlueGene/Q support in thorn vectors Reporter: Roland Haas Status: open Milestone: Version: development version Type: task Priority: minor Component: Changes (by Roland Haas): status: open (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2518/retire-bluegene-q…

1 0

#2518: retire BlueGene/Q support in thorn vectors
by Roland Haas 07 Mar '22

07 Mar '22

#2518: retire BlueGene/Q support in thorn vectors Reporter: Roland Haas Status: new Milestone: Version: development version Type: task Priority: minor Component: Comment (by Roland Haas): Please review. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2518/retire-bluegene-q…

1 0

#2518: retire BlueGene/Q support in thorn vectors
by Roland Haas 07 Mar '22

07 Mar '22

#2518: retire BlueGene/Q support in thorn vectors Reporter: Roland Haas Status: new Milestone: Version: development version Type: task Priority: minor Component: Comment (by Roland Haas): Pull request is here: [https://bitbucket.org/cactuscode/cactusutils/pull-requests/38/vectors-remov… -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2518/retire-bluegene-q…

1 0

#2590: Uninitialized variable in Perl code
by Roland Haas 07 Mar '22

07 Mar '22

#2590: Uninitialized variable in Perl code Reporter: Erik Schnetter Status: resolved Milestone: Version: development version Type: bug Priority: minor Component: Cactus Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2590/uninitialized-var…

1 0

#2590: Uninitialized variable in Perl code
by Roland Haas 07 Mar '22

07 Mar '22

#2590: Uninitialized variable in Perl code Reporter: Erik Schnetter Status: new Milestone: Version: development version Type: bug Priority: minor Component: Cactus Comment (by Roland Haas): Applied as git hash [97419569](https://bitbucket.org/cactuscode/cactus/commits/97419569fbd748131… "Merged in fixuninit \(pull request #136\)" of [cactus](https://bitbucket.org/cactuscode/cactus) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2590/uninitialized-var…

1 0

#2239: GetComponents --avoid-useless-downloads --propose-system-installs
by Roland Haas 07 Mar '22

07 Mar '22

#2239: GetComponents --avoid-useless-downloads --propose-system-installs Reporter: Boud Roukema Status: wontfix Milestone: Version: Type: proposal Priority: major Component: GetComponents Changes (by Roland Haas): status: wontfix (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2239/getcomponents-avo…

1 0

#2396: potential issue with GitHub svn checkouts on Ubuntu
by Roland Haas 07 Mar '22

07 Mar '22

#2396: potential issue with GitHub svn checkouts on Ubuntu Reporter: Roland Haas Status: closed Milestone: Version: Type: bug Priority: minor Component: GetComponents Changes (by Roland Haas): status: closed (was open) Comment (by Roland Haas): Nothing we can do to fix really, since it is a GitHub problem and nothing we control. Just why it (mostly) affects Ubuntu (and WSL which is also Ubuntu), is not clear. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2396/potential-issue-w…

1 0

#2396: potential issue with GitHub svn checkouts on Ubuntu
by Roland Haas 07 Mar '22

07 Mar '22

#2396: potential issue with GitHub svn checkouts on Ubuntu Reporter: Roland Haas Status: open Milestone: Version: Type: bug Priority: minor Component: GetComponents Comment (by Roland Haas): The issue most likely still exists but since git hash [be9c164](https://bitbucket.org/einsteintoolkit/manifest/commits/be9c164e050… "[einsteintoolkit.th](http://einsteintoolkit.th): use git checkout for RePrimAnd" of [manifest](https://bitbucket.org/einsteintoolkit/manifest) and git hash [15eac20](github.com/gridaphobe/CRL/commits/15eac20b021480cfe6a41056b0a3f841… "GetComponents: max --shallow and --branch work together \(#6\)" \(sic\) of [CRL](github.com/gridaphobe/CRL) we no longer use svn in the ET thornlist, instead relying on shallow git checkouts. So most likely the issue will no longer happen to new installs. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2396/potential-issue-w…

1 0

#2599: nsnstohmns cannot be reproduced using LORENE2
by Ken Hui 04 Mar '22

04 Mar '22

#2599: nsnstohmns cannot be reproduced using LORENE2 Reporter: Ken Hui Status: new Milestone: ET_2021_05 Version: ET_2021_05 Type: bug Priority: minor Component: Cactus Comment (by Ken Hui): \(Updates\) Okay, it turns out that if I amend some of the parameters in Lorene/C\+\+/Include/unites.h in LORENE2 according to those in LORENE1, I can reproduce the nsnstohmns simulation. But I would still like to know if there is a way to understand how it causes the error in Carpet, and how it can be fixed. Thank you. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2599/nsnstohmns-cannot…

1 0

#2599: nsnstohmns cannot be reproduced using LORENE2
by Ken Hui 04 Mar '22

04 Mar '22

#2599: nsnstohmns cannot be reproduced using LORENE2 Reporter: Ken Hui Status: new Milestone: ET_2021_05 Version: ET_2021_05 Type: bug Priority: minor Component: Cactus I have been using the Lorentz release of EinsteinToolkit to reproduce the simulation nsnstohmns in the ET gallery. Compiling with LORENE1, the simulation works well but I encountered some errors from the Carpet thorn with LORENE2: ``` INFO (NSTracker): Found star at (4.21875,12.0938,0) 29304 824.175 | 126.7906196 | 0.0001241 0.0019978 | 0.0007481 | 1.1329054 | 0.0008567 | 1182 INFO (CarpetRegrid2): Enforcing grid structure properties, iteration 0 INFO (CarpetRegrid2): Enforcing grid structure properties, iteration 1 WARNING level 1 from host chpc-cn024.rc.cuhk.edu.hk process 0 in thorn CarpetLib, file /opt/Cactus/configs/sim/build/CarpetLib/dh.cc:161: -> /opt/Cactus/configs/sim/build/CarpetLib/dh.cc:973: [ml=0 rl=6 c=0] The following grid structure consistency check failed: Synchronisation and boundary prolongation: All points must have been received needrecv.empty() ml=0 rl=6 baseextent=([756,504,756]:[6408,11784,6408]:[4,4,4]/[189,126,189]:[1602,2946,1602]/[1414,2821,1414]/5640296116) ml=0 rl=6 c=0 extent=([756,5748,756]:[932,5916,872]:[4,4,4]/[189,1437,189]:[233,1479,218]/[45,43,30]/58050) outer_boundaries=[[1,0,1],[0,0,0]] processor=0 ... ... ... memoryof(gh)=15396 memoryof(dh)=138360 memoryof(dh.light_boxes)=11304 memoryof(dh.local_boxes)=96952 memoryof(dh.level_boxes)=7328 memoryof(dh.fast_boxes)=16156 #gfs=181 memoryof(gfs)=193316 WARNING level 0 from host chpc-cn024.rc.cuhk.edu.hk process 0 in thorn CarpetLib, file /opt/Cactus/configs/sim/build/CarpetLib/dh.cc:2105: -> The grid structure is inconsistent. It is impossible to continue. 3 total processes killed (some possibly by mpirun during cleanup) Stopping: ``` In previous release\(s\), only LORENE2 respect the manual input of eos\_file\_path parameters in Meudon\_Bin\_NS. But now it appears that the problem has been fixed in by: Cactus/arrangements/ExternalLibraries/LORENE/dist/eos\_table\_filepath.patch I wonder if there is no reason to use LORENE2 over LORENE1 anymore, and if someone could provide a hint to fix the above errors arose in Carpet. I am grateful for any help and comments. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2599/nsnstohmns-cannot…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac