Trac December 2012

trac@lists.einsteintoolkit.org

1 participants
134 discussions

[Einstein Toolkit] #346: Detect when --reconfig is necessary
by Einstein Toolkit 06 Jul '13

06 Jul '13

#346: Detect when --reconfig is necessary ----------------------+----------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Other | Version: Keywords: | ----------------------+----------------------------------------------------- Cactus sometimes outputs an error message that a configuration needs to be reconfigured. Simfactory should notice this, and then automatically build with --reconfig. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/346> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1065: Pass CCTK_ARGUMENTS more efficiently in Fortran
by Einstein Toolkit 06 Jul '13

06 Jul '13

#1065: Pass CCTK_ARGUMENTS more efficiently in Fortran -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: Other | Version: Keywords: | -------------------------+-------------------------------------------------- CCTK_ARGUMENTS is passed differently in C and in Fortran. In C, only a single pointer is passed, pointing to cctkGH. The cctk_... variables and pointers to grid functions are defined locally from cctkGH. This is efficient, because (a) only a single variable is passed, and (b) the compiler can eliminate unused definitions. In Fortran, all the cctk_... variables and all grid functions are passed explicitly. This is expensive for the caller, because hundreds of arguments have to be set up and passed to the subroutine. The compiler cannot eliminate any unused variables. I suggest to change the Fortran calling convention to be the same as the one for C. Since regular Fortran pointers differ significantly from C pointers, I suggest to use "Cray pointers" instead, which are very similar to C pointers. Cray pointers are an extension to the Fortran standard, and are supported by all Fortran compilers I know of. I attach sample code that shows how to declare, define, and use this convention. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1065> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1015: increase file size limit
by Einstein Toolkit 06 Jul '13

06 Jul '13

#1015: increase file size limit ----------------------------------+----------------------------------------- Reporter: rhaas | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit trac | Version: Keywords: | ----------------------------------+----------------------------------------- Could we increase the size limit for attached files, please? Right now it seems to be 256k which is regularly too small if I have to attach a patch with test data. I don't really like splitting up patches into a code patch (uncompressed) and a gzipped data patch for the test data all the time. It is just very very error prone. At least for logged in users. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1015> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #907: TRAC: allow to create a ticket with review state
by Einstein Toolkit 06 Jul '13

06 Jul '13

#907: TRAC: allow to create a ticket with review state ----------------------------------+----------------------------------------- Reporter: bmundim | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: EinsteinToolkit trac | Version: Keywords: TRAC | ----------------------------------+----------------------------------------- Sometimes we want to create a ticket with an attached patch and assign the ticket to be reviewed. That should be possible with only one "modify ticket". Currently we need to create the ticket with the attachment and then modify the ticket afterwards to review state. The problem is that sometimes we forget to change to review state. It would be nice to do it all at once. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/907> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #1044: Gnuplot Cactus visualisation page has multiple issues
by Einstein Toolkit 06 Jul '13

06 Jul '13

#1044: Gnuplot Cactus visualisation page has multiple issues ----------------------------+----------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: Cactus website | Version: Keywords: | ----------------------------+----------------------------------------------- The page http://cactuscode.org/documentation/visualization/gnuPlot/ has the following problems: * The instructions for viewing multi-iteration 1D data from the IOASCII thorn do not work. Since the iterations are separated by only a single blank line, you cannot use the "index" option in the Gnuplot "plot" command as the instructions tell you to do. I suspect that either the output format or Gnuplot itself has changed since the instructions were written. Erik suggests using some form of "every" to visualise this data in Gnuplot. * This page renders poorly in both Safari (webkit) and Firefox (gecko). The light blue boxes containing text to be typed have a strange artefact on the left side, and the initial paragraph is wrapped poorly. * All of the links in the table of contents are broken. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/1044> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #478: add Cactus to tis.xsede.org
by Einstein Toolkit 06 Jul '13

06 Jul '13

#478: add Cactus to tis.xsede.org --------------------+------------------------------------------------------- Reporter: knarf | Owner: Type: task | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/478> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 2

[Einstein Toolkit] #450: Output elapsed times for test cases
by Einstein Toolkit 06 Jul '13

06 Jul '13

#450: Output elapsed times for test cases -------------------------+-------------------------------------------------- Reporter: eschnett | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- To ensure that Cactus test cases don't run for too long, and to identify those that do, we should output the run time for all test cases together with their results. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/450> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 1

[Einstein Toolkit] #229: Using a nonexistent header file should lead to an error message
by Einstein Toolkit 06 Jul '13

06 Jul '13

#229: Using a nonexistent header file should lead to an error message --------------------+------------------------------------------------------- Reporter: hinder | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Cactus | Version: Keywords: | --------------------+------------------------------------------------------- If I have the following in my interface.ccl, USES INCLUDE: vectors.h but no thorn in my thornlist provides this header file, there is no error at compile time. Further, if I #include this file in my source file, an empty file is included, which means that again I don't get an error. The first indication that something is wrong is that the contents of the header file are not available, which makes debugging the problem with the thornlist very confusing. I propose that the CST should emit a fatal error if one of the thorns tries to use a header file which does not exist. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/229> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 14

[Einstein Toolkit] #905: NaNs in ADMBase::gxx using Development Version of ET
by Einstein Toolkit 06 Jun '13

06 Jun '13

#905: NaNs in ADMBase::gxx using Development Version of ET ---------------------------------+------------------------------------------ Reporter: yosef@… | Type: defect Status: new | Priority: major Milestone: | Component: Other Version: | Keywords: ---------------------------------+------------------------------------------ While testing the CCE in the ET, I stumbled across an issue interpolating the admbase::metric at CCTK_POSTSTEP in GLOBAL mode at particular spatial points. The "bug" (or parfile/scheduling error) seems to be sensitive to the exact grid setup. Basically, when I use the qc0-mclachlan-CCE_Cauchy.par parfile, I get nans for gxx. I made a small test thorn that only interpolates gxx at a particular point. Nans show up at iteration 1. attached is the parfile I used and the test thorn. Here is the output from the above test thorn: gxx(3.966899,0.000000,-17.630662) = 1.1160523626974641 at iter 0 on proc 1 gxx(3.966899,0.000000,-17.630662) = 1.1160523626974641 at iter 0 on proc 0 gxx(3.966899,0.000000,-17.630662) = -nan at iter 8 on proc 1 gxx(3.966899,0.000000,-17.630662) = -nan at iter 8 on proc 0 gxx(3.966899,0.000000,-17.630662) = -nan at iter 16 on proc 1 gxx(3.966899,0.000000,-17.630662) = -nan at iter 16 on proc 0 etc.... -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/905> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 3

[Einstein Toolkit] #705: Activation Order in Parameter Files
by Einstein Toolkit 24 May '13

24 May '13

#705: Activation Order in Parameter Files -------------------------+-------------------------------------------------- Reporter: sbrandt | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Cactus_4.1.0 Component: Cactus | Version: Keywords: | -------------------------+-------------------------------------------------- At the moment the ActiveThorns list is sensitive to the order in which thorns are activated if the ActiveThorns parameter is updated multiple times. However, it is not sensitive to the order in which thorns are activated if all thorns are specified in a single line. This inconsistency should be removed, and the order should not matter in either case. -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/705> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 7

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Trac December 2012