Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1405: TOVSolver: do not set conservatives, remove TOV_Atmosphere
by Einstein Toolkit 19 Jul '13

19 Jul '13

#1405: TOVSolver: do not set conservatives, remove TOV_Atmosphere -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: TOVSolver | -----------------------------------+---------------------------------------- the attached two patches remove TOV_Atmosphere[] from the code and do not set the conservative variables. Instead TOVSolver relies on GRHydro to set the conservatives in InitialPrim2Con and to enforce atmosphere in initialatmospherereset. This also fixes any asymmetry in atmosphere handling between the stars. Most tests pass without change (since GRHydro ran anyway), the failing one being the test_two_av TOVSolver test which the second one regenerates. Differences are small but above threshold in the average case. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1405> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1404: GRHydro InitialAtmosphereReset in INITIAL only scheduled for non-MHD call
by Einstein Toolkit 11 Jul '13

11 Jul '13

#1404: GRHydro InitialAtmosphereReset in INITIAL only scheduled for non-MHD call -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: GRHydro | -----------------------------------+---------------------------------------- the schedule item for InitialAtmoshpereReset in INITIAL (but not PostInitial) unconditionally schedules GRHydro_InitialAtmosphereReset instead of selecting between GRHydro_InitialAtmosphereReset, GRHydro_AtmosphereResetM and GRHydro_AtmosphereResetAM depending on parameter options. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1404> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1345: Cactus shouldn't mess with some flags after they have been setup.
by Einstein Toolkit 09 Jul '13

09 Jul '13

#1345: Cactus shouldn't mess with some flags after they have been setup. --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2013_11 Component: Other | Version: development version Keywords: | --------------------+------------------------------------------------------- Currently Cactus sets up flags like CPPFLAGS or CFLAGS by adding e.g. CPP_OPENMP_FLAGS. However, later it overwrites these again by their original value in sbin/ProcessConfiguration.pl (search for FIXME). The attached patch implements what the 'FIXME' suggests - accepting the drawbacks that are mentioned there: that configuration settings not originating from a thorn might not be forwarded from e.g., a .cactus/config file. MPI was one of these, but this is now handled differently anyway. With this patch, we would need to be aware of these and might need to add them to @allowed_opts in the future. Without the patch however, compilation might fail for perfectly valid setups. One of these is when using openmp, setting all the corresponding *_OPENMP_FLAGS, but not setting CPPFLAGS (only CPP_OPENMP_FLAGS). In this case ProcessConfiguration.pl will set CFLAGS to the version in the config file (*without* the -openmp), but it will leave CPPFLAGS to the version *with* -openmp. This later leads to a linker error in external libraries, since compilation there uses CPPFLAGS (with openmp), but the linker doesn't (It correctly uses CFLAGS, but this doesn't have openmp flags here). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1345> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #1403: adapt trigger to tovsolver rev 137
by Einstein Toolkit 08 Jul '13

08 Jul '13

#1403: adapt trigger to tovsolver rev 137 -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: trigger | -----------------------------------+---------------------------------------- the attached patch adapts the test in trigger to changes in tovsolver. Whoever reviews it, please also apply since I have no write access to trigger. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1403> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1231: "How did I get here" error in test suite mechanism
by Einstein Toolkit 08 Jul '13

08 Jul '13

#1231: "How did I get here" error in test suite mechanism ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- I see several error such as the one below reported by Cactus. The error is the line that begins with "ERROR". Test Hydro_InitExcision: x_flip_pugh_eno "1D shocktube, RK2, Marquina, ENO, Ideal Gas, x-Excision" Issuing ln -fns . output-0000-active && mkdir -p SIMFACTORY && TESTSUITE_PARFILE=/scratch/jenkins/jobs/EinsteinToolkit/simulations/EinsteinToolkit_69189d49fa86945d70ba137f840efe1301b13c71_2/output-0000/arrangements/EinsteinInitialData/Hydro_InitExcision/test/x_flip_pugh_eno.par /scratch/jenkins/jobs/EinsteinToolkit/simulations/EinsteinToolkit_69189d49fa86945d70ba137f840efe1301b13c71_2/output-0000/SIMFACTORY/RunScript ERROR: How did I get here, maximum difference is 9.99999388850981e-12 and maximum value is 0 for h.t0.ah2.gp BH_diagnostics.ah1.gp: differences below tolerance on 1 lines BH_diagnostics.ah2.gp: differences below tolerance on 1 lines h.t0.ah1.gp: differences below tolerance on 704 lines h.t0.ah2.gp: differences below tolerance on 731 lines sf_area[0].xg: differences below tolerance on 1 lines sf_min_radius[0].xg: differences below tolerance on 1 lines sf_radius[0]_2D.asc: differences below tolerance on 308 lines sf_radius[1]_2D.asc: differences below tolerance on 23 lines Success: 55 files compared, 8 differ in the last digits -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1231> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1192: Speed up Hydro_InitExcision test cases
by Einstein Toolkit 08 Jul '13

08 Jul '13

#1192: Speed up Hydro_InitExcision test cases -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Hydro_InitExcision sets up an excision mask for hydrodynamics evolution. It is active at initial and poststep (and postregrid), and its logic depends only on parameters, not on the simulation state. Its test cases take a very long time to run: (1) Running this for 100 iterations with PUGH is overkill. 1 iteration suffices, testing both initial and poststep. (2) The excision mask is not even output! Instead, only the indirect results on the hydro variables are tested. (3) All test cases use PUGH, so Carpet's postregrid bin is not tested. (4) Each test exists three times, for different reconstruction methods. The reconstruction methods do not enter into this thorn's logic. I conclude: The existing tests confirm that this thorn has the right functionality. They are therefore important. However, they should not be in the Cactus test suite. We want regression tests in the Cactus test cases, and this could be achieved about 100x faster (fewer iterations, fewer test cases). Additionally, there should be Carpet tests, and the excision mask should be output. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1192> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1402: adapt admmass test to rev 137 of tovsolver
by Einstein Toolkit 08 Jul '13

08 Jul '13

#1402: adapt admmass test to rev 137 of tovsolver -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: admmass | -----------------------------------+---------------------------------------- the attached patch makes the test pass (only change on parameter name), I cannot commit this myself I think (thorn is in AEIThorns). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1402> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #456: Ensure functions are not defined twice
by Einstein Toolkit 08 Jul '13

08 Jul '13

#456: Ensure functions are not defined twice -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- When multiple source files define non-static functions with the same name, these are all compiled together into the resulting executable. Which one gets called is not predictable by the user. This can happen if a user copies a thorn, modifies it slightly, and compiles both thorns into the same configuration. This can lead to *very* difficult-to-find bugs, and it would be helpful if Cactus was able to prevent this, or at least to mitigate the problem. At the CST level, Cactus should be able to tell that there are two thorns which schedule functions with the same name. At the moment, this is not caught. I propose that this should be a fatal error, as there is no way to predict which function will be called eventually. This will solve the problem in some cases, but not in the case where there are instances of duplicate function names which are not scheduled. It should be possible to scan the object/library files using standard tools (nm etc) to determine if there are multiple globally visible symbols with the same name. There might even be standard tools for this purpose. Doing this in a portable way might not be straightforward, but having an implementation for Linux, for example, would catch the majority of cases. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/456> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1348: simfactory doesn't support multi-core setup using setup-silent
by Einstein Toolkit 07 Jul '13

07 Jul '13

#1348: simfactory doesn't support multi-core setup using setup-silent -------------------------+-------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Keywords: | -------------------------+-------------------------------------------------- It is easy to see why a complete multi-core setup using setup-silent isn't the best way to go. Editing the resulting file is usually so much more convenient. However, the attached patch adds the possibility to have the options --ppn and --num-threads being taken into account for setup-silent. --ppn sets 'ppn', 'max-num-threads' to it's value, and 'make' to 'nice make -j'+value. --num-threads sets 'num-threads'. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1348> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1379: Rename autoconfigured CCTK_BUILTIN functions to __builtin
by Einstein Toolkit 07 Jul '13

07 Jul '13

#1379: Rename autoconfigured CCTK_BUILTIN functions to __builtin -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Other | Version: development version Keywords: | -------------------------+-------------------------------------------------- With autoconf, it is common to define a work-around if a tested feature does not exist. For example, when the "inline" keyword does not exist, then there is a #define that allows code to still use "inline", instead of requiring all code to use CCTK_INLINE. This keeps code more readable. Cactus tests for various __builtin_* features (__builtin_expect, __builtin_unreachable). If these are not present, it defines CCTK_BUILTIN work-around that one can use instead. I suggest to provide instead the respective __builtin_* functions. We would keep the current CCTK_BUILTIN_* variants for backward compatibility (at least for some time), but would not define them for new builtins that we autoconfigure. $ svn diff cctk_Config.h.in Index: cctk_Config.h.in =================================================================== --- cctk_Config.h.in (revision 5021) +++ cctk_Config.h.in (working copy) @@ -376,6 +376,7 @@ # define CCTK_BUILTIN_EXPECT(x,y) __builtin_expect(x,y) #else # define CCTK_BUILTIN_EXPECT(x,y) (x) +# define __builtin_expect(x,y) CCTK_BUILTIN_EXPECT(x,y) #endif /* Whether __builtin_unreachable exists. */ @@ -384,8 +385,15 @@ # define CCTK_BUILTIN_UNREACHABLE() __builtin_unreachable() #else # define CCTK_BUILTIN_UNREACHABLE() CCTK_Abort(0, 1) +# define __builtin_unreachable() CCTK_BUILTIN_UNREACHABLE() #endif /* OpenMP collapse clause */ #if (defined CCTK_DISABLE_OMP_COLLAPSE || \ (defined __IBMC__ && defined _ARCH_450D) || \ @@ -585,6 +593,7 @@ # define CCTK_BUILTIN_EXPECT(x,y) __builtin_expect(x,y) #else # define CCTK_BUILTIN_EXPECT(x,y) (x) +# define __builtin_expect(x,y) CCTK_BUILTIN_EXPECT(x,y) #endif /* Whether __builtin_unreachable exists. */ @@ -593,8 +602,15 @@ # define CCTK_BUILTIN_UNREACHABLE() __builtin_unreachable() #else # define CCTK_BUILTIN_UNREACHABLE() CCTK_Abort(0, 1) +# define __builtin_unreachable() CCTK_BUILTIN_UNREACHABLE() #endif /* Whether static_assert exists. */ #undef HAVE_CCTK_CXX_STATIC_ASSERT #ifdef HAVE_CCTK_CXX_STATIC_ASSERT -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1379> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac