Trac June 2012

trac@lists.einsteintoolkit.org

1 participants
175 discussions

[Einstein Toolkit] #737: simfactory sync can lead to inconsistent builds
by Einstein Toolkit 11 Feb '13

11 Feb '13

#737: simfactory sync can lead to inconsistent builds ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- simfactory's sync command uses rsync with the --archive (-a) option. This option set the modification date of files on the target machine to that on the source machine. This can lead to inconsistent builds in the following situation: [1] local: edit source_file.c [2] local: simfactory sync [3] local: edit source_file.c [4] remote: simfactory build [5] local: simfactory sync [6] remote: simfactory build [6] will not rebuild source_file.o since [5] set the modification time to that of [3] which which is older than [4] hence make will not consider source_file.o to be out-of-date. A simple fix is to add --no-times to the rsync options. Unfortunately this disables rsync's file modification time optimization and requires it to compute checksums on all files which can be very slow on slow filesystems. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/737> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #940: McLachlan dissipation error
by Einstein Toolkit 06 Feb '13

06 Feb '13

#940: McLachlan dissipation error -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- A kind person tells me: I wanted to mention what appears to be a mistake in your dissipation calculation. If you refer to Kreiss-Oliger, or equivalently to Dissipation/src/apply_dissipation.F77, you find that there is a sign flip at certain orders. For example, 3rd order dissipation to be used with 2nd order differencing, and 7th order dissipation to be used with 6th order differencing, both need a negative coefficient. But you don't appear to have such a minus sign (unless I missed it), and your parameter epsdiss is constrained to be positive. It looks to me like PDdissipationNth needs to be multiplied by something like (-1)^(fdOrder/2). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/940> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #815: Outlfow thorn in incoming
by Einstein Toolkit 06 Jan '13

06 Jan '13

#815: Outlfow thorn in incoming -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: optional | Milestone: Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- Hello all, as discussed in the last phone call, the GT Outflow thorn has been put into incoming (http://svn.einsteintoolkit.org/incoming/Outflow). From the docs: {{{ Outflow calculates the flow of rest mass density across a SphericalSurface, eg. and apparent horizon or a sphere at ``infinity''. }}} It has documentation, test-cases and publications using it (http://arxiv.org/abs/1201.4389). Ok to include in EinsteinAnalysis? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/815> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[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] #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] #663: thornlists within Cactus should get cleaned up
by Einstein Toolkit 01 Nov '12

01 Nov '12

#663: thornlists within Cactus should get cleaned up -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: development version Keywords: | -------------------------+-------------------------------------------------- Most of the thornlists in https://svn.cactuscode.org/Utilities/trunk/Thornlist* are out of date, and should get cleaned up. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/663> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

← Newer
1
...
5
6
7
8
9
10
11
...
18
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac June 2012