Trac November 2011

trac@lists.einsteintoolkit.org

2 participants
166 discussions

[Einstein Toolkit] #558: Carpet with Periodic Boundary Conditions
by Einstein Toolkit 08 Feb '12

08 Feb '12

#558: Carpet with Periodic Boundary Conditions -----------------------------+---------------------------------------------- Reporter: hfinkel@… | Owner: eschnett Type: enhancement | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: carpet periodic | -----------------------------+---------------------------------------------- The current Carpet driver is not compatible with the periodic boundary conditions (as provided by the Periodic thorn or otherwise). Erik's comment on the User's list was: "It is straightforward to implement periodicity in the grid structure -- one needs to take the current grid structure, shift it in the 26 directions, and take the logical union of all 27 grid structures. This will then be automatically clipped. The most complex part is calculating by how much to shift." Please implement support for periodic BCs in Carpet. This will directly enable production science runs. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/558> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 25

[Einstein Toolkit] #120: Improve built-in help system
by Einstein Toolkit 08 Feb '12

08 Feb '12

#120: Improve built-in help system -------------------------+-------------------------------------------------- Reporter: hinder | Owner: mthomas Type: enhancement | Status: new Priority: major | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- SimFactory currently provides a single help screen when you type "sim help". I would like to be able to do "sim help <command>" and get help which is relevant for that command. This help should say briefly what the command does, and give a comprehensive list of the options specific to that command. The top-level "sim help" command should then give a list of the commands, and a list of the simfactory options which apply to all commands. This first help page should be kept as brief as possible so that it is easy to see at a glance what commands are available. The most common commands should be listed first, and maybe separated from the less common commands. I think this is important as it is the first port-of-call when someone wants to know how to use a particular feature, especially when the syntax is similar but not quite the same as in SimFactory 1. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/120> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #543: Change diff format in GetDomponents
by Einstein Toolkit 05 Feb '12

05 Feb '12

#543: Change diff format in GetDomponents ---------------------------+------------------------------------------------ Reporter: eschnett | Owner: eric9 Type: enhancement | Status: new Priority: major | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ It would be convenient to change the format of GetComponent's --diff command to output diffs that can be directly applied via "patch -p0" from the main Cactus directory. That is, file names such as "a/Tools/CodeGen/Schedule.m" should be changed to "repos/Kranc/Tools/CodeGen/Schedule.m". -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/543> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #666: have CarpetIOScalar output grid scalar directly rather than applying reductions to them
by Einstein Toolkit 05 Feb '12

05 Feb '12

#666: have CarpetIOScalar output grid scalar directly rather than applying reductions to them -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- Carpet already assumes that these grid scalars have the same value on all processors. So reducing them does not generate any information that is not already present by just looking at a single value. The attached patch outputs grid scalars (from the root processor) directly, this means that grid scalar output files can be used to output timeseries like grid scalars (which is what many are). The attached parfile and data files are a modfied version of a QLM test. Notice how much nicer to read the scalar output *.scalar.asc is then the 0D output *..asc. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/666> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #682: LSUThorns/Vectors: Simplify API for partial vector stores
by Einstein Toolkit 04 Feb '12

04 Feb '12

#682: LSUThorns/Vectors: Simplify API for partial vector stores -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- Implement vec_store_nta_partial, which offers a simpler interface, similar to the one used in OpenCL. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/682> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #680: Add kifneg function
by Einstein Toolkit 04 Feb '12

04 Feb '12

#680: Add kifneg function -----------------------------------+---------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Add an kifneg function that does the opposite of kifpos, because kifneg is more natural (in the same sense as "ifnotzero" is natural in C.) Incidentally, it should probably be renamed "ifmsb" instead, because it can also be applied to unsigned quantities which don't have a sign bit. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/680> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #617: Norm of NxNx1 grid gives poison in new version of Carpet
by Einstein Toolkit 27 Jan '12

27 Jan '12

