Trac April 2013

trac@lists.einsteintoolkit.org

1 participants
178 discussions

[Einstein Toolkit] #1320: reconstruct_Wv with cell centering violates angular momentum conservation
by Einstein Toolkit 10 Apr '13

10 Apr '13

#1320: reconstruct_Wv with cell centering violates angular momentum conservation -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: rhaas Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- we have a bug report that at least for cell centering the option reconstruct_Wv (off by default) does not conserve angular momentum. This system where this was observed was a torus around a BH. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1320> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1318: Update hwloc to 1.7
by Einstein Toolkit 10 Apr '13

10 Apr '13

#1318: Update hwloc to 1.7 -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: ET_2013_05 Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The hwloc library distributed with the ET is currently at a pre-release version. I suggest to update to version 1.7, which has just been released. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1318> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1319: implement Josh Faber's hydro with punctures trick
by Einstein Toolkit 10 Apr '13

10 Apr '13

#1319: implement Josh Faber's hydro with punctures trick -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: task | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- implement [http://arxiv.org/abs/0708.2436] . Worked for UIUC, GT, and in similar form for Vassilios Mewes. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1319> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1313: GRHydro bugfixes
by Einstein Toolkit 10 Apr '13

10 Apr '13

#1313: GRHydro bugfixes -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- due to the code freeze, I will only propose bug fixes until the release branch has been created. Attached are three of those. The first one is related to Christian Reisswig's bugfixes in the excision handling, the second one is a trivial patch that affects how divB is computed (no change in output due to the variable in question being initialized to zero before). The last one reverts the meaning of the (newly introduced) parameters cyl_rho_inner and *_outer so that the values for _outer are used for large "r" and inner for small "r". -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1313> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #1312: quick rsync for simfactory
by Einstein Toolkit 09 Apr '13

09 Apr '13

#1312: quick rsync for simfactory -------------------------+-------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: development version Keywords: | -------------------------+-------------------------------------------------- Quite often I find myself developing something (code/parfiles) locally and use 'sim sync' to get it to a remote location. Until a recent change in simfactory this was usually quite fast (a couple of seconds at most). In all of these cases I know that I didn't change anything on the remote side. Now 'sim sync' can take a minute even to local machines, depending on their file system load since the remote side has to actually read the complete tree for comparison. And this is without any actual changes. I propose to have a 'sim sync --fast' option which uses timestamps as before. This should not be the default since it might not catch all changes in every situation, but it would make quick development sessions like this (edit locally, compile and run remotely) feasible again. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1312> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1197: ubunbu.cfg should default to use OpenMP
by Einstein Toolkit 08 Apr '13

08 Apr '13

#1197: ubunbu.cfg should default to use OpenMP -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- The current ubuntu.cfg option list in simfactory sets {{{ OPENMP = no }}} I would like to change this to "yes" instead. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1197> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1308: MPI: use library list provided by mpic++ instead of guessing (wrong)
by Einstein Toolkit 07 Apr '13

07 Apr '13

#1308: MPI: use library list provided by mpic++ instead of guessing (wrong) -----------------------------------+---------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2013_05 Component: EinsteinToolkit thorn | Version: development version Keywords: | -----------------------------------+---------------------------------------- At the moment, ExternalLibraries/MPI guesses that the library list for openmpi is just 'mpi mpi_cxx'. This is wrong in my case (even for the built library; I need additional libraries. The OpenMPI FAQ mentions this: "NOTE: It is absolutely not sufficient to simply add "-lmpi" to your link line and assume that you will obtain a valid Open MPI executable." They do recommend to use the compiler wrappers. I didn't try that, leaving a patch to a minimum. I would also not be sure how to replace to actual compilers using a thorn while it is supposedly being compiled - after the Cactus configure state (cannot do it before since the wrappers might not be build yet). Thus, I go the second way - also shown in the FAQ: I use mpic++ to get hold of the flags that are needed when linking against the library. This is very similar to what happens for some of the other ExternalLibraries as well (but a bit simpler since they also provide options to just get a list of the libraries, not including the flags themselves - which is what Cactus expects). In my case, this uses the libraries 'mpi_cxx mpi nsl util m m nsl util m dl openmp'. Especially the missing 'util' in the current list prevented me from linking. Adding it hard to the list however might be wrong on systems where this is not needed or that library might not even exist. (and this isn't the only missing library) I would like this to be included in the next release, as this would otherwise prevent people from building on at least some of the major Linux distros out of the box (Debian wheezy here) - or we would have to specify the library list by hand for these systems. Given the central part MPI plays I set this to 'major'. If we see problems with this approach we can still guess the missing libraries and try that, until after the release. OpenMPI FAQ: http://www.open-mpi.org/faq/?category=mpi-apps -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1308> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

[Einstein Toolkit] #1305: Building Einstein Toolkit requires using 'Build' twice
by Einstein Toolkit 05 Apr '13

05 Apr '13

#1305: Building Einstein Toolkit requires using 'Build' twice ----------------------------------------+----------------------------------- Reporter: srichers@… | Owner: sbrandt Type: defect | Status: new Priority: minor | Milestone: Component: Mojave | Version: Keywords: | ----------------------------------------+----------------------------------- When building a config in EinsteinToolkit for the first time the following errors come up: find: `configs/Cfg1/ThornList': No such file or directory find: `configs/Cfg1/config-data': No such file or directory find: `configs/Cfg1/config-info': No such file or directory Checking the folder in .mojaveconfig/projectname after the build reveals the files are present. Running build a second time completes successfully. This does not happen when running simfactory directly, nor does it happen when using Mojave to build the WaveToy demo. (note, optionfile allows building using 32 processes...just a timing issue?) -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1305> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 9

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac April 2013