Trac June 2012

trac@lists.einsteintoolkit.org

1 participants
175 discussions

[Einstein Toolkit] #878: Tests using Exact should use EinsteinExact
by Einstein Toolkit 30 Oct '12

30 Oct '12

#878: Tests using Exact should use EinsteinExact -----------------------------------+---------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: EinsteinToolkit thorn | Version: Keywords: | -----------------------------------+---------------------------------------- The EinsteinExact arrangement provides initial data accurate to roundoff, in contrast to the Exact thorn which does not. The initial data from the Exact thorn is also highly sensitive to roundoff level differences. Hence, tests should be converted to using the EinsteinExact arrangement where possible. In some cases, EinsteinExact will not support the required metrics or parameters. These could either be added to EinsteinExact, or the Exact thorn could continue to be used. Milestone: ET_2012_11. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/878> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 5

[Einstein Toolkit] #361: delta_time when setting up ID with explicit time dependence
by Einstein Toolkit 28 Oct '12

28 Oct '12

#361: delta_time when setting up ID with explicit time dependence ------------------------------------------+--------------------------------- Reporter: eloisa.bentivegna@… | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: Carpet | Version: ET_2010_11 Keywords: | ------------------------------------------+--------------------------------- In CallInitial, delta_time is used to calculate the time corresponding to the different timelevels (line 399 of Carpet/src/Initialise.cc). At this stage, though, delta_time is always equal to 1, leading to potentially very separated initial-data slices when using init_each_timelevel and an initial-data thorn that uses cctk_time explicitly. Should cctkGH->cctk_delta_time be used here instead? -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/361> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 19

[Einstein Toolkit] #323: GetComponents overwrites thorn list
by Einstein Toolkit 25 Oct '12

25 Oct '12

#323: GetComponents overwrites thorn list ---------------------------+------------------------------------------------ Reporter: eschnett | Owner: eric9 Type: defect | Status: new Priority: critical | Milestone: Component: GetComponents | Version: Keywords: | ---------------------------+------------------------------------------------ I specified a thorn list located in the main Cactus directory. GetComponents overwrote this thorn list with its own thorn list (the one it generates automatically). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/323> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 18

[Einstein Toolkit] #631: Documentation fails to build
by Einstein Toolkit 25 Oct '12

25 Oct '12

#631: Documentation fails to build ---------------------+------------------------------------------------------ Reporter: hinder | Owner: Type: defect | Status: new Priority: blocker | Milestone: Component: Cactus | Version: Keywords: | ---------------------+------------------------------------------------------ With the current ET, I cannot build the documentation: [ianhin@login-damiana EinsteinToolkit]$ make AllDoc Creating user documentation UsersGuide.pdf Running pdflatex.... ! Argument of \CA@getsvndate has an extra }. ! Paragraph ended before \CA@getsvndate was complete. ! Argument of \CA@getsvndate has an extra }. ! Paragraph ended before \CA@getsvndate was complete. ! Paragraph ended before \@parse@version was complete. ! Missing number, treated as zero. ! Missing = inserted for \ifnum. ! Missing number, treated as zero. ! LaTeX Error: Missing \begin{document}. ! Undefined control sequence. Problem in . See doc/UsersGuide/LATEX_MESSAGES. make: *** [UsersGuide] Error 1 I am attaching LATEX_MESSAGES. I have tried this both on damiana and on my laptop. I consider this a blocker issue which could delay the release. We must have working documentation. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/631> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #831: Cactus FAQ is out of date
by Einstein Toolkit 24 Oct '12

24 Oct '12

#831: Cactus FAQ is out of date ----------------------------+----------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: ET_2012_05 Component: Cactus website | Version: Keywords: | ----------------------------+----------------------------------------------- The FAQ at http://cactuscode.org/documentation/faq is ancient and some of its content is irrelevant now. It would be nice for this to be revised before the next release. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/831> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 8

[Einstein Toolkit] #797: N13CarpetRegrid211snap_coarseE does not hold after being enforced in cell centering
by Einstein Toolkit 23 Oct '12

23 Oct '12

#797: N13CarpetRegrid211snap_coarseE does not hold after being enforced in cell centering --------------------+------------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: major | Milestone: Component: Carpet | Version: Keywords: | --------------------+------------------------------------------------------- I have a run (on Caltech's shc and on lonestar) which runs fine for about 300M or so and then fails with a property enforcement error inside of CarpetRegrid. Attached please find stdout with Carpet::veryverbose=yes, CarpetRegrid2::veryverbose=yes as well as the parameter file. It takes about 1hr to reproduce this starting from the checkpoints on shc. Most of this time is IO (the checkpoint is iteration 133120 failure occurs at preregrid in iteration 133185). Turning off cell centering makes the error go away. Turning on refluxing makes the run fails (much) earlier with a boxes not contained error (re- running this on shc right now, the XSEDE clusters are just too slow). In case you have access to shc (or zwicky) and would look at the actual output files, the path is: /panfs/ds06/sxs/rhaas/cactus/simulations/noreflux/output-0003 -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/797> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 21

[Einstein Toolkit] #517: archive CactusExternal
by Einstein Toolkit 23 Oct '12

23 Oct '12

#517: archive CactusExternal -------------------------+-------------------------------------------------- Reporter: knarf | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- We should move the CactusExternal thorns to archive. They cause trouble and confusion where they are right now. This should happen for the next Cactus release. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/517> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 6

[Einstein Toolkit] #176: Test parameter files without running them
by Einstein Toolkit 23 Oct '12

23 Oct '12

#176: Test parameter files without running them -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- It would be useful to be able to check that the parameters of a run are OK before running it. Since there can be long queue times on supercomputers, it would be good to do this on a local machine which might not have as much memory as is required for the full run. Currently, running the job would cause memory exhaustion on the smaller machine. One solution would be an additional command-line argument to Cactus --exit-after-paramcheck which stops the run cleanly after the PARAMCHECK Cactus bin. This is preferable to a new Cactus parameter, as it would not require the parameter file to be modified. One could imagine this also being potentially used by simfactory automatically when submitting a job (though this would only work if you could run MPI executables on the head node). -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/176> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 12

[Einstein Toolkit] #773: McLachlan dissipation should be disabled by default
by Einstein Toolkit 23 Oct '12

23 Oct '12

#773: McLachlan dissipation should be disabled by default -------------------------+-------------------------------------------------- Reporter: hinder | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- In the current version of McLachlan, the parameter apply_dissipation is set to "always" by default. The corresponding "epsdiss" is set to 0 by default. The dissipation calculation in McLachlan is expensive due to the way that it iterates over variables. Use of the Dissipation thorn or similar is usually much faster. I had not realised that apply_dissipation was "always" by default. I think it should be "never". OK to change? (with announcement to the mailing list) -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/773> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 13

[Einstein Toolkit] #535: Add autoconf macro to test C99 style variable declarations
by Einstein Toolkit 23 Oct '12

23 Oct '12

#535: Add autoconf macro to test C99 style variable declarations -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- Many compilers don't support C99 style variable declarations in their default settings. We should test this, add certain flags automatically if we can, or abort with a clear error message otherwise. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/535> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

← Newer
1
...
6
7
8
9
10
11
12
...
18
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac June 2012