Trac May 2011

trac@lists.einsteintoolkit.org

1 participants
122 discussions

[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

[Einstein Toolkit] #439: Job Chaining
by Einstein Toolkit 23 May '11

23 May '11

#439: Job Chaining ---------------------------+------------------------------------------------ Reporter: barry.wardell | Owner: mthomas Type: defect | Status: new Priority: blocker | Milestone: Component: SimFactory | Version: Keywords: job chaining | ---------------------------+------------------------------------------------ Currently job chaining only works with the first chained job. Subsequent chained jobs are incorrectly set to depend on the current active restart rather than the last queued restart. The attached patch fixes the problem, although I'm not sure if it's the correct approach. It just looks for the largest restart ID (without checking if that restart is in the queue) and sets the new job to depend on that. What is the 'correct' behavior in this situation? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/439> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

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

23 May '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: -----------------------------------------------------+---------------------- Changes (by eschnett): * status: new => review -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/437#comment:2> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

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

23 May '11

#437: Correct autoconfiguration of restrict keyword; add support for builtin_expect -----------------------------------------------------+---------------------- Reporter: Erik Schnetter <schnetter@…> | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Resolution: | Keywords: -----------------------------------------------------+---------------------- Changes (by eschnett): * reporter: anonymous => Erik Schnetter <schnetter@…> -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/437#comment:1> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #437: Correct autoconfiguration of restrict keyword; add support for builtin_expect
by Einstein Toolkit 23 May '11

23 May '11

#437: Correct autoconfiguration of restrict keyword; add support for builtin_expect -----------------------+---------------------------------------------------- Reporter: anonymous | Type: defect Status: new | Priority: minor Milestone: | Component: Cactus Version: | Keywords: -----------------------+---------------------------------------------------- While experimenting with several different compilers on Hopper, I noticed that some compilers do not support all the ways in which the "restrict" keyword can be used. I updated our autoconf macro to test more cases. I now also think it is not worthwhile to require the compiler to support the array syntax for function arguments, i.e. the syntax void foo (double A[restrict]); which (essentially) declares a pointer A using array syntax. One can instead use the syntax void foo (double *restrict const A); which is identical in almost all respects. The PGI compiler does not seem to support the array syntax, and disabling support for the restrict keyword does not seem to be worth the cost. I also add support for the gcc built-in function "builtin_expect", which tells the compiler the value that an expression is most likely to have, allowing compile-time optimisations based on this heuristic, and maybe avoiding branch penalties at run time. I also enabled the (currently commented out) definitions for attribute(hot) and attribute(cold), which tell the compiler that a function is either executed very often, or very rarely. This can also influence the optimiser. I attach a patch. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/437> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #328: TRAC frequently logs users out
by Einstein Toolkit 19 May '11

19 May '11

#328: TRAC frequently logs users out ----------------------------------+----------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit trac | Version: Keywords: | ----------------------------------+----------------------------------------- There seems to be some mechanism which is automatically logging users out of TRAC. This means that they end up posting as "anonymous" because they don't realise they are logged out. Probably there is a session cookie which expires or something. To avoid this, we could either try to change the logout (I would be happy if the automatic logout was just disabled completely), or make it much more obvious when you are not logged in. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/328> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

[Einstein Toolkit] #385: No link to wiki
by Einstein Toolkit 18 May '11

18 May '11

#385: No link to wiki -------------------------------------+-------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit website | Version: Keywords: | -------------------------------------+-------------------------------------- There is no (obvious) link to the wiki on the Einstein Toolkit web site. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/385> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #348: https://docs.einsteintoolkit.org/ does not redirect to the docs page
by Einstein Toolkit 18 May '11

18 May '11

#348: https://docs.einsteintoolkit.org/ does not redirect to the docs page -------------------------------------+-------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit website | Version: Keywords: docs | -------------------------------------+-------------------------------------- When I go to https://docs.einsteintoolkit.org/ it takes me to the list of CCT wikis. Based on the hostname, it should redirect to the correct page automatically. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/348> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac May 2011