#617: Norm of NxNx1 grid gives poison in new version of Carpet ------------------------+--------------------------------------------------- Reporter: hinder | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: regression | ------------------------+--------------------------------------------------- I am having a problem with a 2D Carpet unigrid simulation with NxNx1 grid points in each direction. I have 0 boundary points and 0 ghost points in the z direction. The norm2 and other norms computed by CarpetIOBasic and CarpetIOScalar are showing poison. The same happens if I use one boundary point and one ghost point. The important feature is that zmin = zmax. If I make zmax = zmin + dz, then the norms are fine. This works fine in the git version of Carpet - it seems to be a regression in the Mercurial version. Parameter file is attached. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/617> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #659: vip.rzg.mpg.de: Internal Compiler Error: Insufficient storage
by Einstein Toolkit 16 Jan '12

16 Jan '12

#659: vip.rzg.mpg.de: Internal Compiler Error: Insufficient storage ----------------------------------------------+----------------------------- Reporter: alexander.beck-ratzka@… | Type: defect Status: new | Priority: major Milestone: | Component: Cactus Version: | Keywords: Formaline ----------------------------------------------+----------------------------- I have gotten an internal compiler error at compiling formaline on vip.rzg.mpg.de. xlc_r -g -q64 -qminimaltoc -qsuppress=1506-1108 -qlanglvl=extc99 -O2 -qmaxmem=-1 -qhot -qarch=pwr6 -qtu ne=pwr6 -qsmp=omp -c -o /u/alibeck/Cactus/configs/test-kiki/scratch /cactus-thorn-source-BLAS.o /u/alib eck/Cactus/configs/test-kiki/scratch/cactus-thorn-source-BLAS.c Out of memory in PoolArea::PoolArea(). xlc_r: 1501-230 (S) Internal compiler error; please contact your Service Representative. For more infor mation visit: http://www.ibm.com/support/docview.wss?uid=swg21110810 gmake[1]: *** [/u/alibeck/Cactus/configs/test-kiki/scratch/cactus-thorn- source-BLAS.o] Error 251 gmake[1]: Leaving directory `/u/alibeck/Cactus' gmake: *** [test-kiki] Error 2 The deeper investigation of the vip support team gave the following reason: 1506-300: (S) Insufficient storage available. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/659> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 11

[Einstein Toolkit] #592: simfactory --mdbkey syntax is horrible
by Einstein Toolkit 20 Dec '11

20 Dec '11

#592: simfactory --mdbkey syntax is horrible --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | --------------------+------------------------------------------------------- apparently simfactory requires me to do: {{{ sim --mdbkey=optionlist my-very-own-option-list --thornlist=einsteintoolkit.th }}} to overwrite mdb entries from the command line (and --define --substitue --replace --append --mdbkey). I have to admit I would not have guessed that from the help text which states: {{{ options: -h, --help show this help message and exit --define=DEFINE set additional definition --mdbkey=MDBKEY override an mdb key }}} I would like to suggest to either change the help text to {{{ --mdbkey=MDBKEY MDBVALUE }}} or to support something like {{{ --mdbkey="MDBKEY=VALUE" }}} with or without quotation marks instead maybe. Is there a full documented list of valid mdb entries somewhere? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/592> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #523: schedule MoL_DecrementCounter and friends BEFORE MoL_PostStepModify
by Einstein Toolkit 20 Dec '11

20 Dec '11

#523: schedule MoL_DecrementCounter and friends BEFORE MoL_PostStepModify --------------------+------------------------------------------------------- Reporter: rhaas | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- right now MoL_DecrementCounter (and MoL_ResetTime and MoL_ResetDeltaTime) is/are scheduled BEFORE MoL_PostStep which caused MoL_PostStepModify to run before MoL_DecrementCounter for me. The means that routines that are moved from MoL_PostStep to MoL_PostStepModify see a different MoL_IntermediateStep possibly confusing users. Also MoL_Add should be explicitly schedules before MoL_PostStepModify (again right now it says MoL_PostStep). It still ends up before due to the alphabetic sorting it seems. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/523> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

← Newer
1
...
8
9
10
11
12
13
14
...
17
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac November 2011