Trac

trac@lists.einsteintoolkit.org

8708 discussions

#2553: Cactus' link command uses CPPFLAGS and CXXFLAGS
by Erik Schnetter 11 Aug '21

11 Aug '21

#2553: Cactus' link command uses CPPFLAGS and CXXFLAGS Reporter: Roland Haas Status: open Milestone: Version: development version Type: bug Priority: minor Component: Cactus Comment (by Erik Schnetter): We can certainly change the way Cactus handles things. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2553/cactus-link-comma…

1 0

#2553: Cactus' link command uses CPPFLAGS and CXXFLAGS
by Roland Haas 11 Aug '21

11 Aug '21

#2553: Cactus' link command uses CPPFLAGS and CXXFLAGS Reporter: Roland Haas Status: open Milestone: Version: development version Type: bug Priority: minor Component: Cactus Comment (by Roland Haas): Apparently using g\+\+ to link CUDA code is advanced use $or at least was in 2014$. [https://developer.nvidia.com/blog/separate-compilation-linking-cuda-device-… It requires that one pre-links the object files to extract CUDA device code into a form that g\+\+ understands. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2553/cactus-link-comma…

1 0

#2551: include RePriMand in the ET
by Roland Haas 11 Aug '21

11 Aug '21

#2551: include RePriMand in the ET Reporter: Roland Haas Status: new Milestone: Version: development version Type: enhancement Priority: major Component: Comment (by Roland Haas): Also see #2414 for a similar framework. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2551/include-reprimand…

1 0

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

11 Aug '21

#2534: Evolution of grid arrays with Mol no longer works Reporter: Status: resolved Milestone: Version: development version Type: bug Priority: major Component: Carpet Changes (by Roland Haas): status: resolved (was new) -- 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 11 Aug '21

11 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): @{557058:d079f9c2-ad27-47b2-bf4b-ecc6bbe288b0} confirmed $private email$ that the branch rhaas/poisonarray seems to work. Applied as git hash [9d0eaa4c](https://bitbucket.org/eschnett/carpet/commits/9d0eaa4c2d4f617f50e… "Carpet: handle marking grid-arrays invalid correctly" of [carpet](https://bitbucket.org/eschnett/carpet) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2534/evolution-of-grid…

1 0

#2553: Cactus' link command uses CPPFLAGS and CXXFLAGS
by Roland Haas 11 Aug '21

11 Aug '21

#2553: Cactus' link command uses CPPFLAGS and CXXFLAGS Reporter: Roland Haas Status: open Milestone: Version: development version Type: bug Priority: minor Component: Cactus Changes (by Roland Haas): title: Cactus' link command uses CPPFLAGS and CXXFLAGS (was Cactus' link command used CPPFLAGS and CXXFLAGS) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2553/cactus-link-comma…

1 0

#2553: Cactus' link command used CPPFLAGS and CXXFLAGS
by Roland Haas 11 Aug '21

11 Aug '21

#2553: Cactus' link command used CPPFLAGS and CXXFLAGS Reporter: Roland Haas Status: open Milestone: Version: development version Type: bug Priority: minor Component: Cactus Changes (by Roland Haas): status: open (was new) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2553/cactus-link-comma…

1 0

#2553: Cactus' link command used CPPFLAGS and CXXFLAGS
by Roland Haas 11 Aug '21

11 Aug '21

#2553: Cactus' link command used CPPFLAGS and CXXFLAGS Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: minor Component: Cactus Comment (by Roland Haas): I see. I had not thought of link time optimizations. To me it seems that passing CCPFLAGS to the compiler call makes since we actually call the compiler driver which internally first preprocesses the code $with cpp$ and then calls the actual compiler $cc1$. This is different from say FPP where Cactus explicitly calls the preprocessor and then passes the output file to Fortran compiler $though by now it seems that many Fortran compiler drivers can also call the C preprocessor internally$. Right not the linking stage in Cactus is really just linking object files and library files into the executable and does not include any compilation so the compiler and preprocessor options are $except for LTO$ not needed. The cases where this matters are probably limited and I would have though that one should be able to use g\+\+ to link CUDA code, but at least my initial tries failed until I used nvcc to link $otherwise it would report undefined symbols for some CUDA using code. Not for libcuda or libcudart though, which I already included in LIBS$. I will try and see if the build system / option lists would support having `LDFLAGS` default to `$(CPPFLAGS) $(CXXFLAGS)` so that one can override its value completely via an option list. Currently it is impossible to remove `$(CXXFLAGS)` from the linker command line. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2553/cactus-link-comma…

1 0

#2554: init_3_timelevels produces nans on past timelevels of the initial slice
by Yosef Zlochower 11 Aug '21

11 Aug '21

#2554: init_3_timelevels produces nans on past timelevels of the initial slice Reporter: Yosef Zlochower Status: new Milestone: Version: ET_2021_05 Type: bug Priority: minor Component: Carpet I have been running into an issue where I when I interpolate an evolved function I get nans even though there are no nans on the gridfunction itself. The nans appear to arise when the past timelevels $at iteration 0$ are initialized by init\_3\_timelevels and occur near the buffer regions. As the evolution proceeds, these bad past timelevels are overwritten with seemingly good data. The attached thorn demonstrates the issue by evolving the trivial system dt\_f = 1 In visit you can see nans on the “\_p\_p” timelevel at iteration 1 $not iteration 0??$. The nans go away later in the evolution. attachment: init3.par (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2…) attachment: TestInit3.tar.gz (https://api.bitbucket.org/2.0/repositories/einsteintoolkit/tickets/issues/2…) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2554/init_3_timelevels…

1 0

#2553: Cactus' link command used CPPFLAGS and CXXFLAGS
by Erik Schnetter 11 Aug '21

11 Aug '21

#2553: Cactus' link command used CPPFLAGS and CXXFLAGS Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: minor Component: Cactus Comment (by Erik Schnetter): There are some optimizations that recompile code at link time. I don’t think these were ever successfully used in Cactus, nor whether compilers offer them any more. $The current set of `-lto` optimizations might store the compiler flags internally.$ So far, the Cactus policy has been that each stage $preprocessor, compiler, linker$ gets passed all the flags of the previous stages. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2553/cactus-link-comma…

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac