#1964: Binary neutron star sample has poor OpenMP parallelization
-----------------------------------+----------------------------------------
Reporter: anonymous | Owner:
Type: enhancement | Status: new
Priority: unset | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: NsNs |
-----------------------------------+----------------------------------------
When running the sample from the ETK/gallery page the number of OpenMP
threads seems to be limited to 2, showing only 200% in top, although 16
OMP threads were used.
Other param files from /par go way beyond 1000%, showing that more threads
are fully used.
Could it be that there is a omp_set_num_threads(2) somewhere in the hydro
code?
http://einsteintoolkit.org/about/gallery/NsNsToHMNS/
Creating 1 MPI process per core fixes the issue, obviously, and the CPU is
fully utilized
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1964>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1968: Output time stamp in verbose build log
-------------------------+--------------------------------------------------
Reporter: knarf | Owner:
Type: enhancement | Status: new
Priority: optional | Milestone:
Component: Cactus | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
Timestamp includes sub-second granularity when available, and uses Perl to
do so in a more portable way than 'date' likely could.
At the same time, don't let 'make' output the commands necessary to
generate this debug output. This is not useful, except when debugging the
debug output, which likely a user will never do.
Pull-request at https://bitbucket.org/cactuscode/cactus/pull-requests/32
/output-time-stamp-in-verbose-build-log/diff
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1968>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1962: OpenBlas fails to compile on modern laptop
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: blocker | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: OpenBLAS |
-----------------------------------+----------------------------------------
It seems as if the cpuid_x86.c in OpenBlas (0.2.13) does not recognize
anything newer than Haswell CPUs so fails on my skylake laptop (i7-6500U).
According to the changelong http://www.openblas.net/Changelog.txt we'd
need at least Version 0.2.15 from Otctober 2015 to make this work.
This is a blocker for affected systems since one cannot compile.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1962>
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
#1965: use CCTK_BOOLEAN for useSpatialBetaDriver in ML_BSSN
-----------------------------------+----------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit thorn | Version: development version
Keywords: ML_BSSN |
-----------------------------------+----------------------------------------
This parameter used to be a string keyword accepting "yes" and "no" and
was changed to a CCTK_INT in the ML rewrite. Making it a CCTK_BOOLEAN
won't change it's C type (both CCTK_INT and CCTK_BOOLEAN are ints in C++)
but will let users use the same parfile with both pre and post-rewrite
code (or alternative the same code with pre and post-rewrite parfiles).
If we really cared about the speed we *may* consider making it a CCTK_REAL
so that {{{ifthen(v==1, a,b)}}} could be written as {{{ifthen(v, a,b)}}}
thus saving on the comparison operation required and on a int->real
conversion.
This would require adding support for Boolean Parameters to Kranc's
Param.m which does not seem difficult.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1965>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1969: Carpet::processor_topology = "recursive" does not work with one process
---------------------+------------------------------------------------------
Reporter: sbrandt | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Other | Version: development version
Keywords: |
---------------------+------------------------------------------------------
If you set Carpet::processor_topology = "recursive" and use one mpi
process, you get the following error:
{{{
terminate called after throwing an instance of 'std::out_of_range'
what(): vector::_M_range_check: __n (which is 0) >= this->size() (which
is 0)
Rank 0 with PID 19719 received signal 6
Writing backtrace to ./backtrace.0.txt
Aborted (core dumped)
}}}
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1969>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1966: provide strerror() type function in Cactus
-------------------------+--------------------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: optional | Milestone:
Component: Cactus | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
It would be useful to have a {{{sterror()}}} like function in Cactus that
could turn the error codes returned by the various flesh functions into
user readable strings.
This requires mostly that we consolidate all error codes into a single
file to make sure there are no duplicates.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1966>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit