Trac September 2013

trac@lists.einsteintoolkit.org

1 participants
141 discussions

[Einstein Toolkit] #1314: increase number of triggers in AEIThorns trigger
by Einstein Toolkit 11 Feb '14

11 Feb '14

#1314: increase number of triggers in AEIThorns trigger -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: Trigger | -----------------------------------+---------------------------------------- currently the max is 10. I find myself needing more (15 to be precise). Can we increase this number to say 39 (or some other largish non-typical number) or are that many parameters too expensive to support? Similarly (but more complicated) it would be useful to be able to steer more than one parameter/grid scalar when a trigger triggers. The current way of specifying targets is unfortunately not well suited for this. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1314> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1117: Wrong CarpetIOASCII headers for complex 2D output.
by Einstein Toolkit 25 Jan '14

25 Jan '14

#1117: Wrong CarpetIOASCII headers for complex 2D output. ----------------------------------------+----------------------------------- Reporter: reisswig@… | Type: defect Status: new | Priority: minor Milestone: | Component: Other Version: | Keywords: ----------------------------------------+----------------------------------- I am outputting a 2d _complex_ array (called "extracted_vars") using 2d CarpetIOASCII output. Using the standard output format, the data starts at column 13. So the first array element "extracted_vars[0]" is at column 13. Now, since I have a complex array, the second element, "extracted_vars[1]", must be at column 15 (column 14 contains the imaginary part of element [0]). In older versions of Carpet, this was reported correctly in the header. In the current version, it is incorrect. The second element, "extracted_vars[1]" is reported to be in column 14 instead of 15. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1117> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #542: Remove thorn CactusArchive/ADM from thorn list
by Einstein Toolkit 25 Jan '14

25 Jan '14

#542: Remove thorn CactusArchive/ADM from thorn list -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: task | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Remove thorn CactusArchive/ADM from thorn list. This thorn is outdated, and we should updated out test cases instead. It also takes a long time and a lot of memory to compile. If we want an ADM formulation (which is doubtful since we don't use it ourselves), we should implement one via Kranc. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/542> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #114: per-variable tolerances for Cactus testsuites
by Einstein Toolkit 24 Jan '14

24 Jan '14

#114: per-variable tolerances for Cactus testsuites -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: major | Milestone: ET_2011_06 Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- It would be nice to be able to specify per-variable testsuite tolerances in Cactus (per regexp for the name in the ideal case). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/114> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 24

[Einstein Toolkit] #1352: ExternalLibraries/Lua requires readline-headers
by Einstein Toolkit 16 Jan '14

16 Jan '14

#1352: ExternalLibraries/Lua requires readline-headers --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | --------------------+------------------------------------------------------- ExternalLibraries/Lua requires readline-headers, but there is no check for it. We could provide a thorn containing it (or forget about the lua thorn - I don't know of any user right now). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1352> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1401: misspelling ActiveThorns in parfiles results in unhelpful error message
by Einstein Toolkit 15 Jan '14

15 Jan '14

#1401: misspelling ActiveThorns in parfiles results in unhelpful error message --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- the attached parfile (which misspells ActiveThorns as ActiveThrons) causes the error message: {{{ Activating thorn Cactus...Success -> active implementation Cactus ERROR IN PARAMETER FILE: In rule 'file::set::par' Line=1, Column=13 ActiveThrons = "Cactus" ^ Expected one of the following characters: [ \t\r\n#:] WARNING level 0 in thorn Cactus processor 0 host horizon.tapir.caltech.edu (line 167 of /mnt/data/rhaas/postdoc/gr/Zelmani/src/main/ProcessParameterDatabase.c): -> CCTKi_SetParameterSetMask: 1 parsing errors in parameter file WARNING level 0 in thorn Cactus processor 0 host horizon.tapir.caltech.edu (line 167 of /mnt/data/rhaas/postdoc/gr/Zelmani/src/main/ProcessParameterDatabase.c): -> CCTKi_SetParameterSetMask: 1 parsing errors in parameter file }}} which does not provide a hint for the cause of the error. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1401> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #1381: Carpet no longer has an implied sync() call after restriction
by Einstein Toolkit 14 Jan '14

14 Jan '14

#1381: Carpet no longer has an implied sync() call after restriction --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: development version Keywords: | --------------------+------------------------------------------------------- I just pushed two tests for the higher order restriction code into CarpetProlongateTest. What I did was to generate the test data before the commit that removes the extra sync, then save the data and apply as the test data on top of the master branch. I also verified that indeed I get the same restricted data across an interprocessor boundary (ie in the z direction of the tests). Surprisingly I actually do since in fact the schedule.ccl file in CarpetProlongateTest does not apply boundary conditions are SYNC in MoL_PostStep so that I should have gotten test failures. This would seem to indicate that either (a) I don't have my test setup correctly (always possibly) or (b) there is yet another SYNC hidden somewhere inside of CarpetLib/Carpet. On the other hand, the current "_rest" tests in CarpetProlongateTest now fail for me unless I re-add the sync. Adding a dummy routine and SYNC to MoL_PostStep which I think is the correct thing to do does not help possibly because the SYNC implies a prolongation while a low-level sync call does not (and which is where I see differences). This of course would argue against (b) above. Attached please find my code change a a plot of diffference.z.asc for test_cc_rest_o3 before and after the change. I do not necessarily think that this is a bug, it certainly is unexpected though. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1381> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1363: Crash on startup in Piraha
by Einstein Toolkit 13 Jan '14

13 Jan '14

#1363: Crash on startup in Piraha ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: blocker | Milestone: ET_2013_05 Component: Other | Version: Keywords: | ----------------------+----------------------------------------------------- I built a Cactus configuration with fewer thorns than usual, and with assertions disabled (-DNDEBUG. This configuration does not start; it crashes on startup with a backtrace {{{ #0 std::_Rb_tree<void*, void*, std::_Identity<void*>, std::less<void*>, std::allocator<void*> >::_M_insert_unique<void* const&> (this=0x0, __v=@0x7fff5fbfd228) at locale_facets.h:1078 #1 0x000000010072e6f2 in smart_ptr<piraha::Grammar>::smart_ptr (this=0x104b9d0d0, ptr=0x10570a5a0, array_=<value temporarily unavailable, due to optimizations>) at stl_set.h:415 #2 0x0000000100721542 in piraha::AutoGrammar::reparserGenerator () at AutoGrammar.cc:6 #3 0x0000000100c2ada6 in _GLOBAL__sub_I_Grammar.cc () at smart_ptr.hpp:53 #4 0x00007fff5fc13762 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE () }}} This indicates that the failure oocurs during initialisation of a global variable during startup. _Rb_tree points to a set or a map. This may be caused by {{{ extern smart_ptr<Grammar> pegGrammar; }}} I also see that Piraha has some code in smart_ptr.hpp that is only added when DNEBUG is defined, and contains assert calls (!). Given that NDEBUG disables assert, this looks like an error. It is considered bad style to use C++ constructors to initialise global variables; this is fragile and breaks often. I suggest instead to change these global variables to pointers, to initialise them to NULL, and to allocate to respective objects explicitly at run time. This is safer, as it ensures that things are allocated in the right order. I also just see that there is a global variables called "ptrs" in Piraha. This is not good; please use a cctki_ prefix for all globally visible variables and functions (or move them into a namespace). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1363> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #1291: Boundary does not check for storage
by Einstein Toolkit 13 Jan '14

13 Jan '14

#1291: Boundary does not check for storage -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- I accidentally selected a variable for a flat boundary condition (with thorn Boundary) without storage. This led to a segfault. Instead, thorn Boundary should output an error message or a warning. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1291> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #1369: Error link doesn't work on Mac
by Einstein Toolkit 06 Jan '14

06 Jan '14

#1369: Error link doesn't work on Mac ---------------------+------------------------------------------------------ Reporter: sbrandt | Owner: sbrandt Type: defect | Status: new Priority: major | Milestone: Cactus_4.3.0 Component: Mojave | Version: Keywords: | ---------------------+------------------------------------------------------ Error link doesn't work on Mac -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1369> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

← Newer
1
...
7
8
9
10
11
12
13
14
15
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac September 2013