Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1322: CarpetRegrid2 movement_threshold
by Einstein Toolkit 17 Apr '13

17 Apr '13

#1322: CarpetRegrid2 movement_threshold -----------------------------------+---------------------------------------- Reporter: vassilios.mewes@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: ET_2012_11 Keywords: CarpetRegrid2 | -----------------------------------+---------------------------------------- i have got a question about the CarpetRegrid2 process of regridding when supplying the thorn with information from puncture tracker... in a recent simulation of BH+torus system i did, the BH was moving significantly further than the movement_threshold i supplied in the par file, but Carpet never regridded...it seems to me that the new center is set at a frequency of regrid_every, but shouldn't it be reset only when the center has moved further than the movement_threshold parameter? as it seems to me at the moment, i would have to know the movement of the BH a priori in order to chose a sensible regridding frequency, because if the BH moves too little between regrid_every, it will eventually move out of the finest refinement level.. furthermore, the regridding frequency might change during the run because the BH is actually accelerating... i am doing something wrong here or setting false parameters? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1322> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #591: Add harmonic shift to McLachlan
by Einstein Toolkit 15 Apr '13

15 Apr '13

#591: Add harmonic shift to McLachlan -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: McLachlan | -----------------------------------+---------------------------------------- The attached patch adds a harmonic shift condition to McLachlan. It does this by introducing a new real-valued parameter harmonicShift. This should be set to 0 for gamma-driver shift (the default, and the existing behaviour), and to 1 for harmonic shift. This is useful for code- correctness tests with the shifted gauge wave which is an exact solution of the Einstein equations in harmonic gauge. The harmonic shift equation has been tested with the shifted gauge wave exact solution and yields convergence to the exact solution. The current way that gauge conditions is handled in McLachlan is not very elegant, and I don't think this patch should be applied as-is. I am putting it here for anyone who might find it useful. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/591> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1289: Harmonic shift in McLachlan only works for conformalMethod = 1 (W method)
by Einstein Toolkit 15 Apr '13

15 Apr '13

#1289: Harmonic shift in McLachlan only works for conformalMethod = 1 (W method) -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: McLachlan | -----------------------------------+---------------------------------------- The harmonic shift implemented in #591 is missing the case discrimination for the conformalMethod parameter; the way it is currently coded is correct for conformalMethod = 1 (W method) but not for conformalMethod = 0 (phi method). My original version of the code had the two variants but I removed this at some point while testing and my submitted patch contained only conformalMethod = 1. In my original notes, I have this {{{ alpha^2 em4phi (gtu[ua, uk] (PD[alpha, lk]/alpha + 2 IfThen[conformalMethod, -1/(2 phi), 1] PD[phi, lk]) - gtu[ua, ul] gtu[uj, um] PD[gt[ll, lm], lj]) }}} which should be checked again before committing. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1289> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1321: Collisions in executable cache directory
by Einstein Toolkit 12 Apr '13

12 Apr '13

#1321: Collisions in executable cache directory ------------------------+--------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- If I have two Cactus trees both using the same configuration names and the same simulation directory, I believe that the executable cache in simulations/CACHE will suffer from collisions between the cached executables in the different Cactus trees. A solution would be to use a unique name for the executable, just as is done when purging simulations to the TRASH directory. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1321> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #1304: slow build
by Einstein Toolkit 11 Apr '13

11 Apr '13

#1304: slow build ----------------------------------+----------------------------------------- Reporter: srichers@… | Owner: sbrandt Type: defect | Status: new Priority: major | Milestone: Component: Mojave | Version: Keywords: | ----------------------------------+----------------------------------------- There is a significant lag when using the Mojave 'Build' command. It is not noticeable for the WaveToy demo, but for the Einstein Toolkit, eclipse freezes for about 30 seconds before the console shows build progress. Following a completed build ("done." printed in the console), the progress bar in eclipse remains static at one percentage for another ~5 minutes, preventing another build command from executing. Fresh (yesterday) install of eclipse and Mojave. ET downloaded through Mojave wizard using development thornlist on the ET website. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1304> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1320: reconstruct_Wv with cell centering violates angular momentum conservation
by Einstein Toolkit 10 Apr '13

10 Apr '13

#1320: reconstruct_Wv with cell centering violates angular momentum conservation -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: rhaas Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- we have a bug report that at least for cell centering the option reconstruct_Wv (off by default) does not conserve angular momentum. This system where this was observed was a torus around a BH. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1320> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1318: Update hwloc to 1.7
by Einstein Toolkit 10 Apr '13

10 Apr '13

#1318: Update hwloc to 1.7 -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: ET_2013_05 Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The hwloc library distributed with the ET is currently at a pre-release version. I suggest to update to version 1.7, which has just been released. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1318> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1319: implement Josh Faber's hydro with punctures trick
by Einstein Toolkit 10 Apr '13

10 Apr '13

#1319: implement Josh Faber's hydro with punctures trick -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: task | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- implement [http://arxiv.org/abs/0708.2436] . Worked for UIUC, GT, and in similar form for Vassilios Mewes. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1319> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1313: GRHydro bugfixes
by Einstein Toolkit 10 Apr '13

10 Apr '13

#1313: GRHydro bugfixes -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- due to the code freeze, I will only propose bug fixes until the release branch has been created. Attached are three of those. The first one is related to Christian Reisswig's bugfixes in the excision handling, the second one is a trivial patch that affects how divB is computed (no change in output due to the variable in question being initialized to zero before). The last one reverts the meaning of the (newly introduced) parameters cyl_rho_inner and *_outer so that the values for _outer are used for large "r" and inner for small "r". -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1313> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1312: quick rsync for simfactory
by Einstein Toolkit 09 Apr '13

09 Apr '13

#1312: quick rsync for simfactory -------------------------+-------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: development version Keywords: | -------------------------+-------------------------------------------------- Quite often I find myself developing something (code/parfiles) locally and use 'sim sync' to get it to a remote location. Until a recent change in simfactory this was usually quite fast (a couple of seconds at most). In all of these cases I know that I didn't change anything on the remote side. Now 'sim sync' can take a minute even to local machines, depending on their file system load since the remote side has to actually read the complete tree for comparison. And this is without any actual changes. I propose to have a 'sim sync --fast' option which uses timestamps as before. This should not be the default since it might not catch all changes in every situation, but it would make quick development sessions like this (edit locally, compile and run remotely) feasible again. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1312> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac