#1256: scheduling MoL_PostStep in Post_Recover_Variables
--------------------+-------------------------------------------------------
Reporter: rhaas | Owner:
Type: task | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: MoL |
--------------------+-------------------------------------------------------
this is not ideal since some routines in MoL_PostStep will always change
results (eg. Con2Prim). We already removed MoL_PostStep from the past
timelevels since the prolongation cannot be handled properly.
Originally (MoL rev 137,
https://trac.einsteintoolkit.org/changeset/137/CactusNumerical/MoL) was
introduced to enforce boundary conditions and recompute the ADM variables.
Since then the policy has changed and the ADM variables are supposed to be
checkpointed (rule of thumb is that anything with more than one timelevels
should be checkpointed).
When recovering from a checkpoint the boundary conditions are currently
satisfied since CarpetIOHDF5 reads in everything that it can, incl. data
in ghost and boundary zones. This method ensures that bit identical data
is read in. Unfortunately running MoL_PostStep then changes values.
It seems as if MoL_PostStep is never required so should not be run.
The attached trivial patch adds a parameter to MoL to disable running in
Post_Recover_Variables.
Note that this is not yet are request for review but a work item since
more testing is required to decide if anything breaks when MoL_PostStep is
not run.
Tests done with GRHydro (and changes so that eg. the atmosphere mask is
identical in ghost zones [currently it is not valid in ghost zones but
also never checked in ghost zones]) gives bit identical results even when
changing the number of processors while recovering. This is a very simple
test though.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1256>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1297: Reduce time spent in cycling timelevels if there is only one timelevel.
--------------------------------------+-------------------------------------
Reporter: diener | Owner: eschnett
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Carpet | Version: development version
Keywords: performance optimization |
--------------------------------------+-------------------------------------
I noticed in a run with gridfunctions with only 1 timelevels that a
significant amount of time was spent cycling timelevels. The attached
patch makes the routine bypass a lot of code, if a grid variable only has
1 timelevel.
This reduces the total time spent in cycling timelevels from 417 s to 0.8
s for a run of 32767 iterations.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1297>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#705: Activation Order in Parameter Files
-------------------------+--------------------------------------------------
Reporter: sbrandt | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone: Cactus_4.1.0
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
At the moment the ActiveThorns list is sensitive to the order in which
thorns are activated if the ActiveThorns parameter is updated multiple
times. However, it is not sensitive to the order in which thorns are
activated if all thorns are specified in a single line. This inconsistency
should be removed, and the order should not matter in either case.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/705>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#526: Reorder ticket states
----------------------------------+-----------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit trac | Version:
Keywords: |
----------------------------------+-----------------------------------------
The order in which the ticket states is displayed (in the form where one
modifies the ticket state) should be the natural order in which a ticket
progresses. The current order is somewhat random.
I suggest this order:
new
confirmed
accept
reassign
review
resolve
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/526>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#519: Add all ET repositories to TRAC
----------------------------------+-----------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit trac | Version:
Keywords: |
----------------------------------+-----------------------------------------
TRAC provides integration with version control systems. It has a list of
repositories, and specific changesets and files can be referred to in
ticket comments and wiki pages using a convenient syntax. Several ET
repositories have been added already. I think this feature is useful, and
that the remaining repositories should be added.
It would be nice if the links were easier to type. I propose omitting the
arrangement name from the repositories, as all thorn names are probably
unique, and avoiding spaces which require extra quoting. We have several
repositories in Git and Mercurial. It would be nice to include those as
well. I believe that there are TRAC plugins to accomplish this in the
same way as for SVN.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/519>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1232: Improve output format of Carpet timer trees
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner: eschnett
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Carpet | Version:
Keywords: |
-------------------------+--------------------------------------------------
Marek Blazewicz reports:
I was using the timer tree in Carpet. Because it was not too nicely
outputted, and I had to format it manually each time, I've fixed it ;).
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1232>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#650: User is not asked for Mercurial authentication information initially
---------------------------+------------------------------------------------
Reporter: hinder | Owner: eric9
Type: defect | Status: new
Priority: major | Milestone:
Component: GetComponents | Version:
Keywords: |
---------------------------+------------------------------------------------
When running GetComponents without the "-a" (anonymous) option, the user
is asked initially for authentication information for any authenticated
repositories. However, the Carpet repository is not included in this
list. This leads to the authentication prompt much later when Carpet is
actually being checked out, and here it is not possible to say
"anonymous". I believe the problem occurs on line 846 of GetComponents:
{{{
# if AUTH_URL is defined we want to find the username:
if (
defined( $component->{AUTH_URL} )
and ( $component->{TYPE} eq 'cvs'
or $component->{TYPE} eq 'svn'
or $component->{TYPE} eq 'darcs'
or $component->{TYPE} eq 'git' )
)
{
}}}
where Mercurial (hg) is not included in that list. The attached
(untested) patch adds hg to that list, but I don't know if this is
sufficient to fix the problem.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/650>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1229: provide downloadable tarball of ET
-------------------------------------+--------------------------------------
Reporter: rhaas | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit website | Version:
Keywords: |
-------------------------------------+--------------------------------------
I created a mock up download page (with one paragraph changed) with a tar
ball of the current release version of the ET.
http://www.tapir.caltech.edu/~rhaas/ET/
To provide the tarball we would need some way to store data on the web-
sever that is not archived via svn (or live with ~200MB commmits).
Alternatively I am happy to have the tarball live in in my webspace and
keep the link though a more "permanent" storage site might be more useful.
The tarball would need to be updated whenever the release branch(es)
change.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1229>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1267: CCTK_Info, CCTK_Warn, CCTK_Error not documented
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
----------------------+-----------------------------------------------------
The reference manual lacks documentation for CCTK_Info, CCTK_Warn,
CCTK_Error. Only their "V" equivalents and their macro equivalents are
documented.
In addition, I see that the documentation claims that these three
functions are "internal" functions. This is not true -- if this was true,
they would have CCTKi_ prefixes.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1267>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit