#85: --reconfig seems to lead to --clean
------------------------+---------------------------------------------------
Reporter: anonymous | Owner: mthomas
Type: defect | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
When I use --reconfig for building, SimFactory also assumes that --clean
is used, although I did not.
I build with the command
./simfactory/sim build --debug --reconfig
and after reconfiguring, SimFactory outputs
build_clean: True
removeConfig: False
Cleaning sim-debug
and then cleans the configuration. This should not be the case.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/85>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#110: sh: svnversion: command not found
------------------------+---------------------------------------------------
Reporter: hinder | Owner: mthomas
Type: defect | Status: new
Priority: minor | Milestone:
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
When running SimFactory 2 on Kraken, I get the following output directory
after the login message when running
sim2 --remotemachine kraken build --thornlist thornlists/ian.th
sh: svnversion: command not found
If a feature of simfactory won't be available due to a lack of the
svnversion program, a more friendly message (or nothing at all) should be
output.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/110>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#80: Add 'local' machine entry
-------------------------+--------------------------------------------------
Reporter: anonymous | Owner: mthomas
Type: enhancement | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
-------------------------+--------------------------------------------------
It's currently necessary to set a machine entry for the local machine,
even if it's not used for compiling/running Cactus. This is not obvious
from the defs.local.ini.simple file.
I suggest adding a 'local' machine to the mdb and then putting the options
that are required into defs.local.ini.simple so that users know what they
need to specify. Something like:
[local]
sourcebasedir = ...
basedir = ...
aliaspattern = ...
hostname = ...
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/80>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#51: M_PI definition not always available to wavetoy-loopcontrol.c
--------------------------------------------+-------------------------------
Reporter: richard.oshaughnessy@… | Owner: eschnett
Type: defect | Status: closed
Priority: minor | Milestone:
Component: Cactus | Version: ET_2010_06
Resolution: fixed | Keywords: c99
--------------------------------------------+-------------------------------
Comment (by eschnett):
Actually, I am going to disable this source file because it is not used in
production simulations, it is only an old example.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/51#comment:3>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#51: M_PI definition not always available to wavetoy-loopcontrol.c
--------------------------------------------+-------------------------------
Reporter: richard.oshaughnessy@… | Owner: eschnett
Type: defect | Status: closed
Priority: minor | Milestone:
Component: Cactus | Version: ET_2010_06
Resolution: fixed | Keywords: c99
--------------------------------------------+-------------------------------
Changes (by eschnett):
* status: assigned => closed
* resolution: => fixed
Comment:
To my knowledge, M_PI is not part of ANSI C, but is part of POSIX. Some
compilers disable POSIX compatibility by default. The compiler
configurations that we distribute e.g. with the Simulation Factory
<http://simfactory.org/> should contain these settings. These may also be
good examples for which settings your compiler requires.
I am not going to modify wavetoy-loopcontrol.c since there is nothing one
can do in the source code (except not using M_PI); rather, the compiler
options need to be changed.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/51#comment:2>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#102: Implement 4th order finite differencing in Exact
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
Thorn EinsteinInitial/Exact uses finite differencing to calculate the
extrinsic curvature. It uses currently 2nd order stencil. The attached
patch implements 4th order finite differencing, which reduces the error
significantly.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/102>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#99: Cactus doesn't add include paths to F90-compilation
--------------------+-------------------------------------------------------
Reporter: knarf | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
--------------------+-------------------------------------------------------
Cactus doesn't add include paths to F90-compilation, probably because
those files get preprocessed anyway in an extra step. However, this then
also neglects the include files necessary for F90-modules. The attached
patch adds include-dirs also as compiler flags to let it find the modules.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/99>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit