Trac June 2012

trac@lists.einsteintoolkit.org

1 participants
175 discussions

[Einstein Toolkit] #177: EXC_BAD_ACCESS in CarpetIOASCII
by Einstein Toolkit 06 Aug '12

06 Aug '12

#177: EXC_BAD_ACCESS in CarpetIOASCII --------------------+------------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- I am trying to run a minimal parameter file for testing purposes (attached). Cactus gets as far as printing the iteration 0 info line and then appears to hang. When I run in a debugger, it reports: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 0x0000000100b858b7 in CarpetIOASCII::WriteASCII<0> (os=@0x7fff5fbfc5e0, gfdatas={<std::_Vector_base<const gdata *, std::allocator<const gdata *> >> = {_M_impl = {<allocator<const gdata *>> = {<__gnu_cxx::new_allocator<const gdata *>> = {<No data fields>}, <No data fields>}, _M_start = 0x109f0ea10, _M_finish = 0x109f0eab8, _M_end_of_storage = 0x109f0eab8}}, <No data fields>}, gfext=@0x7fff5fbfc960, vi=0, time=0, org=@0x7fff5fbfcafc, dirs=@0x7fff5fbfd150, rl=0, ml=0, m=0, c=0, tl=0, coord_time=0, coord_lower=@0x7fff5fbfc9d8, coord_upper=@0x7fff5fbfc9f0) at ioascii.cc:1378 1378 switch (vartype) { (gdb) bt #0 0x0000000100b858b7 in CarpetIOASCII::WriteASCII<0> (os=@0x7fff5fbfc5e0, gfdatas={<std::_Vector_base<const gdata *, std::allocator<const gdata *> >> = {_M_impl = {<allocator<const gdata *>> = {<__gnu_cxx::new_allocator<const gdata *>> = {<No data fields>}, <No data fields>}, _M_start = 0x109f0ea10, _M_finish = 0x109f0eab8, _M_end_of_storage = 0x109f0eab8}}, <No data fields>}, gfext=@0x7fff5fbfc960, vi=0, time=0, org=@0x7fff5fbfcafc, dirs=@0x7fff5fbfd150, rl=0, ml=0, m=0, c=0, tl=0, coord_time=0, coord_lower=@0x7fff5fbfc9d8, coord_upper=@0x7fff5fbfc9f0) at ioascii.cc:1378 #1 0x0000000100b5b7ee in CarpetIOASCII::IOASCII<0>::OutputDirection (cctkGH=0x109f073f0, vindex=0, alias={_M_dataplus = {<allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x10a06c1c8 "carpet::timing"}}, basefilename={_M_dataplus = {<allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x10a06ba68 "minimal/carpet::timing"}}, dirs=@0x7fff5fbfd150, is_new_file=true, truncate_file=true) at ioascii.cc:610 #2 0x0000000100b554c4 in CarpetIOASCII::IOASCII<0>::OutputVarAs (cctkGH=0x109f073f0, varname=0x10a06c170 "CARPET::physical_time_per_hour", alias=0x10a06be00 "carpet::timing") at ioascii.cc:480 #3 0x0000000100b57370 in CarpetIOASCII::IOASCII<0>::TriggerOutput (cctkGH=0x109f073f0, vindex=0) at ioascii.cc:359 #4 0x0000000100b542b7 in CarpetIOASCII::IOASCII<0>::OutputGH (cctkGH=0x109f073f0) at ioascii.cc:239 #5 0x000000010329a006 in Carpet::OutputGH (cctkGH=0x109f073f0) at OutputGH.cc:55 #6 0x0000000103293b25 in Carpet::OutputGH (where=0x104c70f3c "Initialise::CallAnalysis", cctkGH=0x109f073f0) at Initialise.cc:1382 #7 0x000000010328d432 in Carpet::CallAnalysis (cctkGH=0x109f073f0) at Initialise.cc:530 #8 0x00000001032892d4 in Carpet::Initialise (fc=0x7fff5fbfe2b0) at Initialise.cc:118 #9 0x000000010005806a in main (argc=4, argv=0x7fff5fbfe318) at flesh.cc:80 I do not see how this line "switch(vartype)" where vartype is declared on the stack, could lead to this error. This configuration has been rebuilt with -O0 (Intel compiler) and debugging enabled. This is with the current production (Git) version of Carpet running on Mac OS 10.6.5. The code is compiled as 64 bit. This parameter file has worked in the past, though with 32 bit on Mac OS 10.5. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/177> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #944: import outstanding Zelmani patches into ET trunk
by Einstein Toolkit 04 Aug '12

04 Aug '12

#944: import outstanding Zelmani patches into ET trunk -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- attached are all current outstanding differences between ET GRHydro and Zelmani GRHydro. I would like to flush them out into trunk. The only ones that do not work with current trunk are the Multirate ones (the last one) so those should be kept back until the MoL multirate issues are resolved. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/944> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #465: Hydro_InitExcision test cases take a long time
by Einstein Toolkit 04 Aug '12

04 Aug '12

#465: Hydro_InitExcision test cases take a long time -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- I am just running all test cases with an executable without optimisation, and I find that Hydro_InitExcision takes a long time. While most other test cases finish in a few minutes, Hydro_InitExcision takes two hours to run. The test cases should be reduced in number, size, or duration. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/465> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #839: MoL Multirate capabilities. This add three new multirate RK schemes to MoL.
by Einstein Toolkit 02 Aug '12

02 Aug '12

#839: MoL Multirate capabilities. This add three new multirate RK schemes to MoL. ----------------------------------------+----------------------------------- Reporter: reisswig@… | Type: enhancement Status: new | Priority: optional Milestone: | Component: Cactus Version: | Keywords: MoL Multirate ----------------------------------------+----------------------------------- In order to make multirate work, we need to introduce new registration routines that explicitly register variables with the "slow" sector, i.e. those variables which are integrated by the lower order scheme. This also means that we require new "accumulator" parameters indicating how many "slow" variables we want to register. Flags indicate whether it is time to execute slow RHS computation. For instance, in the RK4-RK2 scheme, there are 4 substeps in total, but the RK2 RHS are only evaluated in the very first and in the very last step of the four substeps. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/839> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 15

[Einstein Toolkit] #550: CarpetIOHDF5 too verbose while reading from checkpoint
by Einstein Toolkit 02 Aug '12

02 Aug '12

#550: CarpetIOHDF5 too verbose while reading from checkpoint -------------------------+-------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- It is not that uncommon that I recover using a different number of processors. Every time I do this I see the error file cluttered with messages like WARNING level 1 in thorn CarpetIOHDF5 processor 21 host c312-313.ls4.tacc.utexas.edu (line 640 of /work/00920/tg459479/Cactus/arrangements/Carpet/CarpetIOHDF5/src/Input.cc): -> Variable AHFINDERDIRECT::ahmask on rl 0 and tl 0 not read completely. Will have to look for it in other files I expect this, this is not an error and not really something to warn about. I acknowledge that this might have been introduced when recovering using the same number of processors was a problem and caused reading all files, but I don't think this is an issue anymore. I propose to change the warnlevel for this message to CCTK_WARN_DEBUG(4). In addition it would be good to have _one_ separate message with level CCTK_WARN_PICKY(3) if any variable/reflevel/timelevel could not be read completely (but not one for each of these), ideally only once for all processors. This would not clutter the output of the default simfactory runs (-L 3) too much, but would indicate that this happened - and in case this is a problem it's easy to enable -L 4. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/550> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #855: CCTK_TraverseString should be documented
by Einstein Toolkit 17 Jul '12

17 Jul '12

#855: CCTK_TraverseString should be documented -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- CCTK_TraverseString should be documented -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/855> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #634: Riemann1D fails to compile on Kraken
by Einstein Toolkit 08 Jul '12

08 Jul '12

#634: Riemann1D fails to compile on Kraken -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- I'm unable to compile the Riemann1D utility on Kraken. It gives the following error message. {{{ Creating Riemann1d in /nics/d/home/hinder/Cactus/EinsteinToolkit/exe/sim from /nics/d/home/hinder/Cactus/EinsteinToolkit/configs/sim/build/GRHydro/Riemann1d.o /nics/d/home/hinder/Cactus/EinsteinToolkit/configs/sim/build/GRHydro/Riemann1d.o: In function `riemann1d': /nics/d/home/hinder/Cactus/EinsteinToolkit/arrangements/EinsteinEvolve/GRHydro/src/util/Riemann1d.f90:10: undefined reference to `__kmpc_begin' /nics/d/home/hinder/Cactus/EinsteinToolkit/arrangements/EinsteinEvolve/GRHydro/src/util/Riemann1d.f90:374: undefined reference to `__kmpc_end' /usr/bin/ld: link errors found, deleting executable `/nics/d/home/hinder/Cactus/EinsteinToolkit/exe/sim/Riemann1d' make[1]: *** [/nics/d/home/hinder/Cactus/EinsteinToolkit/exe/sim/Riemann1d] Error 1 make: *** [sim-utils] Error 2 }}} I think that this needs an Intel library to be linked in, but I'm not sure which one or how to add it. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/634> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #935: HTTPD can use large amounts of memory for its hash table of pages
by Einstein Toolkit 08 Jul '12

08 Jul '12

#935: HTTPD can use large amounts of memory for its hash table of pages -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: HTTPD | -----------------------------------+---------------------------------------- I just found that for an (stripped down!) parameter file of my production simulations HTTPD creates a Hash table via functions in CACTUS_HOME/src/util/Hash.c that consumes 1GB of memory (for the array of pointers that is the top level hash table structure) to hold about 10000 entries. I am not sure if this is due to a poor choice of hashing function (util_HashHash) or the fact that it doubles the size of the table until the number of entries is smaller than the number of hash slots in (in Util_HashRehash and Util_HashAdd). It was somewhat unexpected that a non- science thorn would use that much memory. Alternatives to use less memory might be to increase the filling factor ie. only rehash if hash->keys > 10*hash->fill (maybe starting from some limit of keys) or to use something like the binary tree implementation in BinaryTree.c (but not that one since it is broken in at least two places). I simple linear list might also be sufficient since HTTPD does not have to be lightning fast and serve hundreds of request per second I expect. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/935> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #966: Carpet always calls POSTREGIRD on the finest level
by Einstein Toolkit 08 Jul '12

08 Jul '12

#966: Carpet always calls POSTREGIRD on the finest level -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- While looking at #965 Christian Reisswig and I noticed that Carpet seems to call the routines on the finest level whenever any recompose happened. This is ok to ensure that global (also global-late) routines are called but also means that local routines are called. In cases where the finest level did not actually change (happens in core collapses we believe), this causes unnecessary calls to eg. MoL_PostStep with its attending SYNC calls. This might be candidate for optimization. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/966> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #751: Carpet fails when running qc0-mclachlan.par
by Einstein Toolkit 08 Jul '12

08 Jul '12

#751: Carpet fails when running qc0-mclachlan.par --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- this is due to ggf::transfer_from_all line 613 (dst->transfer_from) where dst is NULL: {{{ 03 assert (lc1>=0 or lc2>=0); 604 605 // Source and destination data 606 gdata * const dst = 607 lc1>=0 ? storage.AT(ml1).AT(rl1).AT(lc1).AT(tl1) : NULL; 608 cdata const & srcs = srcstorage.AT(ml2).AT(rl2); 609 for (int i=0; i<(int)gsrcs.size(); ++i) { 610 gsrcs.AT(i) = lc2>=0 ? srcs.AT(lc2).AT(tl2s.AT(i)) : NULL; 611 } 612 613 dst->transfer_from 614 (state, gsrcs, times, recv, send, slabinfo, p1, p2, time, pos, pot); }}} which causes a segfault in line 613. lc1 is -1 in this case and passes the assert in line 603. Since dst is used as a pointer it may never be NULL. It can be reproduced with the qc0-mclachlan.par example from simfactory. Tested on Caltech's bethe workstation with 12 MPI processes and no OpenMP. hg blames commit 5418b354a3ab which seems to be the original Carpet import into mercurial so this seems to be caused by something else. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/751> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

← Newer
1
...
10
11
12
13
14
15
16
17
18
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac June 2012