Trac October 2021

trac@lists.einsteintoolkit.org

1 participants
83 discussions

#2469: None of the thorns in WVUThorns_Diagnostics have documentation
by Roland Haas 21 Oct '21

21 Oct '21

#2469: None of the thorns in WVUThorns_Diagnostics have documentation Reporter: Roland Haas Status: new Milestone: ET_2021_05 Version: Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): Is there progress on documentation for the remaining 3 thorns: * particle\_tracerET * Seed\_Magnetic\_Fields\_BNS * smallbPoynET ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2469/none-of-the-thorn…

1 0

#2531: remove non piraha parser from Flesh
by Roland Haas 21 Oct '21

21 Oct '21

#2531: remove non piraha parser from Flesh Reporter: Roland Haas Status: new Milestone: Version: development version Type: enhancement Priority: trivial Component: Comment (by Roland Haas): Has there been any progress removing this? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2531/remove-non-piraha…

1 0

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro
by Erik Schnetter 21 Oct '21

21 Oct '21

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: major Component: Cactus Comment (by Erik Schnetter): The problem is caused by bounds checking, in particular the `-fcheck=bounds` option that is used in debug mode. See <[https://godbolt.org/z/zhGv3bjj6](https://godbolt.org/z/zhGv3bjj6)> for a shortened example. The error message and the comparison \(line 8 \) are clearly visible. I assume what happens is that gfortran stores the actual string length in memory, presumably just before the actual string. With bounds checking enabled, the string length is checked. Cactus never sets up the string length since it just reinterprets pointers, assuming that gfortran’s string layout mimics that of C. You could define a new type \(“struct”\) instead of using `character*8`: ```fortran subroutine sub(beta) implicit none type empty end type type(empty) beta end subroutine sub ``` However, this wouldn’t allow the `kind` trick to make the function argument appear used. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2571/runtime-failure-d…

1 0

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro
by Roland Haas 21 Oct '21

21 Oct '21

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: major Component: Cactus Comment (by Roland Haas): The error message mentions a line number \(13\) in `Cactus/arrangements/EinsteinBase/TmunuBase/src/SetStressEnergyState.F90` which is the line: ```fortran subroutine TmunuBase_SetStressEnergyState (CCTK_ARGUMENTS) ``` The error message also gives the dummy argument in question and the found and expected lengths \(0 and 8 respectively\): `'dtbetax_p' (0/8)` -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2571/runtime-failure-d…

1 0

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro
by Roland Haas 21 Oct '21

21 Oct '21

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: major Component: Cactus Comment (by Roland Haas): It apparently happened in a simulation of Kiki’s \(Kyriaki Dionysopoulou\). Apparently this happened \(the error messages in the ticket description\) in a regular run and “with different parameter files” and “completely different setups” \(quoting Kiki\). I have no idea why this never showed up before in the time since it has been introduced. Not sure if this matters but apparently this happened on \(at least\) an older, Intel macOS laptop using: CPP = cpp-11 FPP = cpp-11 CC = gcc-11 CXX = g\+\+-11 F90 = gfortran-11 GNU Fortran \(Homebrew GCC 11.2.0\) 11.2.0 Copyright \(C\) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2571/runtime-failure-d…

1 0

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro
by Erik Schnetter 21 Oct '21

21 Oct '21

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: major Component: Cactus Comment (by Erik Schnetter): Which line triggers the original error about the string length? Is it the call to the `kind` function, or is it the call to that routine? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2571/runtime-failure-d…

1 0

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro
by Roland Haas 21 Oct '21

21 Oct '21

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: major Component: Cactus Comment (by Roland Haas): Ah, one exception: we do worry about assignment without parenthesis in the case of grid scalars eg `ADMBase::shift_state` would be accessed like this `if(shift_state .ne. 0) then STOP endif`. Though I am not sure if either `charater*8` or `logical*8` would prevent this \(I suspect not\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2571/runtime-failure-d…

1 0

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro
by Roland Haas 21 Oct '21

21 Oct '21

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: major Component: Cactus Comment (by Roland Haas): Changing from `charater*8` to `logical*8` may not be not be enough to avoid assignment. The intel compiler \(ifort \(IFORT\) 18.0.3 20180410\) compiles this without warning: ```fortran program foo implicit none logical*8 :: bar integer*4 :: baz bar = baz end program ``` On the other hand we are not worried about assignment to the pointer itself. We want to fails is things like: `bar(1,2,3)` for reading and writing and passing `bar` to a subroutine \(which we likely cannot prevent no matter what\). So it should be enough for our purposes. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2571/runtime-failure-d…

1 0

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro
by Steven R. Brandt 21 Oct '21

21 Oct '21

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: major Component: Cactus Comment (by Steven R. Brandt): That’s a trivial enough change to make -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2571/runtime-failure-d…

1 0

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro
by Erik Schnetter 21 Oct '21

21 Oct '21

#2571: runtime failure due to useing character*8 in DECLARE_CCTK_ARGUMENTS_CHECKED macro Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: major Component: Cactus Comment (by Erik Schnetter): Clever! Character types are a bit magical in Fortran; they don’t really behave like strings in C. You could use `logical*8` instead; assignments between `integer`/\`real\` and `logical` are also disallowed in Fortran. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2571/runtime-failure-d…

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac October 2021