Trac September 2011

trac@lists.einsteintoolkit.org

1 participants
184 discussions

[Einstein Toolkit] #112: Python version of Simfactory should be made default before next ET release
by Einstein Toolkit 29 Sep '11

29 Sep '11

#112: Python version of Simfactory should be made default before next ET release ------------------------+--------------------------------------------------- Reporter: knarf | Owner: mthomas Type: task | Status: new Priority: critical | Milestone: ET_2011_06 Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/112> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #521: Test WeylScal4/teukolskyID is failing
by Einstein Toolkit 29 Sep '11

29 Sep '11

#521: Test WeylScal4/teukolskyID is failing -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: WeylScal4 testsuite | -----------------------------------+---------------------------------------- The !WeylScal4/teukolskyID test case run on 08-Aug-2011 failed. http://damiana2.aei.mpg.de/~ianhin/testsuites/einsteintoolkit/ The errors are related to nontrivial changes in Psi4: http://damiana2.aei.mpg.de/~ianhin/testsuites/einsteintoolkit/einsteintoolk… This is likely related to changeset:"62/ADMBase" committed as a result of #333. User: hinder Date: 2011/08/17 05:07 PM Modified: /trunk/ interface.ccl /trunk/src/ !InitSymBound.c Log: Apply "flat" boundary condition instead of "none" to ADMBase variables In the development version of Carpet, only the interior of the newly created grid is initialized by interpolation, so non-trivial boundary conditions need to be applied. I don't know whether the old or the new results are correct. The failure happens with the stable version of Carpet (the test has always failed with the development version). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/521> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #593: Use shared libraries in Cactus
by Einstein Toolkit 28 Sep '11

28 Sep '11

#593: Use shared libraries in Cactus -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- I tend to have a single thorn list with many thorns. Building executables is slow, and much time is spent in the final link stage. With shared libraries, this time could be much reduced. Using shared libraries seems to be simple on many architectures; there are either ld flags one can use, or one could use libtool for the implementation. This would also be a first step towards building thorns (or external libraries) independently of each other. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/593> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #510: Reduce default verbosity
by Einstein Toolkit 28 Sep '11

28 Sep '11

#510: Reduce default verbosity -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | -------------------------+-------------------------------------------------- SimFactory has an option --verbose which defaults to True. This has been useful while SimFactory was in heavy development and there were frequent problems and errors where the extra information provided by --verbose gave useful context to debugging. Now that SimFactory is in regular production use with fewer problems, and the plan is to make it the default for the Einstein Toolkit, I propose to change the verbosity to False. This makes the tool appear less intimidating for new users and leads to an overall smoother, slicker experience. All information should be available in the simulation log file for debugging purposes if required. The attached patch implements this. There are still some messages which are output anyway, and these will need to be addressed one by one. Also, the --verbose setting does not appear to propagate across remote invocations of simfactory. But these are separate from the decision to make --no-verbose the default. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/510> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #589: View all tickets
by Einstein Toolkit 27 Sep '11

27 Sep '11

#589: View all tickets ----------------------------------+----------------------------------------- Reporter: bmundim | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit trac | Version: Keywords: | ----------------------------------+----------------------------------------- The option to view all tickets (open and closed) one seems not to be linked in the main page anymore. I find it useful if we need to reopen a particular ticket. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/589> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #585: Add thorn FFTW3 to manifest
by Einstein Toolkit 27 Sep '11

27 Sep '11

#585: Add thorn FFTW3 to manifest ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: critical | Milestone: Component: Other | Version: Keywords: | ----------------------+----------------------------------------------------- I believe the PITTNullCode requires thorn ExternalLibraries/FFTW3. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/585> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #131: Cactus produces way too much output with SILENT!=no
by Einstein Toolkit 26 Sep '11

26 Sep '11

#131: Cactus produces way too much output with SILENT!=no -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- I frequently find me scrolling through a lot of not necessary output from Cactus, including a lot of divider lines (___). I propose a mechanism to disable most of that output. There is currently one parameter which influences the amount of output from Cactus. If SILENT is set to 'no', Cactus provides way more output. All other values produce the usual output (including not setting it). I propose to use this existing variable to make Cactus less verbose if SILENT ist set to 'yes'. The default is 'undefined', so this would preserve the default Cactus behaviour. The attached patch attempts to do this: it suppresses divider lines, pre- and postprocessing infos if SILENT='yes'. I don't like that name though, as this is still not really silent, as you will still see one line per compiled file (ala COMPILING /home/frank.loeffler/mcrt/src/main/Banner.c), but I don't have a better idea right now and could live with it. The other option would be to introduce another variable (e.g. BRIEF), but then BRIEF and SILENT could contradict each other. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/131> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 10

[Einstein Toolkit] #565: ADMBase: Change default value of initial_shift parameter to "zero"
by Einstein Toolkit 26 Sep '11

26 Sep '11

#565: ADMBase: Change default value of initial_shift parameter to "zero" -----------------------------------+---------------------------------------- Reporter: bmundim | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- Currently the default value of initial_shift is "none". GRHydro doesn't support shift_state = 0 anymore for example, and I believe most of the codes do need storage for the shift vector. So I was wondering if it wouldn't be better to change the default for the initial_shift parameter from "none" to "zero". Any opinions about it? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/565> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #552: parameter file errors
by Einstein Toolkit 26 Sep '11

26 Sep '11

#552: parameter file errors --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: defect | Status: new Priority: minor | Milestone: ET_2011_11 Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- Cactus should not abort when parameter is set twice in parameter file, to the same value. Currently, Cactus aborts when that happens. While this is most certainly an oversight by the user, aborting is just annoying the user by stealing queue-time. I propose to make this a lvl-1 warning instead. If I set a parameter twice, to the same value, I certainly would like to have that parameter set to that value. Cactus should complain, but not abort because of that. This would have to be changed most certainly in src/main/SetParams.c in a couple of places. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/552> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 4

[Einstein Toolkit] #580: Support XDMF output in Carpet
by Einstein Toolkit 26 Sep '11

26 Sep '11

#580: Support XDMF output in Carpet -------------------------+-------------------------------------------------- Reporter: hinder | Owner: eschnett Type: enhancement | Status: new Priority: minor | Milestone: Component: Carpet | Version: Keywords: | -------------------------+-------------------------------------------------- [http://www.xdmf.org/ XDMF] is an XML-based format for describing how associated HDF5 data is arranged. This provides the information needed by visualisation programs to render the data, and the format is supported by both VisIt and ParaView. If Carpet could write out such a file in combination with its existing HDF5 output, VisIt and ParaView (at least) would be able to render Carpet data without having an additional plugin. I don't know the relative efficiency of the existing Carpet VisIt plugin and the XDMF reader, and I don't know how well the XDMF VisIt reader handles mesh-refined data, so these things should be looked it. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/580> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

← Newer
1
...
11
12
13
14
15
16
17
18
19
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac September 2011