On Mon, Mar 20, 2017 at 11:19 AM, Roland Haas <rhaas@illinois.edu> wrote:
Present: Frank, Eloisa, Erik, Steve, Roland, Peter, Vassili, Ian,
Roberto

Failing tests:
* boostedpuncture failure likely due to code change
* GRHydro tests shows different behaviour depending on options, the
  test seems to fail only with new enough compiler, and -ffast-math
* affected hydro tests are very sensitive to data, it may be sufficient
  to use a mild increase in resolution
* as a general approach we need to decide if we want -ffast-math or if
  removing it does not affect results too much. It may be sufficient
  for gcc to specify options that allow the same subset of fast-math
  that icc uses by default
* if fast-math is needed for good performance, then we have to relax
  test constraints for these tests

I just recall that there is another issue: Modern CPUs support fused multiply-add instructions that may provide a different (but more accurate!) result. By default, GCC will use these instructions if they are available on the hardware. Exact reproducibility would require us to avoid such instructions, unless they give identical results. As Ian mentioned, we probably do not want to exact reproducibility, though.

-erik
 
* action items:
** run production benchmark with and without -fast-math on a modern
machine (Erik), use GW150914
** check if higher resolution helps for hydro tests (Roland)

piraha parser:
* Steve has an experimental version that produces multiple syntax
  errors for ccl files
* Ian would be happy with one good syntax error per ccl file and then
  an abort, Roland would prefer multiple ones. Most importantly
  multiple errors for par files
* if parsing speed is slow (Steve obtained a speedup for parallel
  parsing in a stand-alone parser but not with the integrated parser).
  May consider c++ parser with perl fallback if speed is an issue

KNL:
* can compile on stampede2, but fail to run with a segfault at startup
* Frank managed to compile in an interactive job and run
* Roland notes that NERSC's cori has custom modules/code to allow
  compilation of KNL code on the login nodes, what works on cori does
  not work for example on a different Cray machine (internal)
* wiki for progress
  https://docs.einsteintoolkit.org/et-docs/Running_Cactus_on_Knights_Landing
* Eloisa could obtain similar performance on KNL (~80%) for vacuum
  simulation as on Broadwel node
* CINECA has seminar on KNL, someone from Trento joined and we could try
  and ask them to give an ET seminar and report back

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://pgp.mit.edu .

_______________________________________________
Users mailing list
Users@einsteintoolkit.org
http://lists.einsteintoolkit.org/mailman/listinfo/users




--