Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2598: thornyflat - production run segmentation fault
by Anuj Kankani 07 Jul '22

07 Jul '22

#2598: thornyflat - production run segmentation fault Reporter: Maria Status: new Milestone: Version: ET_2021_11 Type: bug Priority: major Component: Comment (by Anuj Kankani): I am actually able to get ETK running on thornyflat $and spruceknob$ using simfactory by slightly modifying the configuration files attached above . My only issue is that when creating a new simulation, the run and submit script that get used are the generic onces, despite me specifying --machine thornyflat. By manually going in and replacing the run and submit files in the simulation directory, everything works fine. In the thornyflat machine file I specify the thornyflat configuration files, so I’m not sure why it’s still choosing the generic ones. Is there some step I am missing? I have attached the machine file I am using here. ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2598/thornyflat-produc…

1 0

#2615: Riemann release not compiling with intel 2021.6.0
by Roland Haas 07 Jul '22

07 Jul '22

#2615: Riemann release not compiling with intel 2021.6.0 Reporter: Wolfgang Kastaun Status: new Milestone: Version: ET_2022_05 Type: bug Priority: minor Component: Comment (by Roland Haas): This was discussed for a bit in today’s ET call. Is there a public cluster where this happens and that could be used for testing? Most the XSEDE systems would be fine as well as SupeMUC at LRZ. A less convenient solution would be a pointer to where one can download Intel’s OneAPI and compiler these days. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2615/riemann-release-n…

1 0

#2598: thornyflat - production run segmentation fault
by Roland Haas 07 Jul '22

07 Jul '22

#2598: thornyflat - production run segmentation fault Reporter: Maria Status: new Milestone: Version: ET_2021_11 Type: bug Priority: major Component: Comment (by Roland Haas): This was discussed in today’s ET call. While difficult to diagnose remotely, the suggestion were that this may be due to mismatched MPI stacks during compile and runtime or due to incorrect `LD_LIBRARY_PATH`. Without access to the system though, this is almost impossible to correctly diagnose. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2598/thornyflat-produc…

1 0

#2617: AEILocalInterp can produce GBs of level 1 warnings if interpolation points are outside of the domain
by Roland Haas 06 Jul '22

06 Jul '22

#2617: AEILocalInterp can produce GBs of level 1 warnings if interpolation points are outside of the domain Reporter: Roland Haas Status: new Milestone: Version: Type: bug Priority: minor Component: EinsteinToolkit thorn AEILocalInterp will produce warning about each point that it is asked to interpolate to that is outside of the domain. This can easily lead to many many essentially identical warnings if eg the center of a spherical surface is set to NaN but a failure of shift tracking. Instead of producing warnings all the time I would propose the following change in behaviour: * by default output no more than $say$ 10 points, then be silent and report “and NN more warnnings” at the end * add an option to either make the warning level 0 right away $an error$ or once 10 pints have been reached the limits would apply to each interpolator call $LocalInterpUniform call really so technically per grid component$ and thus reset after each call. Note: AEILocalInterp uses a level 1 warning since it actually does follow documented $but mostly ignored$ Cactus design that states that a level 1 warning is almost certainly going to lead to incorrect result but that the code can continue $[http://einsteintoolkit.org/referencemanual/ReferenceManual.html#x1-235000A2](http://einsteintoolkit.org/referencemanual/ReferenceManual.html#x1-235000A2)$. So it _is_ indeed using the warning level as documented, just not like everyone else does. > #define CCTK\_WARN\_ABORT 0 /\* abort the Cactus run \*/ > \#define CCTK\_WARN\_ALERT 1 /\* the results of this run will probably \*/ > /\* be wrong, but this isn’t quite certain, \*/ > /\* so we’re not going to abort the run \*/ > \#define CCTK\_WARN\_COMPLAIN 2 /\* the user should know about this, but \*/ > /\* the results of this run are probably ok \*/ > \#define CCTK\_WARN\_PICKY 3 /\* this is for small problems that can \*/ > /\* probably be ignored, but that careful \*/ > /\* people may want to know about \*/ > \#define CCTK\_WARN\_DEBUG 4 /\* these messages are probably useful \*/ > /\* only for debugging purposes \*/ ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2617/aeilocalinterp-ca…

1 0

#181: AEILocalInterp should not off-centre the interpolation stencil by default
by Roland Haas 06 Jul '22

06 Jul '22

#181: AEILocalInterp should not off-centre the interpolation stencil by default Reporter: Ian Hinder Status: open Milestone: Version: Type: bug Priority: minor Component: Cactus Comment (by Roland Haas): Poking this old ticket. Please review the solution proposed in [https://bitbucket.org/einsteintoolkit/tickets/issues/181/aeilocalinterp-sho… $11 years old$ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/181/aeilocalinterp-sho…

1 0

#181: AEILocalInterp should not off-centre the interpolation stencil by default
by Roland Haas 06 Jul '22

06 Jul '22

#181: AEILocalInterp should not off-centre the interpolation stencil by default Reporter: Ian Hinder Status: open Milestone: Version: Type: bug Priority: minor Component: Cactus Changes (by Roland Haas): assignee: Roland Haas (was ) responsible: [] (was ) AEILocalInterp by default will off-centre the interpolation stencil if there are insufficient points to perform the interpolation. In a parallel setting, this could happen due to there being insufficient ghost points for the interpolator chosen. The off-centering leads to an interpolation error which is of the correct order but larger than for a centered stencil. More importantly, it leads to different results on different numbers of processes. This violates a basic design principle of Cactus, and the expectation of users, that changing the number of processors should not change the results of a simulation. I propose that instead of silently off-centering the stencil, AEILocalInterp should abort with an error indicating that there are insufficient ghost-zones. The interpolator options corresponding to this are: boundary_off_centering_tolerance={0.0 0.0 0.0 0.0 0.0 0.0} boundary_extrapolation_tolerance={0.0 0.0 0.0 0.0 0.0 0.0} **Keyword:** AEILocalInterp -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/181/aeilocalinterp-sho…

1 0

#2598: thornyflat - production run segmentation fault
by Anuj Kankani 30 Jun '22

30 Jun '22

#2598: thornyflat - production run segmentation fault Reporter: Maria Status: new Milestone: Version: ET_2021_11 Type: bug Priority: major Component: Comment (by Anuj Kankani): Was this issue ever sorted out? I’m currently trying get ETK running on Thorny Flat but am running into many issues including this one. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2598/thornyflat-produc…

1 0

#2611: disable use of mathml in online HTML docs
by Roland Haas 30 Jun '22

30 Jun '22

#2611: disable use of mathml in online HTML docs Reporter: Roland Haas Status: open Milestone: Version: development version Type: bug Priority: minor Component: Cactus Comment (by Roland Haas): Applied as git hash [6595839e](https://bitbucket.org/cactuscode/cactus/commits/6595839e91108a280… "Cactus: disable mathml use in HTML docs" of [cactus](https://bitbucket.org/cactuscode/cactus) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2611/disable-use-of-ma…

1 0

#2613: updates to tutorial notebook for Riemann release
by Roland Haas 30 Jun '22

30 Jun '22

#2613: updates to tutorial notebook for Riemann release Reporter: Roland Haas Status: resolved Milestone: Version: development version Type: bug Priority: major Component: EinsteinToolkit website Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2613/updates-to-tutori…

1 0

#2612: GetComponents assumes that $USER is defined
by Roland Haas 30 Jun '22

30 Jun '22

#2612: GetComponents assumes that $USER is defined Reporter: Roland Haas Status: resolved Milestone: Version: development version Type: bug Priority: minor Component: GetComponents Changes (by Roland Haas): status: resolved (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2612/getcomponents-ass…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac