Trac August 2021

trac@lists.einsteintoolkit.org

1 participants
125 discussions

#2546: CarpetIOHDF5: Don't set "delta" attribute to zero for zero-width components
by Erik Schnetter 08 Aug '21

08 Aug '21

#2546: CarpetIOHDF5: Don't set "delta" attribute to zero for zero-width components Reporter: Erik Schnetter Status: closed Milestone: Version: development version Type: enhancement Priority: minor Component: Changes (by Erik Schnetter): status: closed (was resolved) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2546/carpetiohdf5-dont…

1 0

#2546: CarpetIOHDF5: Don't set "delta" attribute to zero for zero-width components
by Erik Schnetter 08 Aug '21

08 Aug '21

#2546: CarpetIOHDF5: Don't set "delta" attribute to zero for zero-width components Reporter: Erik Schnetter Status: resolved Milestone: Version: development version Type: enhancement Priority: minor Component: Changes (by Erik Schnetter): status: resolved (was open) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2546/carpetiohdf5-dont…

1 0

#2546: CarpetIOHDF5: Don't set "delta" attribute to zero for zero-width components
by Erik Schnetter 08 Aug '21

08 Aug '21

#2546: CarpetIOHDF5: Don't set "delta" attribute to zero for zero-width components Reporter: Erik Schnetter Status: open Milestone: Version: development version Type: enhancement Priority: minor Component: Comment (by Erik Schnetter): Applied in [https://bitbucket.org/eschnett/carpet/commits/73edd0639548fb158c5f196f647f2…. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2546/carpetiohdf5-dont…

1 0

#2548: Compilation failure: "const" assignment in LoopControl/src/loopcontrol.cc
by Roland Haas 06 Aug '21

06 Aug '21

1 0

#2548: Compilation failure: "const" assignment in LoopControl/src/loopcontrol.cc
by Roland Haas 06 Aug '21

06 Aug '21

#2548: Compilation failure: "const" assignment in LoopControl/src/loopcontrol.cc Reporter: Bernard Kelly Status: open Milestone: ET_2021_05 Version: ET_2021_05 Type: bug Priority: major Component: EinsteinToolkit thorn Comment (by Roland Haas): I can compile fine with Intel 17 on Blue Waters if I use a modern enough C\+\+ library. However if I force it to use gcc 4.3 by using --gxx-name then I get the same error that you see: ``` COMPILING Carpet/LoopControl/src/loopcontrol.cc /mnt/a/u/staff/rhaas/ET_Next/arrangements/Carpet/LoopControl/src/loopcontrol.cc(70): error: function call must have a constant value in a constant expression lc_random.max() - lc_random.min() + 1; ^ /mnt/a/u/staff/rhaas/ET_Next/arrangements/Carpet/LoopControl/src/loopcontrol.cc(70): error: function call must have a constant value in a constant expression lc_random.max() - lc_random.min() + 1; ^ compilation aborted for /mnt/a/u/staff/rhaas/ET_Next/configs/sim-intel/build/LoopControl/loopcontrol.cc (code 2) ``` so both this and #2547 are due to a too old stdc\+\+ library. Trying to work around this by using `minstd_rand::max()` does not work and gives: ```plaintext COMPILING Carpet/LoopControl/src/loopcontrol.cc /mnt/a/u/staff/rhaas/ET_Next/arrangements/Carpet/LoopControl/src/loopcontrol.cc(70): error: a nonstatic member reference must be relative to a specific object minstd_rand::max() - minstd_rand::min() + 1; ^ /mnt/a/u/staff/rhaas/ET_Next/arrangements/Carpet/LoopControl/src/loopcontrol.cc(70): error: a nonstatic member reference must be relative to a specific object minstd_rand::max() - minstd_rand::min() + 1; ^ compilation aborted for /mnt/a/u/staff/rhaas/ET_Next/configs/sim-intel/build/LoopControl/loopcontrol.cc (code 2) ``` indicating that the library does not declare the function correctly as a static class function and indeed digging into the header files on BlueWaters shows it to be defined as: ```c++ result_type max() const { return __m - 1; } ``` A workaround would be to remove `constexpr` from this line of code but given that thorn `Vectors` also fails with due to the same old C\+\+ library, I am not sure if the workaround would help a lot \(would only help in situations where `LoopControl` but not `Vectors` is used\). -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2548/compilation-failu…

1 0

#2407: Cactus math work-arounds break CarpetX reduction operators
by Roland Haas 06 Aug '21

06 Aug '21

#2407: Cactus math work-arounds break CarpetX reduction operators Reporter: Erik Schnetter Status: open Milestone: Version: Type: bug Priority: major Component: Cactus Comment (by Roland Haas): Comet had been retired so is no longer an issue. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2407/cactus-math-work-…

1 0

#2534: Evolution of grid arrays with Mol no longer works
by Roland Haas 06 Aug '21

06 Aug '21

#2534: Evolution of grid arrays with Mol no longer works Reporter: Status: new Milestone: Version: development version Type: bug Priority: major Component: Carpet Comment (by Roland Haas): Somewhat unrelated: instead of the current workaround for arrays of > The kludge was to check to see that if the "correct" component is being updated, and if not, re-write the old values of the grid array\). wouldn’t it be possible ot make this work by scheduling the RHS function as `GLOBAL` ? That way it would only execute once per iteration and not once per iteration per refinement level. MoL would still update the state vector for the array but b/c it initializes the RHS to zero before the `CalcRHS` schedule group the fact that the RHS routine does not run would leave the RHS unchanged \(ie 0\) and thus effectively no update would be done. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2534/evolution-of-grid…

1 0

#2534: Evolution of grid arrays with Mol no longer works
by Roland Haas 06 Aug '21

06 Aug '21

#2534: Evolution of grid arrays with Mol no longer works Reporter: Status: new Milestone: Version: development version Type: bug Priority: major Component: Carpet Comment (by Roland Haas): Writing my own parfile: ``` ActiveThorns = "Time MoL" ActiveThorns = "Coordbase CartGrid3d Boundary StaticConformal" ActiveThorns = "SymBase InitBase" ActiveThorns = "IOUtil" ActiveThorns = "Carpet CarpetLib CarpetRegrid2" driver::ghost_size = 1 CoordBase::boundary_size_x_lower = 1 CoordBase::boundary_size_y_lower = 1 CoordBase::boundary_size_z_lower = 1 CoordBase::boundary_size_x_upper = 1 CoordBase::boundary_size_y_upper = 1 CoordBase::boundary_size_z_upper = 1 CartGrid3D::type = "coordbase" CoordBase::domainsize = "minmax" CoordBase::xmin = -32.0 CoordBase::ymin = -32.0 CoordBase::zmin = -32.0 CoordBase::xmax = 32.0 CoordBase::ymax = 32.0 CoordBase::zmax = 32.0 CoordBase::dx = 8.0 CoordBase::dy = 8.0 CoordBase::dz = 8.0 cactus::cctk_itlast = 1 Cactus::terminate = "iteration" Carpet::domain_from_coordbase = "yes" Carpet::use_buffer_zones = "yes" Carpet::init_fill_timelevels = "yes" CarpetLib::poison_new_memory = "yes" CarpetLib::poison_value = 114 Carpet::poison_new_timelevels = "yes" Carpet::max_refinement_levels = 2 CarpetRegrid2::regrid_every = 1 CarpetRegrid2::num_centres = 1 CarpetRegrid2::num_levels_1 = 2 CarpetRegrid2::radius_1[1] =16.0 time::dtfac = 0.25 MoL::ODE_Method = "rk4" MoL::MoL_Intermediate_Steps = 4 MoL::MoL_Num_Scratch_Levels = 1 ActiveThorns = EvolveArray ``` I can get a error similar to what is being described in the ticket. My guess is that this branch rhaas/poisonarray \([https://bitbucket.org/eschnett/carpet/branch/rhaas/poisonarray](https://bitbucket.org/eschnett/carpet/branch/rhaas/poisonarray)\) will fix things since it applies the same logic as is used otherwhere in PreSync.cc to [Poison.cc](http://Poison.cc) when it come to handling non-grid functions. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2534/evolution-of-grid…

1 0

#2534: Evolution of grid arrays with Mol no longer works
by Roland Haas 06 Aug '21

06 Aug '21

#2534: Evolution of grid arrays with Mol no longer works Reporter: Status: new Milestone: Version: development version Type: bug Priority: major Component: Carpet Comment (by Roland Haas): I cannot reproduce this with the provided thorn and parfile. The parfile seems to be for a different setup. Eg the thorn name differs, the thorn in the parfile has parameters while the thorn in the tarball does not, the parfile contains `@FOO@` placeholders, the parfile has no mesh refinement or MoL active but the ticket description mentions both being required. I have a guess what is going on, but without a reproducer will not be able to make headway fixing this. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2534/evolution-of-grid…

1 0

#2533: "ActiveThorns" not accepted in parameter file
by Roland Haas 06 Aug '21

06 Aug '21

#2533: "ActiveThorns" not accepted in parameter file Reporter: Erik Schnetter Status: open Milestone: Version: development version Type: bug Priority: major Component: Comment (by Roland Haas): Please apply. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2533/activethorns-not-…

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
13
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac August 2021