Trac

trac@lists.einsteintoolkit.org

8708 discussions

[Einstein Toolkit] #441: Use LoopControl in WeylScal4
by Einstein Toolkit 08 Jun '11

08 Jun '11

#441: Use LoopControl in WeylScal4 -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- I suggest to use LoopControl in WeylScal4: $ svn diff Index: WeylScal4.m =================================================================== --- WeylScal4.m (revision 73) +++ WeylScal4.m (working copy) @@ -296,6 +296,7 @@ Calculations -> calculations, DeclaredGroups -> declaredGroupNames, PartialDerivatives -> derivatives, + UseLoopControl -> True, KeywordParameters -> keywordParameters, RealParameters -> realParameters, InheritedImplementations -> {"admbase", "methodoflines"}]; -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/441> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

Re: [ET Trac] [Einstein Toolkit] #437: Correct autoconfiguration of restrict keyword; add support for builtin_expect
by Einstein Toolkit 08 Jun '11

08 Jun '11

#437: Correct autoconfiguration of restrict keyword; add support for builtin_expect -----------------------------------------------------+---------------------- Reporter: Erik Schnetter <schnetter@…> | Owner: Type: defect | Status: review Priority: minor | Milestone: Component: Cactus | Version: Resolution: | Keywords: -----------------------------------------------------+---------------------- Comment (by barry.wardell): > I also add support for the gcc built-in function "builtin_expect" This sounds like potentially quite a nice addition. How difficult would it be to take this further and enable the use of profile guided optimization (eg. http://stackoverflow.com/questions/2738835/learning-sample-of-likely- and-unlikely-compiler-hints). Do you think it would be likely to help much? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/437#comment:4> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

2 1

Re: [ET Trac] [Einstein Toolkit] #437: Correct autoconfiguration of restrict keyword; add support for builtin_expect
by Einstein Toolkit 08 Jun '11

08 Jun '11

1 0

Re: [ET Trac] [Einstein Toolkit] #437: Correct autoconfiguration of restrict keyword; add support for builtin_expect
by Einstein Toolkit 08 Jun '11

08 Jun '11

1 0

Re: [ET Trac] [Einstein Toolkit] #437: Correct autoconfiguration of restrict keyword; add support for builtin_expect
by Einstein Toolkit 04 Jun '11

04 Jun '11

#437: Correct autoconfiguration of restrict keyword; add support for builtin_expect -----------------------------------------------------+---------------------- Reporter: Erik Schnetter <schnetter@…> | Owner: Type: defect | Status: review Priority: minor | Milestone: Component: Cactus | Version: Resolution: | Keywords: -----------------------------------------------------+---------------------- Comment (by hinder): I'm not sure I understand the array syntax issue. Is this only applicable to the restrict keyword, in which case it's probably fine, or does it also apply to declarations of the form void foo (double A[]); which I thought were standard C and should be supported by all compilers? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/437#comment:3> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #316: Checkpoint recovery nonfunctional
by Einstein Toolkit 23 May '11

23 May '11

#316: Checkpoint recovery nonfunctional ------------------------+--------------------------------------------------- Reporter: hinder | Owner: mthomas Type: defect | Status: new Priority: blocker | Milestone: Component: SimFactory | Version: Keywords: regression | ------------------------+--------------------------------------------------- Checkpoint recovery is nonfunctional in SimFactory 2 (it has broken since it was last fixed in ticket #60). Using the attached parameter file, I submit a simulation on Datura: simfactory2/bin/sim --machine datura --config sim2_datura create-submit parfiles/cptest.par 12 1:00:00 This parameter file terminates the Cactus run after 1 minute and dumps a checkpoint file. I then manually remove the output-0000-active symlink, as the automatic cleanup in the main() function is cleaning up restarts that are attempting to run, so I have disabled it, and manual cleanup doesn't work (see ticket #315). I then resubmit the simulation simfactory2/bin/sim --machine datura submit parfiles/cptest.par and observe that the checkpoint files from the first restart are never hardlinked into the output directory. The job does not recover, and instead starts from initial data. Log file is attached. Looking at the code, it appears that the checkpoint linking is conditional on the from-restart-id parameter being passed to simfactory, which I think is something to do with job-chaining. I can't see anywhere in the code which sets this option, so this is probably why the linking is not happening. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/316> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #435: double instead of CCTK_REAL in two routines in GRHydro
by Einstein Toolkit 23 May '11

23 May '11

#435: double instead of CCTK_REAL in two routines in GRHydro -----------------------------------+---------------------------------------- Reporter: jtao | Owner: Type: enhancement | Status: new Priority: optional | Milestone: ET_2011_11 Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- There are two places in GRHydro code that variables are declared using double. It will be better to use CCTK_REAL instead. It makes it easier to check various things by setting REAL_PRECISION in the config file. GRHydro/src/GRHydro_Con2PrimM_pt.c: register double ftmp,gtmp; GRHydro/src/GRHydro_Con2PrimM_pt.c: double gam_m1_o_gam = ((gammaeos-1.)/gammaeos); -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/435> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #344: Checkpointing + new cleanup procedure
by Einstein Toolkit 23 May '11

23 May '11

#344: Checkpointing + new cleanup procedure -------------------------+-------------------------------------------------- Reporter: mthomas | Owner: mthomas Type: enhancement | Status: new Priority: blocker | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- Attached to this ticket is the patch to fix checkpointing (which Ian has already reviewed) plus code implementing the new cleanup procedure. The new cleanup procedure is thus: 1. Automatic cleanup of every simulation is now gone. 2. Any command that creates a new restart (submit, user initiated run) calls restartlib.CleanupSimulation on that specific simulation, and CleanupSimulation will only attempt to do cleanup if it finds an active restart for that given simulation 3. sim cleanup without any arguments will cleanup all simulations. If you specify a specific simulation, it will only clean up that one. Still needing to be implemented are the times when cleanup of all simulations should happen, or the cleanup when a simulation finishes. These need to be done via cronjobs or some other method that hasn't quite been figured out yet. Please svn up to get the latest revision (I committed a bunch of very trivial code changes) then apply this patch and add comments to this ticket related to this patch. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/344> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #354: Patch: Do not clean up all simulations all the time
by Einstein Toolkit 23 May '11

23 May '11

#354: Patch: Do not clean up all simulations all the time -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: mthomas Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- The enclosed patch disables the global cleanup calll, and instead cleans up individual simulations as they are submitted. It also removes the "finished" attribute of restarts, which is not really necessary since one can instead look for the "*-active" symlink. It re-organises the code internally somewhat, as the current code assumes that restarts in the "U" (finished) state do not need to be cleaned up any more. In addition, it adds a set of TODO comments where the current code could be improved. This patch probably conflicts severely with Michael Thomas's patch addressing the same issue; I propose to combine both patches in some way before committing them. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/354> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #304: SimFactory should not clean-up so aggressively
by Einstein Toolkit 23 May '11

23 May '11

#304: SimFactory should not clean-up so aggressively ------------------------+--------------------------------------------------- Reporter: hinder | Owner: mthomas Type: defect | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- As far as I can tell, SimFactory 2 currently cleans up all simulations every time it is run. This is not scalable - if you are running with a slow production filesystem, just statting all the simulations could take a very long time. Similarly, if you do a sim sync, it currently cleans up all the simulations on your local machine, as well as the remote machine. Running sim --help even cleans up all your simulations! This behaviour is very counter-intuitive (certainly not what a user would expect) and not suitable for production systems. I propose that simfactory should only clean up the simulation which is being referred to in the current command. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/304> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac