Trac February 2013

trac@lists.einsteintoolkit.org

1 participants
177 discussions

[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] #1242: test system does not pause if test fails to run
by Einstein Toolkit 04 Feb '13

04 Feb '13

#1242: test system does not pause if test fails to run --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- when running all tests in a thorn, the test system does not stop for user input when a test completely fails to run (or produces no output files) eg due to an error in the parameter file. {{{ Test GRHydro: tov_carpetevolutionmask2 "Carpet mesh refined, one TOV, Gamma-law, use evolution mask" Issuing mpirun -np 2 exe/cactus_bns_all arrangements/Zelmani/GRHydro/test/tov_carpetevolutionmask2.par Cactus exited with error code 1 Please check the logfile TEST/bns_all/GRHydro/tov_carpetevolutionmask2.log No files created in test directory Failure: 6 files missing, 0 files compared, 0 differ }}} Had the test run but produced different files, the system would have stopped allowing he user to inspect the results. For a thorn with many tests this can make it hard to spot these errors. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1242> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[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

[Einstein Toolkit] #1199: [PATCH]McLachlan_BSSN: fix the Hamiltonian constraint for CCZ4
by Einstein Toolkit 03 Feb '13

03 Feb '13

#1199: [PATCH]McLachlan_BSSN: fix the Hamiltonian constraint for CCZ4 ---------------------------------+------------------------------------------ Reporter: anton@… | Type: defect Status: new | Priority: major Milestone: | Component: EinsteinToolkit thorn Version: development version | Keywords: ---------------------------------+------------------------------------------ A typo in a8794cd2227c87c7457ba51d040e863be2f981e7 has caused the additional CCZ4 terms to overwrite the BSSN value instead of adding to it. Tested to work on TwoPunctures initial data: h = h5py.File('/tmp/testbssn/H.h5') # BSSN reference h1 = h5py.File('/tmp/testccz4/H.h5') # with the patch h2 = h5py.File('/tmp/testccz42/H.h5') # without the patch In [89]: numpy.sum(numpy.abs(h.values()[0][:] - h1.values()[0][:])) Out[89]: 8.0082674998918897e-15 In [90]: numpy.sum(numpy.abs(h.values()[0][:] - h2.values()[0][:])) Out[90]: 7.9536720382719803 -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1199> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1239: AHFinderDirect uses incorrect origin_* upon recovery when horizon was never found before
by Einstein Toolkit 01 Feb '13

01 Feb '13

#1239: AHFinderDirect uses incorrect origin_* upon recovery when horizon was never found before ----------------------------------------+----------------------------------- Reporter: reisswig@… | Type: defect Status: new | Priority: major Milestone: | Component: EinsteinToolkit thorn Version: | Keywords: AHFinderDirect ----------------------------------------+----------------------------------- Problem: After some time in the simulation, I want to search for an horizon. I do not know where the horizon appears initially when the simulation started. I therefore leave origin_* and initial_guess__coord_sphere__*_center at zero. By some means later, I have figured out where the horizon will appear. Therefore, after recovery, I want to set origin_* and initial_guess__coord_sphere__*_center to the origin where I believe the horizon will appear. Unfortunately, upon recovery, the new origin_* is overwritten by whatever was stored in ah_origin_* (this would be zero). Generally, this means that the initial guess ellipsoid that is setup when a horizon has never been found, is ill-posed (because the initial (and incorrect) origin_* are used with the updated initial_guess__coord_sphere__*_center). Solution: Don't use the stored AH origin upon recovery when a horizon has never been found before. The attach patch solves the problem. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1239> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1241: AHFinderDirect is not using the correct origin when "track_origin_from_grid_scalar = yes" when setting up ellipsoid
by Einstein Toolkit 01 Feb '13

01 Feb '13

#1241: AHFinderDirect is not using the correct origin when "track_origin_from_grid_scalar = yes" when setting up ellipsoid ----------------------------------------+----------------------------------- Reporter: reisswig@… | Type: defect Status: new | Priority: major Milestone: | Component: EinsteinToolkit thorn Version: | Keywords: ----------------------------------------+----------------------------------- Problem: My horizon will appear sometimes during the simulation at some position. I don't know this position in advance, so I set origin_* and AHFinderDirect::initial_guess__coord_sphere__*_center to zero initially in my par-file. However, I have a grid scalar which tracks the coordinate location where the horizon will eventually appear. When the horizon finder starts to search for a horizon, it will first setup the coordinate ellipsoid. This routine is executed *before* the new origin is set from the grid scalar. The tracking occurs in the routine Newton(...). The ellipsoid is set before Newton(...) gets executed. Hence, the ellipsoid uses the value that got set via parameters (which would be zero in my case). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1241> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1240: allow non logged in users to change ticket status to "review"
by Einstein Toolkit 01 Feb '13

01 Feb '13

#1240: allow non logged in users to change ticket status to "review" -------------------+-------------------------------------------------------- Reporter: rhaas | Type: defect Status: new | Priority: minor Milestone: | Component: EinsteinToolkit trac Version: | Keywords: -------------------+-------------------------------------------------------- it would be useful if non-logged in users (eg Cactus users that do not want to get a trac account which requires a cct account, yes?) could change the ticket status at least to "review" in case a patch is contributed. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1240> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac February 2013