Trac June 2012

trac@lists.einsteintoolkit.org

1 participants
175 discussions

[Einstein Toolkit] #958: schedule hydrobase_InitExcisionmask global-early loop-local
by Einstein Toolkit 08 Jul '12

08 Jul '12

#958: schedule hydrobase_InitExcisionmask global-early loop-local ----------------------------------+----------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit trac | Version: Keywords: HydroBase | ----------------------------------+----------------------------------------- Christian Ott found that right now the scheduling of EinsteinUtil/SetMask_SphericalSurface::SetMask_SphericalSurface and HydroBase::HydroBase_InitExcisionMask conflict in the Post_Recover_Variables and INITIAL since SetMask_SphericalSurface which needs to run after HydroBase_InitExcisionMask is scheduled GLOBAL which happens to be global-late in these bins. SetMask_SphericalSurface must be local since it must run after SphericalSurfaceHasBeenSet which is after SphericalSurface_Set which is GLOBAL. The attached patch runs HydroBase_InitExcisionMask global-early loop-local instead. Pleas note that the patch will change the behaviour in PostRegrid slightly since HydroBase_InitExcisionMask (and not just SetMask_SphericalSurface which already does so) will run on all refinement levels, always, independent of the iteration counter and Carpet's do_every logic. The current code prevents properly recovering from checkpoints. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/958> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #813: Fix all thorns that attempt reductions in local mode
by Einstein Toolkit 06 Jul '12

06 Jul '12

#813: Fix all thorns that attempt reductions in local mode -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: task | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Recently these produce a level three warning (simfactorie's default) whenever they attempt to do so and clutter the log files. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/813> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 16

[Einstein Toolkit] #969: cannot commit to NaNChecker
by Einstein Toolkit 05 Jul '12

05 Jul '12

#969: cannot commit to NaNChecker -------------------------------+-------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus website | Version: Keywords: subversion server | -------------------------------+-------------------------------------------- Trying to commit to NaNChecker I get: {{{ "svn-commit.tmp" 7L, 212C written Authentication realm: <https://svn.cactuscode.org:443> CactusCode Subversion Repository Password for 'rhaas': svn: Commit failed (details follow): svn: Server sent unexpected return value (500 Internal Server Error) in response to MKACTIVITY request for '/arrangements/CactusUtils/NaNChecker/!svn/act/7a34c55d-bdd2-413e-a7de- 9197062cee1b' svn: Your commit message was left in a temporary file: svn: '/mnt/data/rhaas/postdoc/gr/ET_trunk/arrangements/CactusUtils/trunk/svn- commit.tmp' }}} are the svn servers still experiencing problems (I remember there having been issues with users being asked to enter a password when using the https transport to check out code). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/969> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #968: ignore restricted points in NaNChecker, use OpneMP
by Einstein Toolkit 05 Jul '12

05 Jul '12

#968: ignore restricted points in NaNChecker, use OpneMP -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: NaNChecker | -----------------------------------+---------------------------------------- the attached patch 1 adds a new option ignore_restricted_points to NaNChecker which, if set, makes NaNChecker not complain about grid points for which a mask (by default CarpetReduce::weight, but its name is another parameter) is zero. This is useful for hydro runs to not abort a run if a NaN is found on a very coarse level where it will be overwritten afterwards. The second patch adds OpenMP to NaNChecker. It also converts to code to C++ and uses templates instead of macros. Both patches pass the testsuite in NanChecker (in their default setting). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/968> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #954: Rename configure scripts to "configure.sh"
by Einstein Toolkit 02 Jul '12

02 Jul '12

#954: Rename configure scripts to "configure.sh" -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Each thorn in ExternalLibraries has a script that configures it. For historic reasons these scripts all have different names. I propose to rename them all to "configure.*", where the suffix denotes the language (e.g. sh or pl). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/954> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #967: GRHydro uses EOS_Omni routines without DECLARE_CCTK_FUNCTIONS
by Einstein Toolkit 29 Jun '12

29 Jun '12

