#1645: simfactory should create exe directory
------------------------+---------------------------------------------------
Reporter: rhaas | Owner: eschnett
Type: defect | Status: new
Priority: minor | Milestone:
Component: SimFactory | Version: development version
Keywords: |
------------------------+---------------------------------------------------
Using virtual (--virtual) configuration one can wrap a Cactus config (or
at least the parts that simfactory cares about) around an existing
executable. Simfactory then copies the executable to exe/cactus_sim (or
whatever), however it assumes that exe already exists. Since exe is not
part of the Cactus checkout, simfactory needs to itself ensure that it
exists.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1645>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1615: TOVSolver shares parameters from GRHydro
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: TOVSolver |
-----------------------------------+----------------------------------------
Zach Etienne was looking at TOVSolver to use it for a test case in
IllinoisGRMHD (and to compare to GRHydro). He found that it
Turns out all but one of the parameters that are shared with GRHydro are
unused in TOVSolver:
These need to be removed:
USES real rho_abs_min
USES real rho_rel_min
USES REAL initial_rho_abs_min
USES REAL initial_rho_rel_min
USES REAL initial_atmosphere_factor
and that the one shared parameter that is actually used is
GRHydro_rho_central.
My suggestion would to remove these dependencies so that the initial data
thorn can be used with other evolution thorns.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1615>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1059: simfactory silent error
--------------------------------------+-------------------------------------
Reporter: anonymous | Owner: eschnett
Type: enhancement | Status: new
Priority: optional | Milestone:
Component: SimFactory | Version:
Keywords: simfactory error message |
--------------------------------------+-------------------------------------
When sim submit -remote ... fails to queue a job because the allocation
has been overdrawn, simfactory does not print any error message to screen
(it is only hidden in the log file).
Could it be made to print an error message to screen?
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1059>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#959: Move pthreads to ExternalLibraries
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
We should move pthreads support to ExternalLibraries (or to the flesh).
I have asked CCT to create the respective repository.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/959>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1579: GRHydro does not build on Blue Gene/Q
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Other | Version: development version
Keywords: |
----------------------+-----------------------------------------------------
Some of the C++ source files in GRHydro do not build on a Blue Gene/Q with
IBM's compiler. The problem is that the compiler takes a very long time
(>8h) even without (sic!) optimization. "The usual" playing with compiler
options or changes to the source files had no effect.
I consider this to be a bug in the compiler. A work-around may be to
switch to Clang as C++ compiler.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1579>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#816: include SphericalHarmonicReconASCII from incoming in PITTNULLCode
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: optional | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
Christian Reisswig provided a copy of SphericalHarmonicReconASCII and
alternative thorn that reads in CCE boundary data (similar
SphericalHarmonicRecon) but supporting a wider variety of input file
formats (HDF5 among them, irrespective of the name).
Used by SpEC and Llama.
There are no docs or test cases as of now. Test data would be welcome
(SpEC, Llama or Cactus provided, I don't think it makes a difference).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/816>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1637: MoL should automatically allocate storage for sufficient timelevels of
evolved variables
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version: development version
Keywords: MoL |
-------------------------+--------------------------------------------------
The MoL thorn requires that all evolved variables have at least two
timelevels of data, even if the integration method (e.g. RK4) does not
need any past timelevels. It uses one of these timelevels as scratch
space, potentially in addition to any other scratch space variables. In
the case where at least two timelevels are needed for other reasons, this
is more efficient than allocating an extra scratch space variable. Rather
than requiring the evolution thorn to allocate at least two timelevels of
storage for these variables, MoL should ensure sufficient timelevels via
the flesh API.
A related issue is that using timelevels for this purpose is wasteful in
situations where the timelevel is not used for any other purpose, since
the timelevel will be checkpointed even though it is only being used for
temporary storage.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1637>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1377: GRHydro_Bondi.c and GRHydro_BondiM.c use M_PI
-----------------------------------+----------------------------------------
Reporter: sbrandt | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: GRHydro M_PI |
-----------------------------------+----------------------------------------
GRHydro_Bondi.c and GRHydro_BondiM.c use M_PI. This was a problem on
Tianhe-1A. I'd suggest adding the following to both files:
#ifndef M_PI
#define M_PI 3.141592653589793
#endif
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1377>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1754: _BSD_SOURCE in glibc apparently going away
------------------------+---------------------------------------------------
Reporter: rhaas | Owner:
Type: task | Status: new
Priority: unset | Milestone:
Component: SimFactory | Version: development version
Keywords: |
------------------------+---------------------------------------------------
I just stumbled accross https://lwn.net/Articles/634207/ which states:
--8<--
Also in 2.20, the _BSD_SOURCE and _SVID_SOURCE feature test macros have
been removed. The declarations formerly available under those macros are
now under _DEFAULT_SOURCE, but, since it's the default, one need not set
it explicitly. Roland's suggestion, though, was that most code would
(continue to) want to use _GNU_SOURCE or one of the POSIX-specific macros.
(See this article for an introduction to glibc feature test macros).
--8<--
We use this in some of our option lists to make {{{M_PI}}} and
{{{strdup}}} visible.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1754>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1252: Thorn configuration scripts should not be run if there are missing thorns
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
If there are thorns present in the thornlist which are not present in the
source tree, Cactus currently displays the corresponding error message,
and then runs the rest of the CST including thorn configuration scripts.
Since these can build large external libraries (e.g. LORENE), it can be a
long time before the user notices that the build has failed. I would
prefer if Cactus aborted before running the CST scripts.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1252>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit