Trac November 2012

trac@lists.einsteintoolkit.org

1 participants
156 discussions

[Einstein Toolkit] #1180: new option to save build logs of each compiled file
by Einstein Toolkit 19 Nov '12

19 Nov '12

#1180: new option to save build logs of each compiled file -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- It would be convenient to have an option to automatically generate a log of building Cactus. This can usually be done just by piping the output of the 'make' command into a file, but for parallel builds this gets mixed up. It would be nice to have the output instead done by Cactus itself, on a file-by-file basis and, once done with a thorn, combined into a 'thorn- wide log' and once done with all thorns into an overall log file. This would then make it much easier to post-process such logs, e.g., for analysis of occurring compiler warnings. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1180> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1162: Slowdown due to gethostbyname
by Einstein Toolkit 19 Nov '12

19 Nov '12

#1162: Slowdown due to gethostbyname --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- When running the ET testsuite on my laptop, I found it was taking 7 minutes to run just the tests from the McLachlan arrangement. The CPU usage was negligible for much of the time. I noticed that when running an empty parameter file, there was a slowdown before printing the host name. Additionally, when I attached a debugger to find out why cactus was taking so long to run the tests, the backtrace showed: {{{ 0x00007fff90f0dd16 in kevent () (gdb) bt #0 0x00007fff90f0dd16 in kevent () #1 0x00007fff954c390a in _mdns_search () #2 0x00007fff954c3345 in mdns_hostbyname () #3 0x00007fff954c31c1 in search_host_byname () #4 0x00007fff954c30c1 in gethostbyname () #5 0x00000001096becf8 in Util_GetHostName (name=0x7fff56551550 "macbook", length=255) at Network.c:86 }}} Util_GetHostName first calls gethostname, and if that function returns something with no "." in it, it calls gethostbyname. Indeed, my local hostname does not have a "." in it. This is on Mac OS 10.8.2. Changing the hostname via {{{ sudo scutil --set HostName Ians-MacBook-Pro.local }}} so the hostname included a ".", the tests now run in 1m30s. I don't know why gethostbyname is so slow on my system. Does Cactus, or maybe simfactory, or maybe the test system, call gethostbyname very frequently? Perhaps the output could be cached if this call can sometimes be slow. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1162> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1182: Ensure that all computed quantities in WeylScal4 have regression tests
by Einstein Toolkit 19 Nov '12

19 Nov '12

#1182: Ensure that all computed quantities in WeylScal4 have regression tests -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: WeylScal4 | -----------------------------------+---------------------------------------- We currently have regression tests for the Psi4 variable computed by the WeylScal4 thorn. We should also have tests for the other quantities (the other Weyl scalars and the invariants computed from them). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1182> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #865: Add autoconf macro to test for OpenMP collapse statement
by Einstein Toolkit 17 Nov '12

17 Nov '12

#865: Add autoconf macro to test for OpenMP collapse statement ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/865> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1178: unused Fortran function arguments (here in EOS_IdealFluid)
by Einstein Toolkit 16 Nov '12

16 Nov '12

#1178: unused Fortran function arguments (here in EOS_IdealFluid) -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- In an effort to get rid of some of the warnings I wonder what the best way in Fortran is to suppress warnings about unused function arguments. Is there an 'unused' keyword? I any case: the quick solution I came up with is in the patch: 'var=var' - hopefully optimized away by the compiler. It silences the warning. See attached patch. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1178> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1176: Compilation of Recompose.cc fails with gcc-4.7 and OpenMP
by Einstein Toolkit 15 Nov '12

15 Nov '12

#1176: Compilation of Recompose.cc fails with gcc-4.7 and OpenMP -------------------------------------+-------------------------------------- Reporter: david.radice@… | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: ET_2012_05 Keywords: | -------------------------------------+-------------------------------------- I am trying to compile the latest release of the Einstein Toolkit, Ørsted, on my laptop (Fedora 17, gcc-4.7.2), but I get the following error if I try to compile with OpenMP: /home/davide/Desert/CactusOersted/configs/charon/build/Carpet/Recompose.cc:2071:2: error: stray ‘#’ in program the error disappears if I compile with no OpenMP support. I can also compile without problems, using the same thornlist and with OpenMP support, on our local cluster with the Intel compiler. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1176> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #695: Don't buffer output from configuration scripts
by Einstein Toolkit 15 Nov '12

15 Nov '12

#695: Don't buffer output from configuration scripts ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- Output from configuration scripts is buffered, and is only output after the script has finished. This is inconvenient for long-running scripts. Instead, the output should be shown right away. This buffering is done in file lib/sbin/ConfigScriptParser.pl, which uses Perl backquotes `` to collect all of the script's output. Instead, Cactus should use a pipe to read the script's output line-by-line, and process it immediately. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/695> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1177: McLachlan in ET/master needs an updated KrancNumericalTools/GenericFD
by Einstein Toolkit 15 Nov '12

15 Nov '12

#1177: McLachlan in ET/master needs an updated KrancNumericalTools/GenericFD ----------------------+----------------------------------------------------- Reporter: knarf | Owner: hinder Type: defect | Status: new Priority: critical | Milestone: Component: Kranc | Version: development version Keywords: | ----------------------+----------------------------------------------------- McLachlan in ET/master needs (among other things) kisgn(), which is defined in Kranc/Tools/CodeGen/CodeGenCactus.m, but not mentioned in KrancNumericalTools/GenericFD/src/GenericFD.h. Could it be that something needs to be updated from the Mathematica sources? {{{ COMPILING /home/knarf/Cactus/arrangements/McLachlan/ML_BSSN/src/ML_BSSN_RHS1.cc /home/knarf/Cactus/configs/sim/build/ML_BSSN/ML_BSSN_RHS1.cc: In function ‘void ML_BSSN_RHS1_Body(const cGH*, int, int, const double*, const double*, const double*, const int*, const int*, int, double* const __restrict__*)’: /home/knarf/Cactus/configs/sim/build/ML_BSSN/ML_BSSN_RHS1.cc:648: error: ‘kisgn’ was not declared in this scope }}} -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1177> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #163: Assertion `tl>=0 and tl<timelevels' failed error
by Einstein Toolkit 13 Nov '12

13 Nov '12

#163: Assertion `tl>=0 and tl<timelevels' failed error ------------------------------------+--------------------------------------- Reporter: azebrowski@… | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | ------------------------------------+--------------------------------------- I'm currently running a Cactus simulation based off the ET mclachlan parameter file. I have some custom thorns which force checkpointing every iteration, and then write new parameter files. The new parameter files are used to run specific functions from the host simulation ("spawning"), but I'm having some problems resuming simulations. Currently, I get this error when resuming: INFO (Carpet): GF: rhs: 818k active, 1440k owned (+76%), 1896k total (+32%), 328 steps/time cactus_sim: /home/azebrowski/Cactus/arrangements/Carpet/CarpetLib/src/th.hh:79: double th::get_time(int, int, int) const: Assertion `tl>=0 and tl<timelevels' failed. [cyder:32759] *** Process received signal *** [cyder:32759] Signal: Aborted (6) I'm guessing there's a parameter I'm not setting properly in my child simulation, could anyone give me a pointer to where I should be looking? I looked for things relating to timelevels in the host/spawned parameter files, but didn't see anything that stood out. My parameter files used and full output are attached to this email, with the disclaimer that I modified the spawned parameter file to run every function instead of skipping some in an attempt to bypass any problems that could be caused by skipping some Carpet function on accident. I've made a bzipped tarball containing the checkpointed data from the simulation. It contains several parameter files. The parameter file of interest here is spawn.par, as it doesn't use any of my custom code but still causes Cactus to abort with an error. I left the other parameter files in on the off chance that I might need to refer to them later. Here is the source parameter file, which creates the spawned simulation: http://www.cct.lsu.edu/~azebrowski/ml-ahfinder-spawn.par Here is the spawned simulation's parameter file: http://www.cct.lsu.edu/~azebrowski/spawn.par Here is the full checkpointed data and another copy of the spawned parameter file: http://www.cct.lsu.edu/~azebrowski/data.tar.bz2 Other information: I ran the simulation using OpenMP with 12 cores to generate the checkpointed data. I've also tried MPI, but that didn't seem to make a difference. Thornlist: http://www.cct.lsu.edu/~azebrowski/ThornList gcc: azebrowski@cyder:~/Cactus$ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable- shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) Fortran is gfortran-4.4 I'm using the Mercurial version of Carpet, and the ET development thorns. If you need more information, please let me know. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/163> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #945: add higher order restriction parameter to cell-centerd Carpet
by Einstein Toolkit 13 Nov '12

13 Nov '12

#945: add higher order restriction parameter to cell-centerd Carpet -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: CarpetLib | -----------------------------------+---------------------------------------- the attached patch adds a 3rd order accurate restriction operator to Carpet. It is used only for cell-centered runs, for grid functions whose prolongation operator is *not* ENO or WENO (ie. non matter variables only). It should be completely invisible if CarpetLib:use_cc_o3 is false (which of course is the default). It offers third-order accurate restriction operators for cell centered grids when use_cc_o3 is set. This interpolation is done for samples at the cell centres (so this is not a ppm scheme or anything like that). It really only fits a polynomial of the form \sum_{i,j,k=0}^3 a_{i,j,k} x^i y^j z^k to the fine cells and evaluates at x=y=z=0. So it is good for the metric, but bad for matter (since it will destroy the conservation). Because of this it is not used for grid functions whose transport operator is not WENO or ENO which hopefully excludes all matter variables. I also attach a patch for a modified WaveToyMoL thorn that I used for testing. When test_restriction is set, then it puts a 3rd order polynomial (with some random coefficients) into phi and the differences between the restricted value and what should be there into psi. The wavetoymol thorn right now inherits from CarpetEvolutionMask since I am also working on making this functional again (seems to be ok now). Finally attached is a parameter file to test it. You should find a region inside of reflevel 0 of psi where psi is exactly zero. This is where the restriction works as expected. Further improvements would be to not have the selection for 3rd order done by a global carpetlib parameter but instead by a grid function tag (or a global carpet paarameter). This change could also be made to the eno/weno operators which contain special logic to use ENO for prolongation_order_space = 3 and 5 both. Ok to apply (or are there large scale changes to Carpet that are currently private)? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/945> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac November 2012