Trac October 2012

trac@lists.einsteintoolkit.org

1 participants
189 discussions

[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

[Einstein Toolkit] #1102: when using the file reader, mark variables not requested fro reading as fully read
by Einstein Toolkit 29 Oct '12

29 Oct '12

#1102: when using the file reader, mark variables not requested fro reading as fully read --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- right now this causes many level 2 warnings about looking in another file for this variable. The run eventually succeeds since CarpetIOHDF5 silently continues if it is unable to read anything at all for a given variable (ie. it only aborts if a variable is read only partially but not if it is not read a all since it is missing from the fileset). The attached patch marks these variables as being fully read the same way the ignored variables are handled and adds some further checks if the reader is called from the FilerReader rather than from recovery. The do_inVars logic (explained in the source) is to possibly read a variable if either do_inVars == NULL (corresponds to "all" variables) or do_inVars[vindex] != 0 (which can be positive or negative). As it is right now I think the later checks that end in "continue" are now superfluous. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1102> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1069: Create status page for services
by Einstein Toolkit 29 Oct '12

29 Oct '12

#1069: Create status page for services -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Services (web server, repositories ect) might go down unnoticed or might be available only from certain (local) sites. It would be nice to have some kind of monitor regularly checking availability of Cactus/ET services and reports if something doesn't work as expected. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1069> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1147: Link all thorn source files
by Einstein Toolkit 28 Oct '12

28 Oct '12

#1147: Link all thorn source files -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- The attached patch adds configuration options allowing people to ensure that all thorn source files make it into the executable. Among other things, this ensures that each routine has a unique name. For example, on systems using GNU ld, these options enable this behaviour: {{{ BEGIN_WHOLE_ARCHIVE = -Wl,--whole-archive END_WHOLE_ARCHIVE = -Wl,--no-whole-archive }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1147> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1131: Add Fortran wrappers for isnan
by Einstein Toolkit 28 Oct '12

28 Oct '12

#1131: Add Fortran wrappers for isnan -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Add Fortran wrappers for isnan and friends -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1131> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #361: delta_time when setting up ID with explicit time dependence
by Einstein Toolkit 28 Oct '12

28 Oct '12

#361: delta_time when setting up ID with explicit time dependence ------------------------------------------+--------------------------------- Reporter: eloisa.bentivegna@… | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: ET_2010_11 Keywords: | ------------------------------------------+--------------------------------- In CallInitial, delta_time is used to calculate the time corresponding to the different timelevels (line 399 of Carpet/src/Initialise.cc). At this stage, though, delta_time is always equal to 1, leading to potentially very separated initial-data slices when using init_each_timelevel and an initial-data thorn that uses cctk_time explicitly. Should cctkGH->cctk_delta_time be used here instead? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/361> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 19

[Einstein Toolkit] #1008: Link error when building a configuration containing only MPI thorn
by Einstein Toolkit 25 Oct '12

25 Oct '12

#1008: Link error when building a configuration containing only MPI thorn --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- If I create a thornlist containing just ExternalLibraries/MPI the configuration will compile but it won't link. The linker errors indicate that the "Cactus" virtual thorn is using MPI symbols which are not available. The mpi library is not on the linker command line, nor in LIBS. LIBS is set from MPI_LIBS in make.link, but MPI_LIBS is empty. MPI_LIBS is picked up from the MPI configure.sh script, and it is inserted into bindings/Configuration/Capabilities/make.MPI.defn. This is picked up by bindings/Configuration/Thorns/make.Cactus.defn, but I don't think that this file is used by anything. If I create a new empty thorn which uses the MPI capability, the executable is linked successfully. I think that nothing is loading the make.Cactus.defn definitions for the Cactus virtual thorn. This subtle bug might have other effects so it should probably be fixed. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1008> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #323: GetComponents overwrites thorn list
by Einstein Toolkit 25 Oct '12

25 Oct '12

#323: GetComponents overwrites thorn list ---------------------------+------------------------------------------------ Reporter: eschnett | Owner: eric9 Type: defect | Status: new Priority: critical | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ I specified a thorn list located in the main Cactus directory. GetComponents overwrote this thorn list with its own thorn list (the one it generates automatically). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/323> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 18

[Einstein Toolkit] #1145: EinsteinExact schedules routine at ANALYSIS instead of PRESTEP
by Einstein Toolkit 25 Oct '12

25 Oct '12

#1145: EinsteinExact schedules routine at ANALYSIS instead of PRESTEP -----------------------------------+---------------------------------------- Reporter: diener | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: EinsteinExact | -----------------------------------+---------------------------------------- When evolution_method is set to one of EinsteinExact's supported metrics, the routine to set the data is scheduled at ANALYSIS. To make EinsteinExact consistent with the behavior of thorn Exact as well as making it consistent with common sense it should be scheduled at PRESTEP. The attached patch implements this. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1145> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

← Newer
1
...
11
12
13
14
15
16
17
18
19
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac October 2012