Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1246: link time errors about builtin_isinf on bethe
by Einstein Toolkit 07 Feb '13

07 Feb '13

#1246: link time errors about builtin_isinf on bethe --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- I get link time errors about missing builtin functions on bethe using the current ET thornlist and a option list with options to disable OMP collapse. This happens with current trunk. If I remember correctly I can circumvent the problem with careful choices for '-Disinf=std::isinf' etc. However this seems like a fudge and dangerous given the amount of work put into getting isnan to work in Cactus recently. Is there a "correct" way to fix this? I attach the make output, options list, thorn list and a list of all thorn revisions. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1246> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1248: SimFactory should not silently disable thorns
by Einstein Toolkit 07 Feb '13

07 Feb '13

#1248: SimFactory should not silently disable thorns ------------------------+--------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- It is very confusing when you have a thorn in your thornlist, and simfactory silently disables it because it is included in the "disabled- thorns" entry of the machine. SimFactory should at the very least print a message warning the user when the job is submitted that certain thorns requested in the thornlist have been disabled. Printing it when building won't be enough, as the output will likely get lost, but it should also be printed there. It would also be useful to have an option to disable the disabling code, as it has always confused me and wasted my time, and never benefitted me, to my knowledge. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1248> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1243: Allow pseudo-2D domains in CarpetRegrid2
by Einstein Toolkit 07 Feb '13

07 Feb '13

#1243: Allow pseudo-2D domains in CarpetRegrid2 --------------------+------------------------------------------------------- Reporter: knarf | Owner: knarf Type: defect | Status: new Priority: major | Milestone: ET_2013_05 Component: Other | Version: development version Keywords: | --------------------+------------------------------------------------------- Currently CarpetRegrid2 contains two asserts that fail for domains that are effectively 2D (but defines as 3D arrays, e.g. (nx,ny,1). The attached patch makes sure these domains don't trigger the assert by checking for ilower==iupper. I also attached a parfile intended as testsuite for this case. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1243> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1218: MoL updates
by Einstein Toolkit 07 Feb '13

07 Feb '13

#1218: MoL updates -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The enclosed patches update MoL in three respects: (1) Introduce a function LinearCombination that calculates a linear combination of several grid functions. Use this throughout several (but not yet all) integrators, simplifying the code substantially. This function can also be overloaded to execute on devices if OpenCL or CUDA is used, thus making MoL device aware. (2) Introduce a new integrator "Euler", providing an explicit first-order integrator. This is very handy for debugging. (3) Use cctk_ash instead of cctk_lsh where necessary. Since we use svn, these changed are intermingled in my working directory. I created the patches above manually. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1218> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[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] #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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac