Trac October 2012

trac@lists.einsteintoolkit.org

1 participants
189 discussions

[Einstein Toolkit] #1092: et trac server quite slow
by Einstein Toolkit 27 Nov '12

27 Nov '12

#1092: et trac server quite slow -------------------------------------+-------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit website | Version: Keywords: | -------------------------------------+-------------------------------------- The ET trac server responds rather slowly right now. Eg. {{{ [rhaas@zwicky ~]$ time wget https://trac.einsteintoolkit.org --2012-09-14 15:54:54-- https://trac.einsteintoolkit.org/ Resolving trac.einsteintoolkit.org... 130.39.21.34 Connecting to trac.einsteintoolkit.org|130.39.21.34|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 38172 (37K) [text/html] Saving to: `index.html' 100%[===============================================================================================================================================================================>] 38,172 239K/s in 0.2s 2012-09-14 15:55:09 (239 KB/s) - `index.html' saved [38172/38172] real 0m14.766s user 0m0.013s sys 0m0.007s }}} ie. 14s to get the top level webpage. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1092> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #620: Simplify timelevel handling for Cactus thorn writers
by Einstein Toolkit 21 Nov '12

21 Nov '12

#620: Simplify timelevel handling for Cactus thorn writers -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Currently, a thorn writer must declare the maximum number of timelevels for a variable in the interface.ccl file, then allocate a specific number of timelevels for which storage is allocated in the schedule.ccl file. There are rules for how many timelevels a variable should have. For example, to evolve using MoL I think you need at least two, whereas to evolve using mesh refinement with time prolongation order 2 you need three. The problem is that the person writing the thorn shouldn't have to know how it is going to be used. If I write an evolution thorn, I should not care whether it is used with mesh refinement or not. I certainly shouldn't have to care what prolongation order is going to be used. Would it be possible for Cactus to automatically determine the number of timelevels needed for a given variable? My proposal is that it should not be necessary for the user to specify the number of timelevels in the interface.ccl or schedule.ccl file for variables declared in that thorn. The only time a thorn writer should have to do that is if that thorn specifically uses the other timelevels. For example, a thorn which couples to MoL will probably only ever read or write to the current timelevel. MoL, on the other hand, could tell Cactus that it needs a certain number of timelevels at runtime for those variables. Similarly for mesh refinement. This goes along with the planned changes to the scheduling system to make it easier to program Cactus thorns and make it harder to make errors. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/620> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[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] #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] #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

[Einstein Toolkit] #1020: Reduce WeylScal4 code size
by Einstein Toolkit 12 Nov '12

12 Nov '12

#1020: Reduce WeylScal4 code size -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The attached patch reduces the size of the auto-generated code of WeylScal4 by introducing some strategic temporary variables. This prevents a build failure on BlueGene/Q. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1020> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #434: Keep track of masked-out volume in CarpetMask
by Einstein Toolkit 08 Nov '12

08 Nov '12

#434: Keep track of masked-out volume in CarpetMask -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- Keep track of the volume that is masked out by CarpetMask, and take this volume into account when checking in CarpetReduce that the integral over the simulation domain equals the domain volume. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/434> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 30

[Einstein Toolkit] #1119: hdf5toascii_slicer should output variable names in headers
by Einstein Toolkit 06 Nov '12

06 Nov '12

#1119: hdf5toascii_slicer should output variable names in headers -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- CarpetIOASCII currently puts something like {{{ # data columns: 13:rho }}} into its headers. hdf5toascii_slicer does not. It would be useful if the relavant code was copied into the slicer (from outputslice.cc). Particularly useful if one translates a checkpoint file to ASCII to inspect values in detail. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1119> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1157: simfactory option list for Mac OSX
by Einstein Toolkit 01 Nov '12

01 Nov '12

#1157: simfactory option list for Mac OSX -----------------------------+---------------------------------------------- Reporter: pf289@… | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -----------------------------+---------------------------------------------- In the option list for osx-lion-macports-gcc.cfg it says that one should have installed the following macports: szip, gcc46, fftw, fftw-3, gsl, openssl, hdf5-18 +gcc46 -universal, zlib, openmpi +gcc46 With these ports installed, the following compiler error occurs: ld: library not found for -lhdf5hl_fortran collect2: ld returned 1 exit status make[1]: *** [/Users/paufigueras/Universitat/Cactus/exe/cactus_testconfig] Error 1 make: *** [testconfig] Error 2 To fix it, one should install the hdf5 port with the fortran variant. In other words, in the ports list above one should replace: hdf5-18 +gcc46 -universal -> hdf5-18 +fortran +gcc46 -universal -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1157> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

← Newer
1
...
9
10
11
12
13
14
15
...
19
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac October 2012