Trac October 2021

trac@lists.einsteintoolkit.org

1 participants
83 discussions

#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): We are using `characTer*8, intent(IN) :: dtbetax_p` for grid functions that are neither read nor written by a scheduled function that is that should not even be accessible. Since there is only a single C to Fortran wrapper per thorn, they are still being passed to the Fortran subroutine but we want to make sure that the compiler aborts with an error if the code actually tries to access it. Declaring it as a nonsensical type achieves that since the compiler will not let you assign a real or integer number to a `charcater*8`. We can only use `character*(*)` if that does not add an extra integer “length of string” to the end of the argument list. We may however have to do something like: ``` CCTK_REAL :: dtbetax_p integer, parameter :: cctki_use_dtbetax_p = kind(dtbetax_p) #define dtbetax_p dtbetax_p_IS_NOT_ACCESSIBLE ``` ‌ -- 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 20 Oct '21

20 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): A declaration `character*8` as input argument is really strange. one would only use that if one knows that the length is 8, similar to passing a character array in C \(instead of a character pointer\). Usually one would write `character*(*)`, and the compiler then passes the actual string length as additional \(hidden\) argument, and uses that length in the callee. In this case I rather think that the Fortran code is a mistranslation from C, and that the code generating the `_CHECKED` macro is wrong. `dtbetax_p` should be declared as `CCTK_REAL dtbetax_p(ash0, ash1, ash2)` instead. None of the Cactus grid function or parameter passing arguments or declaration use Fortran `character` variables. -- 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 20 Oct '21

20 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 I just learned \(via Skype\) that Cactus' use of `character*8` variables can cause runtime errors in Fortran: ``` At line 13 of file Cactus/arrangements/EinsteinBase/TmunuBase/src/SetStressEnergyState.F90 Fortran runtime error: Actual string length is shorter than the declared one for dummy argument 'dtbetax_p' (0/8) ``` and digging down a bit and looking at the processed Fortran file \(configs/sim/build/TmunuBase/SetStressEnergyState.f90\) one finds: ```fortran characTer*8, intent(IN) :: dtbetax_p integer, parameter :: cctki_use_dtbetax_p = kind(dtbetax_p) ``` and [https://stackoverflow.com/questions/4780069/passing-a-string-as-an-argument… where the Fortran 2003 standard gets quoted with an explanation: > If a scalar dummy argument is of type default character, the length len of the dummy argument shall be less than or equal to the length of the actual argument. The dummy argument becomes associated with the leftmost len characters of the actual argument. This all used gfortran 11. Safest would be if we could declare as `characTer*0` if that is allowed. Of course it’s still wrong in that the actual argument passed to `dtbetax_p` is never a character at all \(it’s either a double precision real or NULL\) and we only use the `characTer` construct to avoid assignment and also unused actual argument warnings. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2571/runtime-failure-d…

1 0

#2561: Update the simfactory entry for Expanse
by Roland Haas 12 Oct '21

12 Oct '21

1 0

#2561: Update the simfactory entry for Expanse
by Gabriele Bozzola 12 Oct '21

12 Oct '21

#2561: Update the simfactory entry for Expanse Reporter: Gabriele Bozzola Status: open Milestone: Version: development version Type: bug Priority: minor Component: SimFactory Comment (by Gabriele Bozzola): Hi Roland, I didn’t act quickly enough and the invitation expired. Can you send another one? > Having said that: the commit seems to indicate that “numpy” fails, so you are using numpy in your rpar files? Yes, that is correct. > The pull request also adds a line ``` OPENBLAS_DIR = /cm/shared/apps/spack/cpu/opt/spack/linux-centos8-zen2/gcc-10.2.0/openblas-0.3.10-3lzjcwjsyu3qmott7k3k52mtzljioax3/ ``` > to the option list which seems to go beyond the stated goal of fixing some issue with Python, at least at first glance. Adding it \(assuming that this is the correct path for the loaded module\) is the correct thing to do, but ideally should be done in a separate commit \(no stealth changes with subject lines “[whiterabbit.](http://whiterabbit.com/)exe” please\). NumPy is compiled against OpenBlas, which has to be loaded to correctly use the package. The line ensures that OpenBlas is consistent within the environment \(ie, NumPy and Einstein Toolkit use the same OpenBlas, as it is provided by the module\). I agree that this a little bit beyond the scope of the commit, also because there is no need for NumPy and Einstein Toolkit to use the same OpenBlas. ‌ In general, following the discussion in the mailing list \([http://lists.einsteintoolkit.org/pipermail/users/2021-August/008179.html](http://lists.einsteintoolkit.org/pipermail/users/2021-August/008179.html)\), it is likely that this entry for Expanse is not the best one. I am waiting to see if the admins do anything about their ucx/verbs stack. ‌ -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2561/update-the-simfac…

1 0

#1437: Missing option for deterministic noise in CactusNumerical/Noise
by Roland Haas 01 Oct '21

01 Oct '21

#1437: Missing option for deterministic noise in CactusNumerical/Noise Reporter: Frank Löffler Status: new Milestone: Version: development version Type: enhancement Priority: minor Component: EinsteinToolkit thorn Comment (by Roland Haas): @{557058:cf051f66-042f-4a92-a2c7-f2be5a7912de} didn’t you write such a pseudo-rng thorn at one point? For MC simulations? -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1437/missing-option-fo…

1 0

#1265: SimFactory does not support job chaining on supermuc
by Roland Haas 01 Oct '21

01 Oct '21

#1265: SimFactory does not support job chaining on supermuc Reporter: Ian Hinder Status: wontfix Milestone: Version: Type: enhancement Priority: minor Component: SimFactory Changes (by Roland Haas): status: wontfix (was new) Error: Machine supermuc currently does not support job chaining. Please modify the submit command or submission script to support job chaining. **Keyword:** Comment (by Roland Haas): SuperMUC (not SuperMUC-NG) has long since been retired. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1265/simfactory-does-n…

1 0

#1051: Generate html that has only a single page
by Roland Haas 01 Oct '21

01 Oct '21

#1051: Generate html that has only a single page Reporter: Erik Schnetter Status: resolved Milestone: Version: Type: enhancement Priority: minor Component: EinsteinToolkit website Changes (by Roland Haas): status: resolved (was new) When generating html documentation, generate also a version that consists of only a single page, to make searching easier. **Keyword:** -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1051/generate-html-tha…

1 0

#1051: Generate html that has only a single page
by Roland Haas 01 Oct '21

01 Oct '21

#1051: Generate html that has only a single page Reporter: Erik Schnetter Status: new Milestone: Version: Type: enhancement Priority: minor Component: EinsteinToolkit website Comment (by Roland Haas): No idea when this was changed but at least right now the UserGuide [https://www.einsteintoolkit.org/usersguide/UsersGuide.html](https://www.ein… and reference manual [https://www.einsteintoolkit.org/referencemanual/ReferenceManual.html](https… are both single, very long HTML pages. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1051/generate-html-tha…

1 0

#1072: User guide does not explain how to use boolean parameters from Fortran.
by Roland Haas 01 Oct '21

01 Oct '21

#1072: User guide does not explain how to use boolean parameters from Fortran. Reporter: Ian Hinder Status: invalid Milestone: Version: Type: bug Priority: minor Component: Cactus Changes (by Roland Haas): status: invalid (was new) The Cactus user guide does not explain how to use boolean parameters from Fortran. **Keyword:** documentation -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1072/user-guide-does-n…

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