Trac September 2011

trac@lists.einsteintoolkit.org

1 participants
184 discussions

[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] #350: Autogenerating cctk_Loop.h
by Einstein Toolkit 17 Jun '12

17 Jun '12

#350: Autogenerating cctk_Loop.h -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- I wrote a perl script to auto-generate the Cactus header file Cactus/src/include/cctk_Loop.h.The script writes the code to stdout. I attach it to this ticket, as well as the output it generates. I suggest to keep this perl script next to its output in the include directory, and to run it manually whenever required. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/350> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 17

[Einstein Toolkit] #215: Driscoll&Healy integration for Multipole
by Einstein Toolkit 16 Jun '12

16 Jun '12

#215: Driscoll&Healy integration for Multipole -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- The attached patch implements a more accurate integration over the sphere, using an algorithm by Driscoll & Healy. This algorithm uses Gaussian integration weights, leading (almost) to exponential convergence. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/215> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #512: Run testsuite in "distribute" script
by Einstein Toolkit 15 Jun '12

15 Jun '12

#512: Run testsuite in "distribute" script -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- Run the testsuite in the distribute script. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/512> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #515: Silently overrides DEBUG and OPTIMISE options
by Einstein Toolkit 15 Jun '12

15 Jun '12

#515: Silently overrides DEBUG and OPTIMISE options ---------------------------+------------------------------------------------ Reporter: barry.wardell | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ---------------------------+------------------------------------------------ When building a configuration with SimFactory, no matter what is set in the OptionList it sets the DEBUG and OPTIMISE options based on its own --optimise and --debug options, which default to enabling optimisation and disabling debug. This means that even if I have an OptionList with DEBUG="yes", SimFactory will silently change this to DEBUG="no". This is very unexpected and should not happen. I think SimFactory should respect what is set in the OptionList and never change it. The attached patch disables the overriding of all OptionList settings. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/515> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #429: Parallelising AEILocalInterp
by Einstein Toolkit 17 May '12

17 May '12

#429: Parallelising AEILocalInterp -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The enclosed patch parallelises AEILocalInterp via OpenMP. This leads to a slight change in behaviour. Currently, AEILocalInterp traverses the list of points sequentially, and aborts when the first error is encountered. After parallelisation, there is no fixed order in which the points are traversed, and if several errors are encountered, any one of the errors may be returned, not necessarily the first. I am not aware of any thorn that would or should rely on such an ordering. This patch also adds "restrict" and "const" statements that may improve performance as it gives the compiler more information about dependencies between pointers. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/429> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #281: compile error is not linked
by Einstein Toolkit 16 May '12

16 May '12

