Trac December 2012

trac@lists.einsteintoolkit.org

1 participants
134 discussions

[Einstein Toolkit] #1116: changing library options in optionlist does'nt trigger rebuild of depending thorns
by Einstein Toolkit 20 Feb '13

20 Feb '13

#1116: changing library options in optionlist does'nt trigger rebuild of depending thorns --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- I first built Cactus using OpenMPI shipped with the thorn MPI. Then I changed the optionlist to point to a local mpich2 installation and tried to rebuild Cactus using the new optionlist (sim build --thornlist=./thornlists/einsteintoolkit.th --optionlist=numrel-gcc.cfg). The new options are used in config-info and on the link line, however, thorns depending on MPI are not rebuilt, leading to link-failures because these thorns have been built against OpenMPI. Any change in the configuration of external libraries should lead to a rebuilt of depending thorns. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1116> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #950: "Correct" Weyl Scalar symmetries
by Einstein Toolkit 19 Feb '13

19 Feb '13

#950: "Correct" Weyl Scalar symmetries ---------------------------------+------------------------------------------ Reporter: yosef@… | Type: defect Status: new | Priority: major Milestone: | Component: Other Version: | Keywords: ---------------------------------+------------------------------------------ RotatingSymmetry180 and the ReflectionSymmetry thorns define a tensor alias "weylscalars_real", but the symmetries given there do not correspond to those of the usual re[psi0], im[psi0], re[psi1], im[psi1], etc scalars. The Weyl symmetries as provided in RotatingSymmetry180 static int const weylparities[10][3] = {{+1,+1,+1}, {-1,-1,-1}, {+1,+1,+1}, {-1,-1,-1}, {+1,+1,+1}, {-1,-1,-1}, {+1,+1,+1}, {-1,-1,-1}, {+1,+1,+1}, {-1,-1,-1}}; The symmetries for rpsi0, ipsi0, rpsi1, ipsi1, ..., rpsi4, ipsi4 static int const weylparities[10][3] = {{+1,+1,+1}, /* rpsi0 */ {-1,-1,-1}, /* ipsi0 */ {+1,+1,-1}, /* rpsi1 */ {-1,-1,+1}, /* ipsi1 */ {+1,+1,+1}, /* rpsi2 */ {-1,-1,-1}, /* ipsi2 */ {+1,+1,-1}, /* rpsi3 */ {-1,-1,+1}, /* ipsi3 */ {+1,+1,+1}, /* rpsi4 */ {-1,-1,-1}}; /* ipsi4 */ attached is a diff between the current ET version of the Reflection and RotatingSymmetry180 thorns and the "corrected" version. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/950> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #737: simfactory sync can lead to inconsistent builds
by Einstein Toolkit 11 Feb '13

11 Feb '13

#737: simfactory sync can lead to inconsistent builds ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- simfactory's sync command uses rsync with the --archive (-a) option. This option set the modification date of files on the target machine to that on the source machine. This can lead to inconsistent builds in the following situation: [1] local: edit source_file.c [2] local: simfactory sync [3] local: edit source_file.c [4] remote: simfactory build [5] local: simfactory sync [6] remote: simfactory build [6] will not rebuild source_file.o since [5] set the modification time to that of [3] which which is older than [4] hence make will not consider source_file.o to be out-of-date. A simple fix is to add --no-times to the rsync options. Unfortunately this disables rsync's file modification time optimization and requires it to compute checksums on all files which can be very slow on slow filesystems. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/737> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1161: Add thorn libwebp
by Einstein Toolkit 08 Feb '13

08 Feb '13

#1161: Add thorn libwebp -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Webp is an image format that is superior to png, and may supercede it at some point. We should have an external library to support it. See <https://code.google.com/p/webp/>. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1161> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1070: EOS_Omni::poly_gamma_ini should default to poly_gamma
by Einstein Toolkit 08 Feb '13

08 Feb '13

#1070: EOS_Omni::poly_gamma_ini should default to poly_gamma -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- At the moment, EOS_Omni::poly_gamma and EOS_Omni::poly_gamma_ini are two parameters for the adiabatic exponent, one used only for initial data, the other for evolutions. Both default to 2.0. This means that if someone, unaware of poly_gamma_ini, changes only poly_gamma the result is usually catastrophic (wrong results or c2p failures). I myself didn't notice today and had to debug my way down to find my mistake. I propose to make the default of EOS_Omni::poly_gamma_ini to be whatever EOS_Omni::poly_gamma is. One way to achieve that would be to use some special value for EOS_Omni::poly_gamma_ini which would usually not being used to indicate that behavior and to make that default. However, this being an exponent, at least in theory, all real values are allowed. Another approach would be to introduce a new boolean parameter which would allow users to use an initial value for gamma which is different from the one of the initial data. This would be 'saver', but has the drawback of a new parameter. Nevertheless, I favor the second approach. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1070> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 18

[Einstein Toolkit] #1099: CarpetLib::interpolate_from_buffer_zones should by default set to "no"
by Einstein Toolkit 08 Feb '13

08 Feb '13

#1099: CarpetLib::interpolate_from_buffer_zones should by default set to "no" --------------------+------------------------------------------------------- Reporter: knarf | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: ET_2012_11 Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- CarpetLib::interpolate_from_buffer_zones should by default set to "no" after it is properly tested and we should think about whether we have a good reason to not remove that paramter then again. Adding the release tag because we don't want to have a change like this affecting two releases. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1099> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1078: ignore non-evolved points in check_GRHydro_C2P_failed
by Einstein Toolkit 07 Feb '13

07 Feb '13

#1078: ignore non-evolved points in check_GRHydro_C2P_failed -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- The attached patch interfaces GRHydro with Carpet/CarpetEvolutionMask to not abort a run if a con2prim failure happens at points that are not active in the sense that they should not be eg. visualized. CarpetEvolutionMask computes these points by taking the restricted region and modifying it to take buffer zones and ghost zones for prolongation into account. The proposed patch uses Cray pointers (see https://trac.einsteintoolkit.org/ticket/1065) since the Cactus flesh routine to CCTK_VarDataPtr (for Fortran) uses them as well. This requires extra switches for compilers to compile. For gcc the switch is "-fcray- pointer" for intel adding "-safe_cray_ptr" might help efficiency. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1078> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1134: Adams-Bashforth time integrator
by Einstein Toolkit 07 Feb '13

07 Feb '13

#1134: Adams-Bashforth time integrator -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The attached patch implements Adams-Bashforth time integration in MoL and provides a WaveToy test case. Adams-Bashforth integrators calculate a high-order extrapolation with a single RHS evaluation by combining it with results from previous time steps. This requires multiple time levels for the RHS variables. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1134> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #940: McLachlan dissipation error
by Einstein Toolkit 06 Feb '13

06 Feb '13

#940: McLachlan dissipation error -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- A kind person tells me: I wanted to mention what appears to be a mistake in your dissipation calculation. If you refer to Kreiss-Oliger, or equivalently to Dissipation/src/apply_dissipation.F77, you find that there is a sign flip at certain orders. For example, 3rd order dissipation to be used with 2nd order differencing, and 7th order dissipation to be used with 6th order differencing, both need a negative coefficient. But you don't appear to have such a minus sign (unless I missed it), and your parameter epsdiss is constrained to be positive. It looks to me like PDdissipationNth needs to be multiplied by something like (-1)^(fdOrder/2). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/940> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1202: fix some CarpetProlongationTest tests
by Einstein Toolkit 04 Feb '13

04 Feb '13

#1202: fix some CarpetProlongationTest tests --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- the attached patch fixes (by adjusting the domain which was created before CarpetRegrid2 changed its property enforcement logic) some tests in CarpetProlongationTest and also restricts those tests that produce Carpet 1D ouptut to 1 or 2 processes (depending on how many were apparently used to create the test). For some tests (test_o1 test_cc_rest_o0 test_cc_rest_o1) I could not make the code agree with these measures and since they also show differences in a "sum" reduced quantity I replaced the "sum" data by errornorm 0D output (and had to regenerate the data because of this). I am not sure what the expected smallness of errornorm is. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1202> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac December 2012