Trac August 2021

trac@lists.einsteintoolkit.org

1 participants
125 discussions

#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

#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 Cactus link line in make.configuration looks like this right now: ``` $(LD) $(CREATEEXE)$(OPTIONSEP)"$(call TRANSFORM_DIRS,$@)" $(CPPFLAGS) $(CXXFLAGS) $(LDFLAGS) $(EXTRAFLAGS) "$(call TRANSFORM_DIRS,$(TOP)/datestamp.o)" $(BEGIN_WHOLE_ARCHIVE_FLAGS) $(CACTUSLIBLINKLINE) $(END_WHOLE_ARCHIVE_FLAGS) $(GENERAL_LIBRARIES) ``` ie it passed `$(CPPFLAGS)` and `$(CXXFLAGS)` to `$(LD)`. While we do normally set `LD` to the same as `CXX` this is not always correct, eg if one would like to use `g++` for C\+\+ files but link with `nvcc`. Neither one of these options is required or should be there since `$(LD)` does not compile anything at all. Any subset of options from `$(CPPFLAGS)` or `$(CXXFLAGS)` that may be needed $eg `-fopenmp` should be set in `$(LDFLAGS)`$. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2553/cactus-link-comma…

1 0

#2549: inlcude FLRWSolver in ET
by Pierre Mourier 11 Aug '21

11 Aug '21

#2549: inlcude FLRWSolver in ET Reporter: Roland Haas Status: new Milestone: Version: development version Type: enhancement Priority: major Component: Comment (by Pierre Mourier): Hi, I am a postdoc at the Max Planck Institute for gravitational Physics in Hannover. Before this I did my PhD on inhomogeneous cosmology and the impact of structure formation in the late Universe on the large-scale dynamics, and this is still part of my research interests. As such, I am currently using the ET and the FLRWSolver thorn for some simple cosmological setups and planning to use them in the near future for more involved cosmological simulations. I think that it would be very useful for such applications of the ET to have it include FLRWSolver in future releases. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2549/inlcude-flrwsolve…

1 0

#2549: inlcude FLRWSolver in ET
by Michele Grasso 10 Aug '21

10 Aug '21

#2549: inlcude FLRWSolver in ET Reporter: Roland Haas Status: new Milestone: Version: development version Type: enhancement Priority: major Component: Comment (by Michele Grasso): Hi, I am Michele, a PhD student at the Center for Theoretical Physics in Warsaw and ET user. I believe that having the FLRWSolver thorn included in the ET would be extremely useful for all the users interested in cosmology. The thorn has already a place among the main codes for general-relativistic simulations of cosmological structure formation $see arXiv:2003.08014$. I've used the FLRWSolver in my research on relativistic light propagation and observables extrapolation, see arXiv:2107.06306, and I plan to use the thorn in my future works. -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2549/inlcude-flrwsolve…

1 0

#2549: inlcude FLRWSolver in ET
by Theo Anton 10 Aug '21

10 Aug '21

#2549: inlcude FLRWSolver in ET Reporter: Roland Haas Status: new Milestone: Version: development version Type: enhancement Priority: major Component: Comment (by Theo Anton): Hi - I’m planning to use FLRWSolver in my research $I’m a PhD student at Queen Mary University of London working on testing GR/modified gravity in cosmology$, so having FLRWSolver included in the ET would be really useful to me -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2549/inlcude-flrwsolve…

1 0

#2552: VERSION option in configuration.ccl is overly restrictive in allowed characters
by Roland Haas 09 Aug '21

09 Aug '21

#2552: VERSION option in configuration.ccl is overly restrictive in allowed characters Reporter: Roland Haas Status: new Milestone: Version: development version Type: bug Priority: minor Component: Cactus Changes (by Roland Haas): assignee: Steven R. Brandt (was ) responsible: [] (was ) component: Cactus (was ) -- Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2552/version-option-in…

1 0

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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac August 2021