Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1141: Carpet shouldn't stop the "CCTK_ total time" timer at Shutdown
by Einstein Toolkit 31 Oct '12

31 Oct '12

#1141: Carpet shouldn't stop the "CCTK_ total time" timer at Shutdown --------------------+------------------------------------------------------- Reporter: knarf | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- Currently, Carpet stops the "CTTK total time" timer in Shutdown. This now emits a warning since the flesh tries to stop this timer as well. Also, the comment close to this code is wrong and needs to be changed/removed: Carpet/src/Shutdown.c:59 {{{ // Stop all timers before shutdown, since timers may rely on data // structures which are destroyed during shutdown int const ierr = CCTK_TimerStop ("CCTK total time"); }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1141> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 15

[Einstein Toolkit] #1151: Terminology for nodes, processes and cores is confusing
by Einstein Toolkit 30 Oct '12

30 Oct '12

#1151: Terminology for nodes, processes and cores is confusing ------------------------+--------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- SimFactory's terminology for nodes, processes and cores (http://simfactory.org/info/documentation/userguide/processterminology.html) is confusing. We should come up with a new scheme which is more consistent and intuitive. If we use new names for the options and variables, we can support both the old and new schemes at the same time, and provide a simple mapping from one to the other. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1151> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1002: MoL multirate lacks documentation
by Einstein Toolkit 30 Oct '12

30 Oct '12

#1002: MoL multirate lacks documentation ---------------------------+------------------------------------------------ Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: MoL Multirate | ---------------------------+------------------------------------------------ #839 did not provide updates to MoL's documentation so that the only way to learn how to use it is to reverse engineer what GRHydro does. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1002> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #878: Tests using Exact should use EinsteinExact
by Einstein Toolkit 30 Oct '12

30 Oct '12

#878: Tests using Exact should use EinsteinExact -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The EinsteinExact arrangement provides initial data accurate to roundoff, in contrast to the Exact thorn which does not. The initial data from the Exact thorn is also highly sensitive to roundoff level differences. Hence, tests should be converted to using the EinsteinExact arrangement where possible. In some cases, EinsteinExact will not support the required metrics or parameters. These could either be added to EinsteinExact, or the Exact thorn could continue to be used. Milestone: ET_2012_11. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/878> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1149: Add timers for Carpet modes
by Einstein Toolkit 29 Oct '12

29 Oct '12

#1149: Add timers for Carpet modes -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- It is currently not possible to determine from the timer output how much time is spent on each refinement level, or in each mode (meta, global, level, singlemap, local). The branch http://git.carpetcode.org/carpet.git/shortlog/refs/heads/ianhinder/modetime… adds a timer tree which times the time spent in each mode, on each refinement level, and on each map (if desired). This tree is output to standard output after the Evolve timer tree if the Evolve timer tree is being output. Two new parameters are added to control whether to time maps and local mode; these default to "no". Example output with the default parameters {{{ ----------------------- Percent t/secs Timer ----------------------- 100.0% 20.4 meta mode 99.7% 20.4 |_global mode 11.9% 2.4 | |_level(0) 9.4% 1.9 | |_level(1) 15.6% 3.2 | |_level(2) 23.1% 4.7 | |_level(3) 28.6% 5.8 | |_level(4) 10.8% 2.2 | |_untimed }}} If the maps and local mode are enabled, the output can look like this: {{{ ----------------------- Percent t/secs Timer ----------------------- 100.0% 38.1 meta mode 94.9% 36.1 |_global mode 11.9% 4.5 | |_level(0) 2.0% 0.8 | | |_map(0) 1.6% 0.6 | | | |_local 9.8% 3.7 | | |_untimed 5.0% 1.9 | |_level(1) 3.4% 1.3 | | |_map(0) 3.1% 1.2 | | | |_local 1.6% 0.6 | | |_untimed 8.1% 3.1 | |_level(2) 5.0% 1.9 | | |_map(0) 4.7% 1.8 | | | |_local 3.0% 1.2 | | |_untimed 11.0% 4.2 | |_level(3) 7.0% 2.7 | | |_map(0) 6.5% 2.5 | | | |_local 4.0% 1.5 | | |_untimed 15.5% 5.9 | |_level(4) 10.8% 4.1 | | |_map(0) 10.3% 3.9 | | | |_local 4.6% 1.7 | | |_untimed 43.3% 16.5 | |_untimed 5.1% 2.0 | untimed }}} OK to merge? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1149> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1154: Timers which do not exist on certain processes should not be included in reductions
by Einstein Toolkit 29 Oct '12

29 Oct '12

#1154: Timers which do not exist on certain processes should not be included in reductions -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: TimerReport | -----------------------------------+---------------------------------------- The thorn TimerReport reduces Cactus timers across processes to provide minimum, maximum, total, average values etc. However, if a timer does not exist on some of the processes, TimerReport will fail. The solution so far has been to ensure that all timers exist on all processes. However, since the timed value will be 0 on some processes, this makes the minimum and average reductions of limited usefulness. I propose that TimerReport be modified to allow different timers on different processes, and to only include those that actually exist in the reductions. This will make the timing of different multipatch maps useful (see #1149). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1154> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1155: Add "-n" option to Simfactory
by Einstein Toolkit 29 Oct '12

29 Oct '12

#1155: Add "-n" option to Simfactory -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- Add a "do-nothing" option to Simfactory. It would parse its input, say what it would do, but not actually do it. Frank says: "With this in mind it might be also good to have a 'noop' option for submit which would print, in nice long language, what it would do, for example (please improve): "'submitting job on 16 nodes using 32 MPI processes with 4 threads per process (2 processes with a total of 8 threads per node).' "I would totally use this before a lot of my job submissions. :)" -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1155> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1132: CarpetEvolutionMask: Take horizon into account
by Einstein Toolkit 29 Oct '12

29 Oct '12

#1132: CarpetEvolutionMask: Take horizon into account -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1132> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1077: evaluate steered value as formula in AEIThorns::Trigger
by Einstein Toolkit 29 Oct '12

29 Oct '12

#1077: evaluate steered value as formula in AEIThorns::Trigger -------------------------------+-------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: AEIThorn::Trigger | -------------------------------+-------------------------------------------- the attached patch adds functionality to Trigger to use a formula (same syntax as parameters in parameter files) instead of a constant value for its steered values. It supports both grid scalars and parameters as variables. I also include an updated test suite to test the functionality. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1077> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1114: AHFinderDirect fails if one increases the number of horizons after recovery
by Einstein Toolkit 29 Oct '12

29 Oct '12

#1114: AHFinderDirect fails if one increases the number of horizons after recovery -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: AHFinderDirect | -----------------------------------+---------------------------------------- eg. modifying the AHFinderDirect test recoverML like so: {{{#!diff Index: test/recoverML.par =================================================================== --- test/recoverML.par (revision 1568) +++ test/recoverML.par (working copy) @@ -123,7 +123,7 @@ AHFinderDirect::geometry_interpolator_name = "Hermite polynomial interpolation" AHFinderDirect::geometry_interpolator_pars = "order=3" -AHFinderDirect::N_horizons = 1 +AHFinderDirect::N_horizons = 2 AHFinderDirect::origin_x[1] = 0.5 AHFinderDirect::origin_y[1] = 0.7 AHFinderDirect::origin_z[1] = 0.0 @@ -133,3 +133,13 @@ AHFinderDirect::initial_guess__coord_sphere__y_center[1] = 0.3 AHFinderDirect::initial_guess__coord_sphere__z_center[1] = 0.0 AHFinderDirect::initial_guess__coord_sphere__radius[1] = 2.0 + +AHFinderDirect::origin_x[2] = 0.5 +AHFinderDirect::origin_y[2] = 0.7 +AHFinderDirect::origin_z[2] = 0.0 + +AHFinderDirect::initial_guess_method[2] = "coordinate sphere" +AHFinderDirect::initial_guess__coord_sphere__x_center[2] = -0.2 +AHFinderDirect::initial_guess__coord_sphere__y_center[2] = 0.3 +AHFinderDirect::initial_guess__coord_sphere__z_center[2] = 0.0 +AHFinderDirect::initial_guess__coord_sphere__radius[2] = 2.0 }}} causes it to fail with {{{ WARNING level -1 in thorn AHFinderDirect processor 0 host horizon.tapir.caltech.edu (line 310 of /mnt/data/rhaas/postdoc/gr/Zelmani/arrangements/EinsteinAnalysis/AHFinderDirect/src/driver/initial_guess.cc): -> setup_coord_ellipsoid(): expected exactly one r>0 solution to quadratic, got 0 or 2! +z patch (irho,isigma)=(-9,-9) ==> (rho,sigma)=(-0.785398,-0.785398) direction cosines (xcos,ycos,zcos)=(-0.57735,-0.57735,0.57735) r_plus=-nan r_minus=-nan ==> this probably means the initial guess surface doesn't contain the local origin point, or more generally that the initial guess surface isn't a Strahlkoerper ("star-shaped region") with respect to the local origin point [1mWARNING level -1 in thorn AHFinderDirect processor 0 host horizon.tapir.caltech.edu (line 310 of /mnt/data/rhaas/postdoc/gr/Zelmani/arrangements/EinsteinAnalysis/AHFinderDirect/src/driver/initial_guess.cc): ->[0m setup_coord_ellipsoid(): expected exactly one r>0 solution to quadratic, got 0 or 2! +z patch (irho,isigma)=(-9,-9) ==> (rho,sigma)=(-0.785398,-0.785398) direction cosines (xcos,ycos,zcos)=(-0.57735,-0.57735,0.57735) r_plus=-nan r_minus=-nan ==> this probably means the initial guess surface doesn't contain the local origin point, or more generally that the initial guess surface isn't a Strahlkoerper ("star-shaped region") with respect to the local origin point }}} (this might require poisoning to become obvious). The reason is that AHFinderDirect attempts to initialize its internal variables from checkpointed data (in particular the patch system origin). Since the new horizons did not exist at the time of checkpoint (and the whole variable is missing) the recovery routine in CarpetIOHDF5 reads in no data which leaves the Cactus group uninitialized which in turn leads to invalid values in AHFinderDirect's internal data structures. The attached fix circumvents this by having AHFinderDirect initialize the Cactus group from its internal data structures (which it constructed from the parameters) at BaseGrid. This way, any newly created horizon will retain the values from the parameter file, but existing ones have their values overwritten. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1114> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac