Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #1527: simfactory run script for bluewaters does not use -d or -cc numa_node
by Einstein Toolkit 23 Jan '14

23 Jan '14

#1527: simfactory run script for bluewaters does not use -d or -cc numa_node ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Keywords: | ------------------------+--------------------------------------------------- the aprun man page states that {{{ For OpenMP applications, use both the OMP_NUM_THREADS environment variable to specify the number of threads and the aprun -d option to specify the number of CPUs hosting the threads. ALPS creates -n pes instances of the executable, and the executable spawns OMP_NUM_THREADS-1 additional threads per PE. }}} {{{-cc numa_node}}} is used on kraken (also a Cray using AMD cores) and lets threads migrate within a socket rather than tying them to an individual core. These changes improve run speed of qc0-mclachlan from 14 M/hr to 17 M/hr. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1527> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1525: cannt use environment variables in non-stringy parameters
by Einstein Toolkit 23 Jan '14

23 Jan '14

#1525: cannt use environment variables in non-stringy parameters --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- the attached parfile, when run with {{{ TERMINATE_NEXT=no RUNTIME=12 TERMINATE=never RUNTITLE=test ~/data/postdoc/gr/Zelmani/exe/cactus_null env.par }}} produces an error {{{ WARNING level 0 in thorn Cactus processor 0 host horizon.tapir.caltech.edu (line 1 of env): -> Invalid assignment: Attempting to set a variable of type REAL with (STRING)"12" }}} preventing any number-valued parameter to be passed into the simulation via environment variables. In my case I wanted to use the runtime that I computed based on the information available in a qsub script (ie without using simfactory), which is useful to eg run several short Cactus runs in a single qsub script. It would be useful if (as in eg awk for data read from files) environment variables are considered to be "numeric strings" which can be converted to numbers if required. Boolean, string type parameters and keyword type parameters work fine. This is a regression compared to the old parser which did to the env expansion before the parsing stage so would allow env variables everywhere (though I think only on the RHS and not on the LHS of a parameter setting). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1525> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1524: Configure Script Processing Bug
by Einstein Toolkit 22 Jan '14

22 Jan '14

#1524: Configure Script Processing Bug ---------------------+------------------------------------------------------ Reporter: sbrandt | Owner: Type: defect | Status: new Priority: minor | Milestone: Cactus_4.3.0 Component: Cactus | Version: development version Keywords: | ---------------------+------------------------------------------------------ I was working on modifying the java code compiled during the Chemora project, and discovered that a syntax error in the java source file resulted in an infinite number of blank lines being sent to standard output. I traced the problem down to the fact that certain loops in ConfigScriptParser.pl don't check for end of file. The attached patch fixes that, and unifies some replicated code. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1524> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1526: CactusTest/TestArray outputs unitialized data for gf4d
by Einstein Toolkit 22 Jan '14

22 Jan '14

#1526: CactusTest/TestArray outputs unitialized data for gf4d -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: CactusTest | -----------------------------------+---------------------------------------- the current test arrays in CactusTest/TestArrays does not initialize the 4d array that it outputs. The data in the test output files apparently ended up being zero in the past but gives me poison on my machine right now. The attached patch adds the required code to fill in the 4d array the same way that the 0d-3d arrays are filled in. Passes the tests if I copy the 3d output files onto the 4d ones. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1526> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1519: Parameter parser leaks memory
by Einstein Toolkit 17 Jan '14

17 Jan '14

#1519: Parameter parser leaks memory --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | --------------------+------------------------------------------------------- The function cctk_PirahaParser in src/piraha/Call.cc wraps each argument to its set_function (points to CCTKi_SetParameter) in a strdup (with the exception of ActiveThorns). This leads to a memory leak since CTKi_SetParameter does not free() them. To test, run a minimal parfile {{{ Cactus::cctk_itlast = 42 }}} with an executable from an empty thornlist through valgrind: {{{ valgrind --log-file=valgrind.log --leak-check=full --tool=memcheck cactus_null answer.par }}} and you will find eg {{{ ==27121== 20 bytes in 1 blocks are definitely lost in loss record 297 of 1,362 ==27121== at 0x4C2935B: malloc (vg_replace_malloc.c:270) ==27121== by 0x6249D91: strdup (strdup.c:42) ==27121== by 0x43D1C1: cctk_PirahaParser (Call.cc:875) ==27121== by 0x419855: CCTKi_ProcessParameterDatabase (ProcessParameterDatabase.c:158) ==27121== by 0x416760: CCTKi_InitialiseCactus (InitialiseCactus.c:101) ==27121== by 0x415FFD: main (flesh.cc:64) }}} The attached patch fixes this. There is still some memory leakage (couple hundred bytes that seem to be due to the flesh and persist even when the old parser is reactivated). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1519> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[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] #1520: src/piraha does not adhere to Cactus coding style
by Einstein Toolkit 16 Jan '14

16 Jan '14

#1520: src/piraha does not adhere to Cactus coding style ----------------------+----------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: optional | Milestone: Component: Other | Version: development version Keywords: | ----------------------+----------------------------------------------------- The sources files in the src/piraha directory do not adhere to the flesh coding style described in http://einsteintoolkit.org/documentation/MaintGuide/MaintGuidech2.html#x4-3… . It would be very nice if they had GRDOC (or javadoc or doxygen) headers. Also the internal function cctk_PirahaParser should be called CCTKi_PirahaParser instead (ie uppercase CCTK and an added i for internal). Minor point: smart_ptr.cc should be SmartPtr.cc . This is a project for rainy evenings I guess :-). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1520> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac