[Users] meeting minutes for 2017-02-13

[Roland Haas]

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
* 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
* 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
* 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
Url : http://lists.einsteintoolkit.org/pipermail/users/attachments/20170213/234ad53d/attachment.bin