Trac

trac@lists.einsteintoolkit.org

8708 discussions

[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

[Einstein Toolkit] #1237: Backport CarpetRegrid2 correction to Oersted
by Einstein Toolkit 29 Jan '13

29 Jan '13

#1237: Backport CarpetRegrid2 correction to Oersted ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: defect | Status: new Priority: critical | Milestone: Component: Carpet | Version: Keywords: | ----------------------+----------------------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1237> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1235: commit4306806ad6d517f4e9b675d3cd541c95db3ea7fa breaks multipatch runs
by Einstein Toolkit 29 Jan '13

29 Jan '13

#1235: commit4306806ad6d517f4e9b675d3cd541c95db3ea7fa breaks multipatch runs --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Other | Version: Keywords: | --------------------+------------------------------------------------------- The assert(offsets.empty()) in dh::regrid line 1207 and 1265 which may not find the std::vector offsets empty if regrid is called on levels that were not changed. A quick fix is to clear() local_boxes at the top of dh::regrid (attached). However since local_boxes are expensive I less drastic method might be better. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1235> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1234: Correct grid structure output
by Einstein Toolkit 28 Jan '13

28 Jan '13

#1234: Correct grid structure output ------------------------------------+--------------------------------------- Reporter: seth.hopper@… | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | ------------------------------------+--------------------------------------- Carpet: Output grid structure after initialization/recovery Previously, the first iteration was always 0 on recovery. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1234> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1233: McLachlan should not define one-character variables
by Einstein Toolkit 27 Jan '13

27 Jan '13

#1233: McLachlan should not define one-character variables ---------------------------------+------------------------------------------ Reporter: knarf | Type: enhancement Status: new | Priority: minor Milestone: | Component: EinsteinToolkit thorn Version: development version | Keywords: ---------------------------------+------------------------------------------ McLachlan defines several one-character grid functions, making it impossible to use these in thorns inheriting from McLachlan. One example is 'A' which in Fortran is the same as 'a' which is often used as temporary variable. 'A' in McLachlan is the time derivative of the lapse, and in the ML_dtlapse group. Would there be any problem renaming the grid function also to ML_dtlapse? (and similarly others, e.g., B and H and possible some of the two-character variables as well) -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1233> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1228: rename 'mike2' in simfactory to just 'mike'
by Einstein Toolkit 24 Jan '13

24 Jan '13

#1228: rename 'mike2' in simfactory to just 'mike' -------------------------+-------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- I would like to rename the machine 'mike2' in simfactory to just 'mike', as there is no 'mike1', and while the machine _is_ called "Supermike 2", even the login node is usually 'mike1'. But of course the main reason is that I am lazy to type the '2'. :) -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1228> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1220: OPTIONAL_IFACTIVE
by Einstein Toolkit 20 Jan '13

20 Jan '13

#1220: OPTIONAL_IFACTIVE -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Following up on a discussion on the Cactus developers mailing list, I want to suggest a third way of indicating a desired capability. In addition to REQUIRES and OPTIONAL, I suggest OPTIONAL_IFACTIVE. This behaves like OPTIONAL, except that the capability relationship only exists if the thorn providing the capability is active. For example, thorn GRHydro would state "OPTIONAL_IFACTIVE Carpet". This mean that, if Carpet is built into the configuration (i.e. is in the thorn list), _and_ if Carpet is active, then GRHydro will depend on it, e.g. by calling functions in Carpet. If Carpet is not in the thorn lists, these calls will be #ifdef'd out, and if Carpet is not active, these calls will not occur. This will make it possible to automatically activate all thorns that provide a required capability. In fact, the attached patch already implements this. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1220> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1226: backport of include fix for FMA4 to Ørsted
by Einstein Toolkit 20 Jan '13

20 Jan '13

#1226: backport of include fix for FMA4 to Ørsted -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: ET_2012_05 Keywords: | -----------------------------------+---------------------------------------- The following small patch was part of LSUThorns/Vectors revision 77 and would allow Ørsted-users to build Vectors on, e.g., bluewaters. Currently the old code produces a compile-error stating that one should do what this patch resolves: using another include file. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1226> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1230: Make Cactus test suite mechanism independent of Carpet's domain decomposition
by Einstein Toolkit 20 Jan '13

20 Jan '13

#1230: Make Cactus test suite mechanism independent of Carpet's domain decomposition -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- I recently used this line to look for differences: diff -u <(grep '^[^#]' arrangements/EinsteinEvolve/GRHydro/test/balsara1_2d/grhydro\:\:bcons.y.asc | sort -u) <(grep '^[^#]' TEST/sim/GRHydro/balsara1_2d/grhydro\:\:bcons.y.asc | sort -u) This removes all comments and empty lines, then sorts the output and removes duplicate lines (from different processes). The result is rather easy to interpret. If one also deleted column 5 (?) containing the component number, then this would make the self-test independent of Carpet's process decomposition. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1230> 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