blob: a7637849309ce3bcacc2b43af9eaa1c315411789 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
small things
set centroid variables for drift correction
I think we work properly with FishEye, but I should verify that
write an output file or files at each time step giving the
apparent horizon centroid, area, and mass
Ian Hawke points out that a better (or additional) method might be
to put all the info in Cactus "local arrays"
CCTK_INT N_horizons_found
CCTK_REAL centroid_x[N_horizons]
CCTK_REAL centroid_y[N_horizons]
CCTK_REAL centroid_z[N_horizons]
CCTK_REAL area[N_horizons]
CCTK_REAL mass[N_horizons]
and then use IOBasic or IOASCII to output these
maybe getting NaN or Inf in the interpolated geometry
shouldn't abort the Cactus run, but just fail to find the horizon
medium things
handle quadrant/octant grids with symmetry BCs
(I think current Jacobian data structures can handle this,
I just need to define a new type of patch system)
there should be a Cactus test suite
HDF5 data files (simple format and/or Werner Benger's fancy one)
move origin point to track moving BHs
write data files giving intersection of AH with a Cactus output plane
(or more generally, with a hyperslab)
export a "compute h(theta,phi)" function
so other thorns could test point membership in/outside AH etc
prevent h from going negative if the iteration isn't converging
(maybe use log(h) in Newton iteration?)
handle excision properly
(detect when interpolator tries to use data from excised region
and treat this as failure to evalute H(h) --> failure to find horizon
large things
multi-processor (interpolator, overall control)
sparse matrix elliptic solver
handle quadrant/octant grids with rotating BCs
(needs Jacobian of one ghost zone to cover two different ghost zones)
"isolated horizons" computation of BH mass and spin
detect Cartoon and rotate geometry interpolation into Cartoon plane
|
