Trac November 2012

trac@lists.einsteintoolkit.org

1 participants
156 discussions

[Einstein Toolkit] #1190: The default for WARN should be 'yes' in simfactory option lists
by Einstein Toolkit 30 Nov '12

30 Nov '12

#1190: The default for WARN should be 'yes' in simfactory option lists -------------------------+-------------------------------------------------- Reporter: knarf | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: development version Keywords: | -------------------------+-------------------------------------------------- I propose to change the default for WARN in simfactory option lists (for generic machines, especially osx*.cfg and sl6.cfg) to "yes". Most other option lists already follow that. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1190> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1189: Make data parameter of expression evaluation functions const
by Einstein Toolkit 30 Nov '12

30 Nov '12

#1189: Make data parameter of expression evaluation functions const -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- The data argument of Util_ExpressionEvaluate, and of the evaluator functions it uses, should be const. data is a pointer to user-supplied data used for evaluating the expression. It should not be modified by the evaluation. Note that this modifies the flesh API to the (undocumented) thorn-visible function Util_ExpressionEvaluate. The attached patch makes this modification as well as modifying the evaluators in the flesh. OK to apply? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1189> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1153: Do not describe outdated flesh MPI options in UsersGuide/Notes.txt
by Einstein Toolkit 29 Nov '12

29 Nov '12

#1153: Do not describe outdated flesh MPI options in UsersGuide/Notes.txt ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | ----------------------+----------------------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1153> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #1003: Add optional support for CarpetEvolutionMask to GRHydro
by Einstein Toolkit 29 Nov '12

29 Nov '12

#1003: Add optional support for CarpetEvolutionMask to GRHydro -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: GRHydro | -----------------------------------+---------------------------------------- the attached patch adds access to CarpetEvolutionMask's evolution mask to GRHydro. CarpetEvolutionMaks tracks which points on each level contribute to the final answer, roughly speaking anything that would show up in a call to the interpolators. The functional change to GRHydro is trivial (just a parameter, a GF access and a cycle in the routine that checks for C2P failures). However getting the equivalent of CCTK_VarDataPtr to work in Fortran turned out to be ugly. Better solutions are very welcome. Desired features are: * easy to use * not error prone * allows to run GRHydro without CarpetEvolutionMask (this means inheriting won't work) * low memory footprint -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1003> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #1188: GetComponents should output the total number of components to be downloaded
by Einstein Toolkit 29 Nov '12

29 Nov '12

#1188: GetComponents should output the total number of components to be downloaded ---------------------------+------------------------------------------------ Reporter: hinder | Owner: eric9 Type: enhancement | Status: new Priority: major | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ If GetComponents outputs the total number of components it is about to download, then Mohave will be able to give a better progress report. This would also be helpful for users as they can see how far through the process they are. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1188> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1179: Add dtlapse_evolution method to Exact
by Einstein Toolkit 27 Nov '12

27 Nov '12

#1179: Add dtlapse_evolution method to Exact -----------------------------------+---------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: Exact | -----------------------------------+---------------------------------------- The attached patch actually does two things: 1. adds dtlapse_evolution method and dtshift_evolution method options 'exact' to the respective ADMBase keywords 1. schedules metric initialization in MoL_PostStep (in addition to CCTK_PRESTEP) which is in line with what the current gauge initialization routine does -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1179> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1092: et trac server quite slow
by Einstein Toolkit 27 Nov '12

27 Nov '12

#1092: et trac server quite slow -------------------------------------+-------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: EinsteinToolkit website | Version: Keywords: | -------------------------------------+-------------------------------------- The ET trac server responds rather slowly right now. Eg. {{{ [rhaas@zwicky ~]$ time wget https://trac.einsteintoolkit.org --2012-09-14 15:54:54-- https://trac.einsteintoolkit.org/ Resolving trac.einsteintoolkit.org... 130.39.21.34 Connecting to trac.einsteintoolkit.org|130.39.21.34|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 38172 (37K) [text/html] Saving to: `index.html' 100%[===============================================================================================================================================================================>] 38,172 239K/s in 0.2s 2012-09-14 15:55:09 (239 KB/s) - `index.html' saved [38172/38172] real 0m14.766s user 0m0.013s sys 0m0.007s }}} ie. 14s to get the top level webpage. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1092> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[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] #1185: Automate auto-generating code
by Einstein Toolkit 21 Nov '12

21 Nov '12

#1185: Automate auto-generating code -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- There should be an automated way for re-generating code, i.e. running Kranc and autoconf. Often, projects have a script "autogen.sh" that does so. This can't be a makefile, since this has to generate configure, which needs to run to generate the Makefile. In our case, autogen.sh would (unconditionally) run autoconf to generate configure, and would check each thorn for certain scripts/makefiles that then have the opportunity to re-generate code (if needed). For example, we could check for files "autogen.sh" in each thorn's main directory. E.g. McLachlan would contain the command "cd m; make" there. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1185> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

[Einstein Toolkit] #1183: add conservative ENO operator to Carpet
by Einstein Toolkit 20 Nov '12

20 Nov '12

#1183: add conservative ENO operator to Carpet -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: optional | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- the attached patch adds a conservative ENO operator to Carpet which can be used in cell centered runs to conserve rest mass when regridding/prolongating. The operator is activated by setting he new Carpet parameter "Carpet::eno_interpolation_type" to "averages". The default is "samples" which selects the current ENO implementation. I also attach a parameter file that demonstrates the effect (can be turned into a test if we want to, also one can likely add the operator to CarpetExtra's prolongation test thorn). The final file attached contains the Maple worksheet to compute the ENO weights. All of this is based on the lecture notes by Shu http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19980007543_1998045663…. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1183> 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 November 2012