#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…
#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…
#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…
#2598: thornyflat - production run segmentation fault
Reporter: Maria
Status: new
Milestone:
Version: ET_2021_11
Type: bug
Priority: major
Component:
Comment (by Maria):
The helpdesk thinks that is an internal problem with Einstein Toolkit, bug or a bad software design, which has as result not checking for proper allocations. I suspect the problem is in the submit or run files.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2598/thornyflat-produc…