#450: Output elapsed times for test cases
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
To ensure that Cactus test cases don't run for too long, and to identify
those that do, we should output the run time for all test cases together
with their results.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/450>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#229: Using a nonexistent header file should lead to an error message
--------------------+-------------------------------------------------------
Reporter: hinder | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
--------------------+-------------------------------------------------------
If I have the following in my interface.ccl,
USES INCLUDE: vectors.h
but no thorn in my thornlist provides this header file, there is no error
at compile time. Further, if I #include this file in my source file, an
empty file is included, which means that again I don't get an error. The
first indication that something is wrong is that the contents of the
header file are not available, which makes debugging the problem with the
thornlist very confusing.
I propose that the CST should emit a fatal error if one of the thorns
tries to use a header file which does not exist.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/229>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1238: implement buffer mask in CarpetEvolutionMask
---------------------------------+------------------------------------------
Reporter: rhaas | Owner: eschnett
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Carpet | Version:
Keywords: CarpetEvolutionMask |
---------------------------------+------------------------------------------
the attached patch implements a new integer valued grid function
carpetevolutionmask::buffer_mask which is set to 1 in buffer regions and 0
otherwise. It provides a testcase. Eventually I would like to add other
values such that the number correlates with the last MoL step for which
this point needs to be valid before MoL_CalcRHS but for which one cannot
compute a RHS in MoL_CalcRHS.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1238>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1222: Reduction weight for periodic domains.
------------------------+---------------------------------------------------
Reporter: bentivegna | Owner: eschnett
Type: defect | Status: new
Priority: minor | Milestone:
Component: Carpet | Version: development version
Keywords: |
------------------------+---------------------------------------------------
The reduction weight of the internal points neighboring the outer
boundaries is currently set in a "trapezoidal-rule" manner (1/2 on the box
faces, 1/4 on the edges, 1/8 on the vertices, in 3D), regardless of the
nature of the boundaries. In the case of periodic boundaries with a
Coordbase::boundary_shiftout_* parameter of zero, this leads to the
assignment of a non-zero weight to some of the boundary points. This only
yields the correct result if boundary conditions have been applied, which
sometimes isn't possible/necessary.
The attached patch introduces some logic in CarpetReduce to take care of
this case. This may not be the best way to attack the problem though. One
could tackle the way weight is assigned to zero-shiftout boundaries.
Perhaps this issue is related to #1221.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1222>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1236: ReflectionSYmmetry does not handle vector groups of vectors correctly
-----------------------------------------------------------------------+----
Reporter: rhaas | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: RelfectionSymmetry RotatingSymmetry180 RotatingSymmetry90 |
-----------------------------------------------------------------------+----
Currently we use two different way to define vectors in Cactus:
{{{
CCTK_REAL vel[3] "some vector variable"
}}}
and
{{{
CCTK_REAL vel
{
velx, vely, velz
} "some other vector variable"
}}}
both of which work with ReflectionSymmetry since it only looks at the
ordering of variables in a group (ie does vi=CCTK_FirstVarInGroup() then
assumes vi is the x component vi+1 the y component and vi+2 the z
component).
For a group of related vectors we'd like to use
{{{
CCTK_REAL nvel[42]
{
velx, vely, velz
} "bunch of vector"
}}}
which almost works in the indeed CCTK_VarIndex("velx[0]") + 1 ==
CCTK_VarIndex("vely[0]"). Unfortunately the symmetry thorns assume that
vector groups contain precisely three members. A simple fix seems to
instead assert() that the number of members is divisible by 3 and then
loop over them in chunks of three.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1236>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#1309: implement UIUC's speed-up in "evaluation" of spectral solution
--------------------------------------+-------------------------------------
Reporter: bernard.j.kelly@… | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: EinsteinToolkit thorn | Version: ET_2012_11
Keywords: twopunctures evaluation |
--------------------------------------+-------------------------------------
The accompanying svn patch applies the recently released refinement of
TwoPunctures by Vasileios Paschalidis and Zach Etienne at UIUC, greatly
reducing the time taken to properly apply the solution of the spectral
solve to all grid points.
The patch is relative to the ET_2012_11 release (though I suspect it would
apply to the upcoming 2013_05 release without modification). It passes the
TwoPunctures/test/bhns_eval test suite.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1309>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#905: NaNs in ADMBase::gxx using Development Version of ET
---------------------------------+------------------------------------------
Reporter: yosef@… | Type: defect
Status: new | Priority: major
Milestone: | Component: Other
Version: | Keywords:
---------------------------------+------------------------------------------
While testing the CCE in the ET, I stumbled across an issue
interpolating the admbase::metric at CCTK_POSTSTEP in GLOBAL mode
at particular spatial points.
The "bug" (or parfile/scheduling error) seems to be sensitive to
the exact grid setup. Basically, when I use the
qc0-mclachlan-CCE_Cauchy.par parfile, I get nans
for gxx. I made a small test thorn that only interpolates
gxx at a particular point. Nans show up at iteration 1.
attached is the parfile I used and the test thorn.
Here is the output from the above test thorn:
gxx(3.966899,0.000000,-17.630662) = 1.1160523626974641
at iter 0 on proc 1
gxx(3.966899,0.000000,-17.630662) = 1.1160523626974641
at iter 0 on proc 0
gxx(3.966899,0.000000,-17.630662) = -nan
at iter 8 on proc 1
gxx(3.966899,0.000000,-17.630662) = -nan
at iter 8 on proc 0
gxx(3.966899,0.000000,-17.630662) = -nan
at iter 16 on proc 1
gxx(3.966899,0.000000,-17.630662) = -nan
at iter 16 on proc 0
etc....
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/905>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#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