#281: compile error is not linked --------------------+------------------------------------------------------- Reporter: knarf | Owner: sbrandt Type: defect | Status: new Priority: minor | Milestone: Component: Moyave | Version: Keywords: | --------------------+------------------------------------------------------- Info: Simfactory command: /home/knarf/utils/simfactory/lib/sim.py "build" "sim" "--thornlist" "NewSchedule/NewSchedule.th" "--optimise" Info: Version 1195M The Simulation Factory: Manage Cactus simulations Info: defs: /home/knarf/utils/simfactory/etc/defs.ini Info: defs.local: /home/knarf/utils/simfactory/etc/defs.local.ini Info: Executing command: build Using configuration: sim Info: Cactus Directory: /home/knarf/Cactus_NewSchedule Info: HasStoredOptions: True Info: Use stored options list: /home/knarf/Cactus_NewSchedule/configs/sim/OptionList Info: optionlist is: /home/knarf/Cactus_NewSchedule/configs/sim/OptionList Info: hasOutdatedConfig: False Info: build_reconfig: False Info: build_clean: False Info: removeConfig: False SubmitScript is: None Info: RunScript is: /home/knarf/utils/simfactory/mdb/runscripts/debian- lenny-gcc.sh Info: ThornList is: /home/knarf/Cactus_NewSchedule/NewSchedule/NewSchedule.th Building sim ________________________________________________________________________ Cactus - version: 4.0.b17 Building configuration sim ________________________________________________________________________ Checking status of thorn BLAS ________________________________________________________________________ Checking status of thorn Boundary ________________________________________________________________________ ________________________________________________________________________ Checking status of thorn Vectors ________________________________________________________________________ /home/knarf/Cactus_NewSchedule/arrangements/CactusBase/Boundary/src/Check.c:18:2: error: #error "die" Preprocessing /home/knarf/Cactus_NewSchedule/arrangements/CactusBase/Boundary/src/Check.c Compiling /home/knarf/Cactus_NewSchedule/arrangements/CactusBase/Boundary/src/Check.c Checking status of thorn IOUtil ________________________________________________________________________ ________________________________________________________________________ /home/knarf/Cactus_NewSchedule/arrangements/CactusBase/Boundary/src/Check.c:18:2: error: #error "die" make[3]: *** [Check.c.o] Error 1 make[2]: *** [make.checked] Error 2 make[1]: *** [/home/knarf/Cactus_NewSchedule/configs/sim/lib/libthorn_Boundary.a] Error 2 make[1]: *** Waiting for unfinished jobs.... ________________________________________________________________________ make[1]: *** wait: No child processes. Stop. make: *** [sim] Error 2 Info: executing command: /bin/bash -c '{ :; } && { cd /home/knarf/Cactus_NewSchedule && nice make -j3 sim 2>&1; }' Error while executing command "/bin/bash -c '{ :; } && { cd /home/knarf/Cactus_NewSchedule && nice make -j3 sim 2>&1; }'": Command returned exit status 2 -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/281> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #525: Clean up CCTK_GFINDEX definitions
by Einstein Toolkit 11 May '12

11 May '12

#525: Clean up CCTK_GFINDEX definitions -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- The way in which CCTK_GFINDEX is defined is a bit complex, probably unnecessarily so. The file cctk.h distinguishes between compilers which support inlining and compilers which don't. This is probably useless these days since every compiler supports inlining, and if not, we don't really expect it to be fast. If the compiler supports inlining, we define static inline functions, which may or may not check array indices. If the compiler does not support inlining, and if CCTK_DEBUG is defined, then we use regular functions defined in DebugDefines.c, otherwise (i.e. without CCTK_DEBUG) we use macros. Overall, the indexing functions are defined three times, including once as macros. I suggest to simplify this, based on the assumption that every fast compiler supports inlining. I assume so because (a) the ubiquity of C++, which relies heavily on inlining, and (b) C99 officially introduced inlining 12 years ago. The new setup would have "static inline" definitions (without index checking) in cctk.h, and would have regular functions (with index checking) in DebugDefines.c, and would choose between these two implementations via CCTK_DEBUG. This would eliminate the macros, and would eliminate the case distinction based on whether the compiler supports inlining. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/525> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #262: make error messages in ReflectionSymmetry more informative
by Einstein Toolkit 11 May '12

11 May '12

#262: make error messages in ReflectionSymmetry more informative --------------------------------------------+------------------------------- Reporter: roland.haas@… | Type: enhancement Status: new | Priority: minor Milestone: | Component: Cactus Version: | Keywords: --------------------------------------------+------------------------------- this small patch includes the value of ierr in ReflectionSymmetries error messages -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/262> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #588: simfactory tries to create the scratch directory when submitting the job
by Einstein Toolkit 07 May '12

07 May '12

#588: simfactory tries to create the scratch directory when submitting the job ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- on some machines the desired scratch directory is not visible from the head node but is compute node local (eg. kraken I think or zwicky for sure). Simfactory should not try to create the scratch directory on the node that runs qsub but rather inside of the runscript or submitscript. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/588> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

← Newer
1
2
3
4
5
6
7
8
9
...
19
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac September 2011