On Mon, Feb 13, 2017 at 12:09 PM, Roland Haas rhaas@illinois.edu wrote:
Present: Eloisa, Frank, Gwyneth, Ian, Yosef, Roland, Steve, Charalampos, Steve
CarpetRegrid2:
- regrid_every is the first condition checked, it only ever does anything if the iteraton is a multiple of it
- movement threshold is an additional condition that prevents grid movement until the grids have moved a minimum distance
- there is not well known optimal regridding frequency. One consideration would be to regrid when all timelevels are "in sync" ie with the same frequency that the coarsest level steps so that there is no interpolation in time. Another competing consideration is that the black holes should not have moved too far which gives an upper limit. A reason to use regrid_every is also if the positions are not known at every timestep for example if AHFinderDirect is used. With PunctureTracker is used then the information is known at each time.
- the dominant effect is to regrid frequently enough to track the black holes moving
- Courant factor is ratio between time step and space step on the coarsest grid, to compute the courant factor on the finest grid involves the time refinement factor
To be clear, the CFL factor on finer grids need to take both the spatial and temporal refinement factors into account.
- often one sees that the time refinement factors are set 1,1,2,4,8,... instead of 1,2,4,8 which is the default. This is due to an instability in the shift evolution equations. The group in Jena found this to be important (there is a paper by Bernd Bruegmann et al), there is a paper by Erik Schnetter that gives reason for this. It is likely still required for purely Cartesian grids, for Llama (curvilinear) grids one can get away without doing so
One can set the driver conditions in the evolution and gauge equations such that this reduction is not necessary. I don't know whether this has been implemented.
- metric_timelevels is set to 3 for AHFinderDirect setting the same for lapse an shift does not do harm but there is not directly obvious reason why one would need it
QuasiLocalModes might look at lapse and shift to calculate the full four-metric and its time derivative.
-erik
- computing the energy carried of by gravitational waves is done by computing the WeylScalar on a sphere and then do the integral yourself. There are a number of analysis packages that help doing so eg SimulationTools (google find it) by Ian Hinder for Mathematica or possibly pyCactusET. The list of tools is available here:
https://docs.einsteintoolkit.org/et-docs/Analysis_and_post-processing
- some of GW extraction is shown in the gallery:
http://einsteintoolkit.org/about/gallery/gw150914 and Ian will send instructions
- if seeing NaNs when running on many nodes or other errors this is a bug and should at most lead to an error message. static_tov uses a very small grid and we would suggest using a higher resolution grid. A gut feeling would say that anything above 27 MPI ranks is difficult. The issue seems to happen for 40 MPI ranks.
Website:
- comments from Ian via email
- comments from Roland, who will incorporate them into the website repo: https://knarrff@bitbucket.org/einsteintoolkit/www.git
MHD workshop:
- https://docs.einsteintoolkit.org/et-docs/2017_MHD_Workshop has the wiki page
- Roland will write a summary in an email
ET fails to build right now
- there is an unsupported OMP pragma in MoL, seems like a compiler specific issue
- Roland suggests to check if all compilers on our "usual" clusters support "OMP simd" yet
GetComponents:
- https://trac.einsteintoolkit.org/ticket/1916 contains a parallelization for GetComponents please give it a try to see if you can make it break
Yours, Roland
-- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://keys.gnupg.net.
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users