#967: GRHydro uses EOS_Omni routines without DECLARE_CCTK_FUNCTIONS -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- and adding DECLARE_CCTK_FUNCTIONS eg. in ConservativeToPrimitive reveals that we pass scalars to EOS_Omni routines that would expect (1 element) arrays. Making them (pmin, epsmin, rhomin are affected) all arrays makes the code very ugly (even for GRHydro) :-). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/967> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #965: Carpet does not call global-early routines in POSTREGRID
by Einstein Toolkit 26 Jun '12

26 Jun '12

#965: Carpet does not call global-early routines in POSTREGRID --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- Carpet only calls routines on refinement levels that changed (did_recompose == true). However global-early is hard-wired to rl==0, which means it is never executed since reflevel 0 is never recomposed. Unfortunately this affects HydroBase_InitExcisionMask which ends up not being called (since #958). The error mode is not a fatal abort but was a more subtle change in data for Christian Reisswig. The attached patch attempts to fix this for EVOL and INITIAL. Ok to apply? While looking at this Christian Reisswig and I noticed that Carpet seems to call the routines on the finest level whenever any recompose happened. This is ok to ensure that global (also global-late) routines are called but also means that local routines are called. In cases where the finest level did not actually change (happens in core collapses we believe), this causes unnecessary calls to eg. MoL_PostStep with its attending SYNC calls. This might be candidate for optimization. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/965> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #942: GetComponents should not use shallow clones for Git checkouts
by Einstein Toolkit 25 Jun '12

25 Jun '12

#942: GetComponents should not use shallow clones for Git checkouts ---------------------------+------------------------------------------------ Reporter: hinder | Owner: eric9 Type: enhancement | Status: new Priority: major | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ GetComponents currently uses a "shallow clone" for Git repositories by default. This checks out only the repository information needed for the current version. Problems with shallow clones: * It is impossible to switch branches to another version after the initial clone. Since GetComponents checks out release branches using "git clone ...; git checkout ...", this means that release branches cannot be checked out using the default GetComponents options (see #934). This has to be fixed. * You cannot push or pull from/to a shallow clone. In fact, you can do very little with a shallow clone that you couldn't also do with source obtained from a tarball. Benefits of shallow clones: * You save a small amount of space and checkout time due to not including the (compressed) version history, which was the original rationale for using them (see #148). The checkout size of Carpet was measured to increase from 73 MB to 110 MB. There was discussion in #148 amounting to the idea of providing a two-tier Einstein Toolkit. The "developer tier" would be interested in full clones and authenticated repositories, and the "user tier" would be interested in shallow clones and non-authenticated (incorrectly conflated with "public") repositories. I strongly dislike this idea, and agree with the comments in that ticket which said that nearly all users of Cactus are also developers, and should be treated in the same way. Let's keep things simple and egalitarian. I do not consider the space-saving to be significant, even if this was representative of the ET as a whole, which it is not. Shallow clones are nonstandard and lead to problems and confusion. I propose removing support for shallow clones from GetComponents. If there are truly users of the ET who do not want to interact with version control systems at all, then we can accommodate these users by providing release tarballs, which will be much smaller, easier and faster to download. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/942> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #964: make "-a" default option for GetComponents
by Einstein Toolkit 25 Jun '12

25 Jun '12

#964: make "-a" default option for GetComponents ---------------------------+------------------------------------------------ Reporter: rhaas | Owner: eric9 Type: enhancement | Status: new Priority: minor | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ We seem to regularly receive support requests from users where GetComponents fails because they forgot to add the "-a" option. Since GetComponents is supposed to make checking out Cactus easier for novice users, I suggest changing its default options to reflect what is most likely required in this case. Having already the download of Cactus fail would turn me away from using it. For the developer that actually require write access, we should all be computer and version-control savy enough to either change the checkout afterwards or modify the thorn list. Its just a 'svn switch --relocate', '$EDITOR .git/config' and '$EDITOR repos/carpet_hg/.hg/hgrc' after all. So in summary I would like to suggest changing the default to "-a" possibly at the same time we change the defaults to --no-shallow -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/964> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #732: qc0-mclachlan example parameter file should be more functional
by Einstein Toolkit 22 Jun '12

22 Jun '12

#732: qc0-mclachlan example parameter file should be more functional -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- I propose adding wave extraction (using WeylScal4 and Multipole), as well as puncture tracking using PunctureTracker, to qc0-mclachlan.par. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/732> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

← Newer
1
...
11
12
13
14
15
16
17
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