#456: Ensure functions are not defined twice
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
When multiple source files define non-static functions with the same name,
these are all compiled together into the resulting executable. Which one
gets called is not predictable by the user.
This can happen if a user copies a thorn, modifies it slightly, and
compiles both thorns into the same configuration. This can lead to *very*
difficult-to-find bugs, and it would be helpful if Cactus was able to
prevent this, or at least to mitigate the problem.
At the CST level, Cactus should be able to tell that there are two thorns
which schedule functions with the same name. At the moment, this is not
caught. I propose that this should be a fatal error, as there is no way
to predict which function will be called eventually.
This will solve the problem in some cases, but not in the case where there
are instances of duplicate function names which are not scheduled. It
should be possible to scan the object/library files using standard tools
(nm etc) to determine if there are multiple globally visible symbols with
the same name. There might even be standard tools for this purpose.
Doing this in a portable way might not be straightforward, but having an
implementation for Linux, for example, would catch the majority of cases.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/456>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#447: simfactory 1.0 always uses -L 3
----------------------------------------------+-----------------------------
Reporter: alexander.beck-ratzka@… | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
----------------------------------------------+-----------------------------
The perl version of simfactory always uses the debugging loglevel for
simulations. The loglevel of a cactus simulation can be specified by
setting -L to a value between 0 (none) and 3 (debug). While the cactus
default is 0, simfactory sets it to 3. The debug loglevel could lead to
huge output files.
I would suggest to set it to the cactus default, and allow a user to
increase it.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/447>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#107: Update released einsteintoolkit.bib once we have a more final version
-----------------------+----------------------------------------------------
Reporter: anonymous | Type: task
Status: new | Priority: major
Milestone: | Component: EinsteinToolkit website
Version: | Keywords:
-----------------------+----------------------------------------------------
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/107>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#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
#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
#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
#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
#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
#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