Trac February 2014

trac@lists.einsteintoolkit.org

1 participants
141 discussions

[Einstein Toolkit] #1435: count evolved variables automatically in Refluxing
by Einstein Toolkit 12 Feb '14

12 Feb '14

#1435: count evolved variables automatically in Refluxing -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: Refluxing | -----------------------------------+---------------------------------------- the attached patch reliefs the user from some variable counting (there is still some) when using Refluxing and will automatically find out which variables are evolved with MoL and which use a non-MoL time integration scheme. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1435> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1535: Outflow: add option for computing the flow of unbounded matter
by Einstein Toolkit 12 Feb '14

12 Feb '14

#1535: Outflow: add option for computing the flow of unbounded matter -----------------------------------+---------------------------------------- Reporter: dradice@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- I created a small patch for the Outflow thorn to allow one to optionally compute the flux of matter having "eninf := - u_t - 1" larger than a given threshold, so as to measure the amount of "unbound" (*) matter ejected from the system. ----- (*) Obviously this really makes sense only for a stationary spacetime -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1535> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1438: do not require --thornlist for build --reconfig
by Einstein Toolkit 12 Feb '14

12 Feb '14

#1438: do not require --thornlist for build --reconfig -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Keywords: | -------------------------+-------------------------------------------------- The attached patch removes the requirement to provide a new thornlist when doing a sim build --reconfig . Since the typical reason (at least this is the only case I encountered this) for this is that the Cactus config changed (and the Cactus build system wants a make sim-reconfig) one usually does not want to change the thornlist at all. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1438> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1465: Boost doesn't honor parallel build options
by Einstein Toolkit 12 Feb '14

12 Feb '14

#1465: Boost doesn't honor parallel build options -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- ExternalLibraries/Boost doesn't honor parallel build options. This is because it doesn't use 'make' to build, but a tool called 'b2', which isn't using 'make's environment variables, nor is it capable to interact with the jobserver make provides. Manually parsing MAKEFLAGS inside the configure script of the thorn also doesn't work, as this doesn't contain the requested number of jobs, but only the fact that a parallel build was requested and a pointer to the jobserver. Manually interacting with this job server might be possible for gnu make, but is probably messy and highly likely not portable. However, building a huge package like Boost in parallel is something we have to achieve. On my workstation it reduces the time used for building Boost alone from about 500s to 60s. The only alternative that is easy enough to implement that I can see right now is to make it possible to pass a number of processes used for building to Cactus (in addition to passing it to make), and Boost using this variable for the parallel build. Simfactory should then also pass this to Cactus. One downside of this would be that if multiple libraries were to be built in parallel you might end up using almost twice as many jobs than specified. On the other hand, this doesn't seem to be the case right now and even if using twice as many might be better than many times too few. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1465> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1521: Piraha smart_ptr can't handle self assignment
by Einstein Toolkit 12 Feb '14

12 Feb '14

#1521: Piraha smart_ptr can't handle self assignment ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- An assignment of the form {{{ void foo(smart_ptr<T> x) { x = x; } }}} will not work, since operator= assumes that LHS and RHS are different objects. The usual remedy is to add an if statement, doing nothing for self assignment. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1521> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1314: increase number of triggers in AEIThorns trigger
by Einstein Toolkit 11 Feb '14

11 Feb '14

#1314: increase number of triggers in AEIThorns trigger -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: Trigger | -----------------------------------+---------------------------------------- currently the max is 10. I find myself needing more (15 to be precise). Can we increase this number to say 39 (or some other largish non-typical number) or are that many parameters too expensive to support? Similarly (but more complicated) it would be useful to be able to steer more than one parameter/grid scalar when a trigger triggers. The current way of specifying targets is unfortunately not well suited for this. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1314> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1540: Use clang for automated testing
by Einstein Toolkit 11 Feb '14

11 Feb '14

#1540: Use clang for automated testing -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: development version Keywords: | -------------------------+-------------------------------------------------- We should use Clang for automated testing, maybe in addition to GCC. Clang is known for having better diagnostics than GCC. Point in case: Clang discovered the C/C++ incompatibility for complex numbers that GCC ignored. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1540> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1534: Bug in complex numbers
by Einstein Toolkit 11 Feb '14

11 Feb '14

#1534: Bug in complex numbers ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: critical | Milestone: Component: Cactus | Version: development version Keywords: | ----------------------+----------------------------------------------------- I hear that C++ "complex<double>" and C "complex double" may have different ABI properties. This means that we need to correct Cactus's complex number implementation, probably using C's "complex double". I hear that this makes Cactus complex numbers unusable on 32-bit Intel systems (untested). See <http://llvm.org/bugs/show_bug.cgi?id=18756> for details. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1534> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #1539: Simfactory: update loewe entries
by Einstein Toolkit 10 Feb '14

10 Feb '14

#1539: Simfactory: update loewe entries -------------------------+-------------------------------------------------- Reporter: bmundim | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: development version Keywords: loewe | -------------------------+-------------------------------------------------- The attached patch applies cleanly both to trunk and Noether release. * It updates the loewe machine database entries. * Avoid Boost and MPI compilation. * Fix chaining jobs in its submit script. Is it ok to apply to both repos? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1539> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1512: LoopControl slows down with time when exloring new tilings
by Einstein Toolkit 05 Feb '14

05 Feb '14

#1512: LoopControl slows down with time when exloring new tilings -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: development version Keywords: LoopControl | -------------------------+-------------------------------------------------- the attached parfile does nothing but apply the periodic boundary condition over and over again. The run slows down with time, and spends more and more time in Slab's apply routine (Periodic just uses lots of calls to Slab). Digging further this caused by LoopControl and in particular setting {{{ LoopControl::settle_after_iteration = 0 }}} restores the expected behaviour, namely that the runtime in Pariodic/apply increases linearly with the number of timesteps rather than superlinearly. I blind guess for the culprit is the std::map inside of loopcontrol. I have done no further digging into the code though. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1512> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac February 2014