Trac July 2012

trac@lists.einsteintoolkit.org

1 participants
161 discussions

[Einstein Toolkit] #591: Add harmonic shift to McLachlan
by Einstein Toolkit 15 Apr '13

15 Apr '13

#591: Add harmonic shift to McLachlan -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: McLachlan | -----------------------------------+---------------------------------------- The attached patch adds a harmonic shift condition to McLachlan. It does this by introducing a new real-valued parameter harmonicShift. This should be set to 0 for gamma-driver shift (the default, and the existing behaviour), and to 1 for harmonic shift. This is useful for code- correctness tests with the shifted gauge wave which is an exact solution of the Einstein equations in harmonic gauge. The harmonic shift equation has been tested with the shifted gauge wave exact solution and yields convergence to the exact solution. The current way that gauge conditions is handled in McLachlan is not very elegant, and I don't think this patch should be applied as-is. I am putting it here for anyone who might find it useful. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/591> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #624: Replace Cactus complex number implementation with C/C++ standard implementation
by Einstein Toolkit 08 Mar '13

08 Mar '13

#624: Replace Cactus complex number implementation with C/C++ standard implementation -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Cactus offers CCTK_COMPLEX. This maps to the standard datatype in Fortran, but not in C or C++. It should map to the standard datatypes in C and C++ as well, so that the growing body of code written in C and C++ can reasonably make use of complex numbers. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/624> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #950: "Correct" Weyl Scalar symmetries
by Einstein Toolkit 19 Feb '13

19 Feb '13

#950: "Correct" Weyl Scalar symmetries ---------------------------------+------------------------------------------ Reporter: yosef@… | Type: defect Status: new | Priority: major Milestone: | Component: Other Version: | Keywords: ---------------------------------+------------------------------------------ RotatingSymmetry180 and the ReflectionSymmetry thorns define a tensor alias "weylscalars_real", but the symmetries given there do not correspond to those of the usual re[psi0], im[psi0], re[psi1], im[psi1], etc scalars. The Weyl symmetries as provided in RotatingSymmetry180 static int const weylparities[10][3] = {{+1,+1,+1}, {-1,-1,-1}, {+1,+1,+1}, {-1,-1,-1}, {+1,+1,+1}, {-1,-1,-1}, {+1,+1,+1}, {-1,-1,-1}, {+1,+1,+1}, {-1,-1,-1}}; The symmetries for rpsi0, ipsi0, rpsi1, ipsi1, ..., rpsi4, ipsi4 static int const weylparities[10][3] = {{+1,+1,+1}, /* rpsi0 */ {-1,-1,-1}, /* ipsi0 */ {+1,+1,-1}, /* rpsi1 */ {-1,-1,+1}, /* ipsi1 */ {+1,+1,+1}, /* rpsi2 */ {-1,-1,-1}, /* ipsi2 */ {+1,+1,-1}, /* rpsi3 */ {-1,-1,+1}, /* ipsi3 */ {+1,+1,+1}, /* rpsi4 */ {-1,-1,-1}}; /* ipsi4 */ attached is a diff between the current ET version of the Reflection and RotatingSymmetry180 thorns and the "corrected" version. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/950> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[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

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac July 2012