#1195: Modify bisection algorithm in EOS_Omni's nuc_eos
-----------------------------------+----------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version:
Keywords: |
-----------------------------------+----------------------------------------
EOS_Omni's nuc_eos routines use a bisection method to find the temperature
for a given internal energy. This bisects on the temperature T. I suggest
to bisect on log T instead, which is a more natural operation.
For example, if the temperature range is [1...1000] in some units, then
bisecting in T will examine the sequence 500, 250, 125, ..., and will thus
perform many table lookups until (say) T=10 is reached. Bisecting in log T
will find this result much faster.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1195>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1380: Support __builtin_assume_aligned
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Other | Version: development version
Keywords: |
-------------------------+--------------------------------------------------
The builtin assume_aligned tells the compiler that a certain pointer is
aligned. This can lead to more efficient code when auto-vectorization is
used.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1380>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#447: simfactory 1.0 always uses -L 3
----------------------------------------------+-----------------------------
Reporter: alexander.beck-ratzka@… | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
----------------------------------------------+-----------------------------
The perl version of simfactory always uses the debugging loglevel for
simulations. The loglevel of a cactus simulation can be specified by
setting -L to a value between 0 (none) and 3 (debug). While the cactus
default is 0, simfactory sets it to 3. The debug loglevel could lead to
huge output files.
I would suggest to set it to the cactus default, and allow a user to
increase it.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/447>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#107: Update released einsteintoolkit.bib once we have a more final version
-----------------------+----------------------------------------------------
Reporter: anonymous | Type: task
Status: new | Priority: major
Milestone: | Component: EinsteinToolkit website
Version: | Keywords:
-----------------------+----------------------------------------------------
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/107>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1299: Correct ET logo on https://www.ohloh.net/p/einsteintoolkit
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Other | Version:
Keywords: |
----------------------+-----------------------------------------------------
The Einstein Toolkit logo on <https://www.ohloh.net/p/einsteintoolkit>
looks bad, because it has the wrong aspect ratio. We should upload a
square logo instead.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1299>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#346: Detect when --reconfig is necessary
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Other | Version:
Keywords: |
----------------------+-----------------------------------------------------
Cactus sometimes outputs an error message that a configuration needs to be
reconfigured. Simfactory should notice this, and then automatically build
with --reconfig.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/346>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1065: Pass CCTK_ARGUMENTS more efficiently in Fortran
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Other | Version:
Keywords: |
-------------------------+--------------------------------------------------
CCTK_ARGUMENTS is passed differently in C and in Fortran. In C, only a
single pointer is passed, pointing to cctkGH. The cctk_... variables and
pointers to grid functions are defined locally from cctkGH. This is
efficient, because (a) only a single variable is passed, and (b) the
compiler can eliminate unused definitions.
In Fortran, all the cctk_... variables and all grid functions are passed
explicitly. This is expensive for the caller, because hundreds of
arguments have to be set up and passed to the subroutine. The compiler
cannot eliminate any unused variables.
I suggest to change the Fortran calling convention to be the same as the
one for C. Since regular Fortran pointers differ significantly from C
pointers, I suggest to use "Cray pointers" instead, which are very similar
to C pointers. Cray pointers are an extension to the Fortran standard, and
are supported by all Fortran compilers I know of.
I attach sample code that shows how to declare, define, and use this
convention.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1065>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1389: Trac html code remains bold after end of comment
----------------------------------+-----------------------------------------
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit trac | Version: development version
Keywords: |
----------------------------------+-----------------------------------------
the comment in https://trac.einsteintoolkit.org/ticket/1365#comment:13
accidentally turns on bold script which persists for the remaining
comments (at least using Firefox, Chroma or Opera). It would be better to
reset everything to normal at the end of each comment.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1389>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1015: increase file size limit
----------------------------------+-----------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit trac | Version:
Keywords: |
----------------------------------+-----------------------------------------
Could we increase the size limit for attached files, please? Right now it
seems to be 256k which is regularly too small if I have to attach a patch
with test data. I don't really like splitting up patches into a code patch
(uncompressed) and a gzipped data patch for the test data all the time. It
is just very very error prone.
At least for logged in users.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1015>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#907: TRAC: allow to create a ticket with review state
----------------------------------+-----------------------------------------
Reporter: bmundim | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit trac | Version:
Keywords: TRAC |
----------------------------------+-----------------------------------------
Sometimes we want to create a ticket with an attached patch and assign the
ticket to be reviewed. That should be possible with only one "modify
ticket". Currently we need to create the ticket with the attachment and
then modify the ticket afterwards to review state. The problem is that
sometimes we forget to change to review state. It would be nice to do it
all at once.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/907>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit