Trac July 2012

trac@lists.einsteintoolkit.org

1 participants
161 discussions

[Einstein Toolkit] #972: Add PETSC_INC_DIRS etc. to ExternalLibraries/PETSc
by Einstein Toolkit 08 Jul '12

08 Jul '12

#972: Add PETSC_INC_DIRS etc. to ExternalLibraries/PETSc ----------------------------------------------------+----------------------- Reporter: Erik Schnetter <schnetter@…> | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | ----------------------------------------------------+----------------------- The thorn ExternalLibraries/PETSc does not provide variables called PETSC_INC_DIRS, PETSC_LIB_DIRS, PETSC_LIBS to allow overriding the auto- detected defaults. When the auto-detecting mechanism fails, one currently has to use the global options SYS_INC_DIRS, LIBDIRS, and LIBS to ensure the PETSc files are found at build time. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/972> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[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

[Einstein Toolkit] #958: schedule hydrobase_InitExcisionmask global-early loop-local
by Einstein Toolkit 08 Jul '12

08 Jul '12

#958: schedule hydrobase_InitExcisionmask global-early loop-local ----------------------------------+----------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit trac | Version: Keywords: HydroBase | ----------------------------------+----------------------------------------- Christian Ott found that right now the scheduling of EinsteinUtil/SetMask_SphericalSurface::SetMask_SphericalSurface and HydroBase::HydroBase_InitExcisionMask conflict in the Post_Recover_Variables and INITIAL since SetMask_SphericalSurface which needs to run after HydroBase_InitExcisionMask is scheduled GLOBAL which happens to be global-late in these bins. SetMask_SphericalSurface must be local since it must run after SphericalSurfaceHasBeenSet which is after SphericalSurface_Set which is GLOBAL. The attached patch runs HydroBase_InitExcisionMask global-early loop-local instead. Pleas note that the patch will change the behaviour in PostRegrid slightly since HydroBase_InitExcisionMask (and not just SetMask_SphericalSurface which already does so) will run on all refinement levels, always, independent of the iteration counter and Carpet's do_every logic. The current code prevents properly recovering from checkpoints. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/958> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #971: global-early, loop-local routines in PostRegrid cause access to elements outside of a vector capacity
by Einstein Toolkit 08 Jul '12

08 Jul '12

#971: global-early, loop-local routines in PostRegrid cause access to elements outside of a vector capacity --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- This happens whenever a refinement level is created during evolution (but not during the intial regrid which by default is in meta mode). The attached parameter file demonstrates the problem by forcing the initial regrid to happen in level mode. The actual error obtained (using a debug executable) is: {{{ terminate called after throwing an instance of 'std::out_of_range' what(): vector::_M_range_check Rank 0 with PID 23084 received signal6 Writing backtrace to ./backtrace.0.txt Aborted }}} which can be traced back to {{{ (gdb) bt #0 0x00007ffff3476475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007ffff34796f0 in *__GI_abort () at abort.c:92 #2 0x00007ffff3c5468d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x00007ffff3c52796 in ?? () from /usr/lib/x86_64-linux- gnu/libstdc++.so.6 #4 0x00007ffff3c527c3 in std::terminate() () from /usr/lib/x86_64-linux- gnu/libstdc++.so.6 #5 0x00007ffff3c529ee in __cxa_throw () from /usr/lib/x86_64-linux- gnu/libstdc++.so.6 #6 0x00007ffff3ca466d in std::__throw_out_of_range(char const*) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #7 0x00000000010856b7 in std::vector<std::vector<gdata*, std::allocator<gdata*> >, std::allocator<std::vector<gdata*, std::allocator<gdata*> > > >::_M_range_check (this=0xbba8850, __n=0) at /usr/include/c++/4.7/bits/stl_vector.h:774 #8 0x00000000052405b7 in std::vector<std::vector<gdata*, std::allocator<gdata*> >, std::allocator<std::vector<gdata*, std::allocator<gdata*> > > >::at (this=0xbba8850, __n=0) at /usr/include/c++/4.7/bits/stl_vector.h:792 #9 0x000000000524050b in ggf::data_pointer (this=0xb735ad0, tl=0, rl=2, lc=0, ml=0) at /mnt/data/rhaas/postdoc/gr/Zelmani/arrangements/Carpet/CarpetLib/src/ggf.hh:214 #10 0x0000000005257432 in Carpet::enter_local_mode (cctkGH=0xb68bae0, c=0, lc=0, grouptype=402) at /mnt/data/rhaas/postdoc/gr/Zelmani/arrangements/Carpet/Carpet/src/modes.cc:654 #11 0x0000000005258be1 in Carpet::local_component_iterator::step (this=0x7fffffffc580) at /mnt/data/rhaas/postdoc/gr/Zelmani/arrangements/Carpet/Carpet/src/modes.cc:1030 #12 0x0000000005258aa4 in Carpet::local_component_iterator::local_component_iterator (this=0x7fffffffc580, cctkGH_=0xb68bae0, grouptype_=402) at /mnt/data/rhaas/postdoc/gr/Zelmani/arrangements/Carpet/Carpet/src/modes.cc:1006 #13 0x0000000005261f28 in Carpet::CallFunction (function=0x4b42007, attribute=0xb682af8, data=0xb68bae0) at /mnt/data/rhaas/postdoc/gr/Zelmani/arrangements/Carpet/Carpet/src/CallFunction.cc:187 #14 0x00000000006f9cfc in CCTKi_ScheduleCallFunction (function=0x4b42007, attribute=0xb682ae0, data=0x7fffffffcc50) at /mnt/data/rhaas/postdoc/gr/Zelmani/src/main/ScheduleInterface.c:3027 #15 0x00000000006fdaf7 in ScheduleTraverseFunction (function=0x4b42007, attributes=0xb682ae0, n_whiles=0, whiles=0x0, n_ifs=0, ifs=0x0, item_entry=0x6f9548 <CCTKi_ScheduleCallEntry>, item_exit=0x6f9772 <CCTKi_ScheduleCallExit>, while_check=0x6f9981 <CCTKi_ScheduleCallWhile>, if_check=0x6f9a14 <CCTKi_ScheduleCallIf>, function_process=0x6f9aa3 <CCTKi_ScheduleCallFunction>, data=0x7fffffffcc50) at /mnt/data/rhaas/postdoc/gr/Zelmani/src/schedule/ScheduleTraverse.c:584 #16 0x00000000006fd782 in ScheduleTraverseGroup (schedule_groups=0xb66e280, group=0xb682280, attributes=0xb681df0, n_whiles=0, whiles=0x0, n_ifs=0, ifs=0x0, item_entry=0x6f9548 <CCTKi_ScheduleCallEntry>, item_exit=0x6f9772 <CCTKi_ScheduleCallExit>, while_check=0x6f9981 <CCTKi_ScheduleCallWhile>, if_check=0x6f9a14 <CCTKi_ScheduleCallIf>, function_process=0x6f9aa3 <CCTKi_ScheduleCallFunction>, data=0x7fffffffcc50) at /mnt/data/rhaas/postdoc/gr/Zelmani/src/schedule/ScheduleTraverse.c:368 #17 0x00000000006fd92e in ScheduleTraverseGroup (schedule_groups=0xb66e280, group=0xb677520, attributes=0x0, n_whiles=0, whiles=0x0, n_ifs=0, ifs=0x0, item_entry=0x6f9548 <CCTKi_ScheduleCallEntry>, item_exit=0x6f9772 <CCTKi_ScheduleCallExit>, while_check=0x6f9981 <CCTKi_ScheduleCallWhile>, if_check=0x6f9a14 <CCTKi_ScheduleCallIf>, function_process=0x6f9aa3 <CCTKi_ScheduleCallFunction>, data=0x7fffffffcc50) at /mnt/data/rhaas/postdoc/gr/Zelmani/src/schedule/ScheduleTraverse.c:384 #18 0x00000000006fd4b1 in CCTKi_DoScheduleTraverse (group_name=0x75d82be "CCTK_POSTREGRIDINITIAL", item_entry=0x6f9548 <CCTKi_ScheduleCallEntry>, item_exit=0x6f9772 <CCTKi_ScheduleCallExit>, while_check=0x6f9981 <CCTKi_ScheduleCallWhile>, if_check=0x6f9a14 <CCTKi_ScheduleCallIf>, function_process=0x6f9aa3 <CCTKi_ScheduleCallFunction>, data=0x7fffffffcc50) at /mnt/data/rhaas/postdoc/gr/Zelmani/src/schedule/ScheduleTraverse.c:158 #19 0x00000000006f7f26 in ScheduleTraverse (where=0x75d82be "CCTK_POSTREGRIDINITIAL", GH=0xb68bae0, CallFunction=0x5260878 <Carpet::CallFunction(void*, cFunctionData*, void*)>) at /mnt/data/rhaas/postdoc/gr/Zelmani/src/main/ScheduleInterface.c:1360 #20 0x00000000006f6d78 in CCTK_ScheduleTraverse (where=0x75d82be "CCTK_POSTREGRIDINITIAL", GH=0xb68bae0, CallFunction=0x5260878 <Carpet::CallFunction(void*, cFunctionData*, void*)>) at /mnt/data/rhaas/postdoc/gr/Zelmani/src/main/ScheduleInterface.c:891 #21 0x00000000051f9def in Carpet::ScheduleTraverse (where=0x75d8233 "CallRegridInitialLevel", name=0x75d82be "CCTK_POSTREGRIDINITIAL", cctkGH=0xb68bae0) at /mnt/data/rhaas/postdoc/gr/Zelmani/arrangements/Carpet/Carpet/src/Initialise.cc:1360 #22 0x00000000051f86d5 in Carpet::CallRegridInitialLevel (cctkGH=0xb68bae0) at /mnt/data/rhaas/postdoc/gr/Zelmani/arrangements/Carpet/Carpet/src/Initialise.cc:1168 #23 0x00000000051f54c7 in Carpet::CallInitial (cctkGH=0xb68bae0) at /mnt/data/rhaas/postdoc/gr/Zelmani/arrangements/Carpet/Carpet/src/Initialise.cc:452 #24 0x00000000051f3365 in Carpet::Initialise (fc=0x7fffffffd710) at /mnt/data/rhaas/postdoc/gr/Zelmani/arrangements/Carpet/Carpet/src/Initialise.cc:124 #25 0x00000000006f18f3 in main (argc=2, argv=0x7fffffffd818) at /mnt/data/rhaas/postdoc/gr/Zelmani/src/main/flesh.cc:80 }}} The reason this happens seems to be that the data structures in dh are only valid once Recompose ran on this level (I think). Since global-early ,loop-local routines run before this happens, they see inconsistent data structures and trigger the out-of-bounds error in enter-level-mode. This is a recently triggerable issue, since before 55759e108807 Carpet would not call global-early routines in PostRegrid and the first such routine is HydroBase_InitExcisionMask which was recently made global-early, loop- local. Reverting these changes does not seem like a good option for the reasons outlined in #958. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/971> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #813: Fix all thorns that attempt reductions in local mode
by Einstein Toolkit 06 Jul '12

06 Jul '12

#813: Fix all thorns that attempt reductions in local mode -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: task | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Recently these produce a level three warning (simfactorie's default) whenever they attempt to do so and clutter the log files. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/813> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #969: cannot commit to NaNChecker
by Einstein Toolkit 05 Jul '12

05 Jul '12

#969: cannot commit to NaNChecker -------------------------------+-------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus website | Version: Keywords: subversion server | -------------------------------+-------------------------------------------- Trying to commit to NaNChecker I get: {{{ "svn-commit.tmp" 7L, 212C written Authentication realm: <https://svn.cactuscode.org:443> CactusCode Subversion Repository Password for 'rhaas': svn: Commit failed (details follow): svn: Server sent unexpected return value (500 Internal Server Error) in response to MKACTIVITY request for '/arrangements/CactusUtils/NaNChecker/!svn/act/7a34c55d-bdd2-413e-a7de- 9197062cee1b' svn: Your commit message was left in a temporary file: svn: '/mnt/data/rhaas/postdoc/gr/ET_trunk/arrangements/CactusUtils/trunk/svn- commit.tmp' }}} are the svn servers still experiencing problems (I remember there having been issues with users being asked to enter a password when using the https transport to check out code). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/969> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #968: ignore restricted points in NaNChecker, use OpneMP
by Einstein Toolkit 05 Jul '12

05 Jul '12

#968: ignore restricted points in NaNChecker, use OpneMP -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: NaNChecker | -----------------------------------+---------------------------------------- the attached patch 1 adds a new option ignore_restricted_points to NaNChecker which, if set, makes NaNChecker not complain about grid points for which a mask (by default CarpetReduce::weight, but its name is another parameter) is zero. This is useful for hydro runs to not abort a run if a NaN is found on a very coarse level where it will be overwritten afterwards. The second patch adds OpenMP to NaNChecker. It also converts to code to C++ and uses templates instead of macros. Both patches pass the testsuite in NanChecker (in their default setting). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/968> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #954: Rename configure scripts to "configure.sh"
by Einstein Toolkit 02 Jul '12

02 Jul '12

#954: Rename configure scripts to "configure.sh" -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Each thorn in ExternalLibraries has a script that configures it. For historic reasons these scripts all have different names. I propose to rename them all to "configure.*", where the suffix denotes the language (e.g. sh or pl). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/954> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac July 2012