#1528: check that mainstream machines use correct thread binding
------------------------+---------------------------------------------------
Reporter: rhaas | Owner: eschnett
Type: task | Status: new
Priority: major | Milestone:
Component: SimFactory | Version: development version
Keywords: |
------------------------+---------------------------------------------------
it is possible that systems that initialize themselves before hwloc (eg
MPI) bind to the wrong CPU core unless (the equivalent of) numactl is
used.
For an example on bluewaters see #1527.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1528>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1493: testsuite Carpet/outer-buffers fails
--------------------+-------------------------------------------------------
Reporter: knarf | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone: ET_2014_05
Component: Carpet | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
The testsuite Carpet/outer-buffers fails because it sets the parameter
Carpet::use_outer_buffer_zones which doesn't exist anymore.
This testsuite was not usually run because a required thorn wasn't part of
the toolkit. This now changed, triggering a failure in the regular builds
and tests.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1493>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#849: Drop explicit support for Fortran 77 in Cactus
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
I suggest to drop explicit support for Fortran 77 in Cactus. Fortran 77
is, for all practical purposes, a subset of Fortran 90, and thus Fortran
77 code can be compiled by Fortran 90 compilers.
There is currently no platform that has a Fortran 77 and no Fortran 90
compiler, and there is no Fortran source code in Cactus that cannot be
compiled by a Fortran 90 compiler.
In a way, supporting Fortran 77 as language is similar to supporting K&R C
as a language. We don't do this either.
I suggest to remove/ignore all configuration options regarding Fortran 77,
and to compile .f77 and .F77 files with a Fortran 90 compiler. This change
will simplify the configuration stage of Cactus. I don't expect any user
to notice.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/849>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1531: GRHydro updates
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: GRHydro EOS_Omni |
-----------------------------------+----------------------------------------
A large number of GRHydro updates have accumulated. Attached please find
them all as well as a required update to EOS_Omni.
Patches to follow in a bit.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1531>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1536: Wrong code in Piraha.hpp
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: critical | Milestone:
Component: Cactus | Version: development version
Keywords: |
----------------------+-----------------------------------------------------
Piraha.hpp contains in lines 171 ff the code
{{{
const char c;
Literal(char b) : c(b) {}
bool match(Matcher *m);
std::string fmt() {
std::string s = "literal(";
s += c+")";
return s;
}
}}}
In this code, the expression c+")" adds a character to a pointer, in
effect adding to the pointer. This does not append to the string s, as was
intended.
There seem to be several similar cases in other locations as well.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1536>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1505: remove the MoL number of variables accumulators
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: optional | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: MoL |
-----------------------------------+----------------------------------------
The attached patches removes the need for MoL's accumulator parameters to
count the number of evolved, constrained and save-and-restore variables.
Instead it counts them during MoL_RegisterVariables and using timelevels
as a way of creating new variable storage for the scratch levels. This
means unfortunately that it will create C pointers for 99 (the current max
in interface.ccl) scratch timelevels ie there is ScratchSpace_p_p_p_p..._p
.
Currently applies on top of trunk.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1505>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#882: Create ThornGuideHTML target
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
----------------------+-----------------------------------------------------
Barry Wardell suggests: The only issue is that there doesn't seem to be a
HTML version of the configuration specific ThornGuide make target, so we
should add this as a target at the same time as removing the patch. I'd
imagine this would just be a matter of copy-and-paste from the existing
ThornGuideHTML target.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/882>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1489: EinsteinExact (the arrangement) fails to build ThornGuideHTML
-----------------------------------+----------------------------------------
Reporter: knarf | Owner:
Type: defect | Status: new
Priority: major | Milestone: ET_2014_05
Component: EinsteinToolkit thorn | Version: development version
Keywords: |
-----------------------------------+----------------------------------------
EinsteinExact (the arrangement) fails to build ThornGuideHTML. The problem
is the file spacetimes.tex which is included, but ThornGuideHTML is built
outside of the doc directory, and cannot find it.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1489>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1522: Improve determining make dependencies
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Cactus | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
Cactus automatically determines the dependencies between source files and
their include files. This mechanism doesn't quite work in all cases; e.g.
when a source file (or header file?) is removed, the build aborts, and the
auto-generated dependencies have to be deleted automatically.
I have recently come across a mechanism that works reliably. Here is the
relevant Makefile fragment, applied to building C++ files:
{{{
# Taken from <http://mad-scientist.net/make/autodep.html> as written
# by Paul D. Smith <psmith(a)gnu.org>, originally developed by Tom
# Tromey <tromey(a)cygnus.com>
PROCESS_DEPENDENCIES = \
sed -e 's/$@.tmp/$@/g' < $*.o.d > $*.d && \
sed -e 's/\#.*//' \
-e 's/^[^:]*: *//' \
-e 's/ *\\$$//' \
-e '/^$$/ d' \
-e 's/$$/ :/' < $*.o.d >> $*.d && \
rm -f $*.o.d
%.o: %.cc
${CXX} -MD ${CPPFLAGS} ${CXXFLAGS} -o $@.tmp -c $*.cc
@${PROCESS_DEPENDENCIES}
@mv $@.tmp $@
-include ${DEPS}
}}}
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1522>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit