#1884: provide support for multi-model runs in thorn MPI
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: MPI |
-----------------------------------+----------------------------------------
The attached patch adds a very thin layer of code to ExternalLibraries/MPI
to provide access to two communicators {{{MPI_Comm_World}}} and
{{{MPI_Comm_Universe}}} which can be used for multi-model runs (or runs
started via {{{MPI_Comm_Spawn}}}).
The code does not itself split a communicator, it only provides routines
to get and set the communicators.
It supports C and F90 calls (and C++ calls through external C and call
from F77 files since Cactus compiles those with at a F90 compiler).
Documentation is provided in the tex file and in the grdoc comments.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1884>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1656: CarpetInterp and MoL do not work properly together
--------------------+-------------------------------------------------------
Reporter: hinder | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: Carpet | Version: development version
Keywords: |
--------------------+-------------------------------------------------------
I am trying to integrate interpolated quantities using MoL. I call the
interpolator in MoL_CalcRHS, and want it to perform only a spatial
interpolation of the current content of timelevel 0. This current content
is what has been set by MoL; it is not the final value that will be at
t_{n+1} or was at t_N, but is the intermediate value that should be used
when computing the RHS at a given MoL substep. Since MoL does not set the
Carpet time hierarchy values, CarpetInterp seems to get confused about how
to do the interpolation. I need to tell CarpetInterp not to interpolate
in time at all, but to use timelevel 0 only. Unfortunately, setting the
interpolator option to use only one timelevel does not work. There is
commented-out code to "use cctk_time to decide whether to interpolate",
which essentially guarantees that no time interpolation will happen (since
the interpolation is requested for cctk_time, and the current time is
cctk_time, so they are always equal). Re-enabling this code allowed me to
achieve 4th order convergence for integrated interpolated quantities,
though I am not sure I understand everything that is going on in
CarpetInterp. I have added a parameter which controls this, and with this
parameter set to the default, nothing changes (i.e. it is not going to
change anyone's results unless they set the parameter). I would like to
commit this, so that collaborators can work off the same version. Since
the patch is very small, I hope this will not add too much unneeded
complexity. Is it OK to commit? Patch is attached.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1656>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1865: Automatically start SystemTopology
---------------------------------+------------------------------------------
Reporter: dradice@… | Owner: eschnett
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Carpet | Version: development version
Keywords: |
---------------------------------+------------------------------------------
Carpet used to load hwloc automatically and that would set thread
affinities. Now this functionality is in the SystemTopology thorn, which
is not automatically activated. This change could result in a significant
performance regression on some systems (see discussion in #1850).
Would it make sense to activate SystemTopology automatically?
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1865>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1932: ML_BSSN: other_timelevels Parameter Not Respected
--------------------------------+-------------------------------------------
Reporter: zachetie@… | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Other | Version: development version
Keywords: |
--------------------------------+-------------------------------------------
At the Jun 27, 2016 ET telecon, we found the following bug in
McLachlan/ML_BSSN:
Inside the ET_2016_05 ML_BSSN/schedule.ccl, you'll notice the following
lines:
STORAGE: ML_Ham[timelevels]
STORAGE: ML_mom[timelevels]
STORAGE: ML_cons_detg[timelevels]
STORAGE: ML_cons_Gamma[timelevels]
STORAGE: ML_cons_traceA[timelevels]
in all of these lines, "timelevels" should be replaced by
"other_timelevels".
This should result in significantly increased memory usage in the latest
ML_BSSN (possibly at the 10-20% level), particularly in vacuum evolutions.
Related to this problem, I noticed that in a previous version of McLachlan
(2015_05, where the above issue does not exist), all constraints are being
stored in checkpoint files, despite having only one timelevel.
ML_BSSN_Helper is supposed to overwrite the ML_BSSN/interface.ccl request
to set the Checkpoint="no" tag.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1932>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1816: segfaults on 64bit systems when build with c99
--------------------------------+-------------------------------------------
Reporter: physik@… | Owner:
Type: defect | Status: new
Priority: unset | Milestone:
Component: Cactus | Version: ET_2014_05
Keywords: |
--------------------------------+-------------------------------------------
I recently encountered a segfault in ScheduleInterface.c, more precisely
in the function
static int CCTKi_ScheduleCallFunction(void *function,
t_attribute *attribute,
t_sched_data *data)
{
/* find the timer for this function and this schedule bin */
t_timer *timer = attribute->timers;
while (timer && strcmp(timer->schedule_bin, data->schedule_bin))
{
timer = timer->next;
}
Running in the debugger revealed that timer->schedule_bin pointed to an
invalid address. Curiously, it had the top 33 (33 not a typo) bits all
set. Taking the lowest 32 bits gave a valid address which pointed to a
reasonable string "CCTK_INITIAL". This suggests a 32/64 bit issue. The
pointer timer->schedule_bin seems to be initialized in the same function
using strdup:
timer->schedule_bin = strdup (where);
strdup is not part of the c99 standard, but only Posix. Compiling with gcc
--std=c99 means it is not defined in <string.h>. This means the compiler
treats the occurrence of strdup as an implicit function declaration, and
assumes it returns int.
Thus, it will do an implicit conversion of the result from int to char*.
If the highest bit of the int was set, this resulted in a 64 bit pointer
with all 32 high bits set (I checked with a small test code).
When the address returned by the actual strdup code linked from glibc has
the top 33 bits zero, the conversion yields the correct results.
Therefore, the problem is hard to reproduce, it only occurred with a test
case almost exhausting my workstations memory, but frustratingly not small
tests.
After this, I also found compiler warnings for ScheduleInterface.c of the
type
implicit declaration of function ‘strdup’ [-Wimplicit-function-
declaration]
and
assignment makes pointer from integer without a cast [-Wint-conversion]
Switching from --std=c99 to --std=gnu99 fixed the problem for now.
However, this is a bug that might affect many users since the code
compiles with --std=c99 and the compiler warnings are hidden within the
thousands of other compiler warnings the ET code generates.
Also, a quick grep revealed many occurrences of strdup, although some of
them where redefined as Util_Strdup. The rest might lead to segfaults on
64 bit systems with std=c99.
My findings concern the Wheeler release, I haven't had time to check the
development version.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1816>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1943: Formaline's Simulation ID differs between processes of the same run
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: unset | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: |
-----------------------------------+----------------------------------------
Formalin's SimulationID and RunID are not unique for a run; they are
different for different MPI processes. It is probably necessary to
broadcast the IDs of process 0 at startup.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1943>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1942: Use read/write tags to synchronize variables
---------------------+------------------------------------------------------
Reporter: sbrandt | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Other | Version: development version
Keywords: |
---------------------+------------------------------------------------------
See pull request:
https://bitbucket.org/eschnett/carpet/pull-requests/13/presync/diff
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1942>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit