Trac

trac@lists.einsteintoolkit.org

8708 discussions

[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

[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] #1175: Improving the treatment of external libraries
by Einstein Toolkit 12 Nov '12

12 Nov '12

#1175: Improving the treatment of external libraries -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- There are two tickets (#1006 and #1170) which address shortcomings in the current handling of external libraries in Cactus. I think that the handling of external libraries needs a bit of a redesign, and have created a wiki page (https://docs.einsteintoolkit.org/et- docs/Improving_the_treatment_of_external_libraries) containing a summary of my view of the current situation, and a draft proposal for what to do about it. Perhaps there are other approaches, maybe radically different! Or maybe the current system is the best we can have, for practical reasons. In any case, I think we should have a discussion about this. Please take a look and add notes or comments either in the text of the page or as comments to this ticket. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1175> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1159: GRHydro_Init_Data
by Einstein Toolkit 08 Nov '12

08 Nov '12

#1159: GRHydro_Init_Data -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- attached please find patches for GRHydro_Init_Data that were produce during the workshop at RIT. Unless there are objections I will apply them on Friday. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1159> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #1160: GRHydro update
by Einstein Toolkit 08 Nov '12

08 Nov '12

#1160: GRHydro update -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- attached please find patches for the changes applied during the workshop at RIT as well as some of the older ones from Zelmani. Unless there are objections I will apply them on Friday. With these, Zelmani and trunk agree up to whitespace and support for EvolutionMask. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1160> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac