Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

No Einstein Toolkit Meeting
by Frank Loeffler 04 Nov '13

04 Nov '13

Hi I am sorry about the late notice, but there won't be an Einstein Toolkit call today. Release issues should be communicated on the users mailing list. Most issues have been dealt with already last week, with only a few things remaining to be fixed. I would like to urge everyone not to commit any larger changes right now, but wait until after the release with those. The next Einstein Toolkit call will happen next Monday, at the usual time. Frank Loeffler

1 0

coverage tests
by Roland Haas 31 Oct '13

31 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Steve, all, do I remember correctly that you managed to run a coverage analysis of the ET code at the last developer's meeting and had a nice way of visualizing the results? Do you have instructions anywhere on how to run this analysis? This would be useful to verify that all parts of the code (that I currently care about and am thus likely to write tests for...) are actually tested? 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJzCiMACgkQTiFSTN7SboWGwACdHm9IVbjF+Oniqs/F3xciIDqL HBkAoNVjEjtrL8tEfOmD14Geq82a/dxG =hSw9 -----END PGP SIGNATURE-----

1 0

Fortran OpenMP parallel do
by Erik Schnetter 30 Oct '13

30 Oct '13

I have just found several instances of "OpenMP parallel do" constructs in GRHydro that did not mark loop variables as private. This is a severe parallelization error that can lead to wrong results in ways that are very difficult to debug. I wonder why the compiler does not flag this. I suggest a code review before the release. While it is true that the loop index of the loop that is parallelized (usually only the outermost loop) does, in Fortran, not have to be declared as private, all other loop indices still have to be declared as private. In C, all loop indices have to be declared as private. Personally, I find it simplest to just declare all loop indices as private. This is correct: !$OMP PARALLEL DO PRIVATE(i,j,k) do k=1,nz do j=1,ny do i=1,nx And this would be wrong: !$OMP PARALLEL DO do k=1,nz do j=1,ny do i=1,nx -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/ 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/.

6 7

Meeting Minutes
by Roland Haas 30 Oct '13

30 Oct '13

Present: Erik, Frank, Roland, Ian, Steve Release date: * run testsuite by week of Nov 11th * aim for release before Supercomputing conference * Erik will start the tests on all machines, will then assign failing tests to maintainers * ask if Bruno Mundim would want to run on their machines in Frankfurt Restriction in Carpet: * commit patch to disable restriction into outer boundaries (which can never be fully filled via restriction) after release * add TODO item to optimize communication algorithm * deferred tickets ** #590 deferred to next release ** #1425 not release critical, remove milestone ** #980 deferred until after release ** #1429 patch applied, asked Bernard for exact intel compiler identification to add #ifdef to TP ** 1317 deferred until after release ** 809 deferred until after release ** 1251 deferred until after release, assign to Steve * those with patches will be added to trunk very shortly after the release * tickets for release ** Frank: apply conservative patch and disable for all intel 13 compilers starting from version known to fail. Backport more restrictive exclusion once we know of a known good version ** Roland: check if vectorization patch in PUGH needs to depend on Vectors (# 1411) ** Roland: apply first patch in #1395 ** Roland: remove OPTIONAL_IFACTIVE from #1411 ** Philipp: #1409 will include but add comment that Avec does not currently work ** Erik: #1360 (check if they even build, defer until after release) ** Ian: #626, #1075, #1387: delete faulty parfiles ** #1364 closed, suggest to require simfactories "make" option to be an executable with options. Needs to be documented. Running tests with different numbers of processors: * see comment in #1075 for decision on how to proceed if a test case asks for an explicit number of processes Yours, Roland

2 1

Re: [Users] [Einstein Toolkit] #590: McLachlan should allow other thorns to set the gauge
by Einstein Toolkit 28 Oct '13

28 Oct '13

#590: McLachlan should allow other thorns to set the gauge ------------------------------------+--------------------------------------- Reporter: bmundim | Owner: diener Type: defect | Status: assigned Priority: major | Milestone: ET_2014_05 Component: EinsteinToolkit thorn | Version: Resolution: | Keywords: ------------------------------------+--------------------------------------- Changes (by knarf): * milestone: ET_2013_11 => ET_2014_05 -- Ticket URL: <https://trac.einsteintoolkit.org/ticket/590#comment:21> Einstein Toolkit <http://einsteintoolkit.org> The Einstein Toolkit

1 0

Einstein Toolkit Meeting Reminder
by Frank Loeffler 27 Oct '13

27 Oct '13

2 2

Meeting Minutes
by Roland Haas 23 Oct '13

23 Oct '13

Present: Erik, Steve, Roland, Ian, Matt, Philipp Release date: * canonical Release milestones: * large number of tickets with milestone marker * introduce merge window before the release after which only minor changes are allowed * tickets to be deferred ** #590 deferred to next release ** #1425 not release critical, remove milestone ** #980 deferred until after release ** #1429 patch applied, asked Bernard for exact intel compiler identification to add #ifdef to TP ** 1317 deferred until after release ** 809 deferred until after release ** 1251 deferred until after release, assign to Steve * those with patches will be added to trunk very shortly after the release * assignments of tickets to maintainers, please have a look: ** Ian: #626, #1387, #1075 (interaction with simfactory, tentatively assigned) ** Roland: #1395 (apply patch), #392 ** Erik: #1360 (check if they even build, defer until after release), #1392 ** Philipp: #1409 will include but add comment that Avec does not currently work * check that tutorial still works, both the one for a workstation and the one on queenbee * further discussion on the mailing list * Ian will add description (based on email send to mailing list) on how to evolve arrays with MoL to wiki * Roland, Peter and Frank to provide examples for the gallery * check that parfiles from MHD paper work when downloaded from the website. Ideally one of the MHD paper authors other than Philipp or Roland (who ran most of them so are not good testers) Yours, Roland

1 1

Recoding of IllinoisGRMHD presentation by Zach Etienne Oct 14 2013
by Roland Haas 23 Oct '13

23 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, you can find a recording of Zach's talk at http://www.tapir.caltech.edu/~rhaas/ET/20131014_Etienne.mp4 I have also added the link to the phone call wiki page https://docs.einsteintoolkit.org/et-docs/Phone_Call_Minutes#Oct_2013 in case the location of the mp4 file moves. 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJoKcsACgkQTiFSTN7SboWDjwCdHQIAoXRdCdn8HjF9qYom2M+O PWwAniRpcLOq07Xf3E6uUbcQgW5NParh =ODkz -----END PGP SIGNATURE-----

1 0

Einstein Toolkit Meeting Reminder
by Roland Haas 20 Oct '13

20 Oct '13

Hi Please consider joining the weekly Einstein Toolkit phone call at 10 am US central time on Mondays. As usual, you can find instructions how to join on the following web site: http://einsteintoolkit.org/community/support/ In short: the number is (+1) 225-578-4942 or (+1) 866-573-0359 and the conference id is 118682#. As always, we will answer questions and hear comments that come up at the meeting. Topics: * release critical tickets [1] * outstanding issues for the next release for which we have no tickets yet * examples for gallery * MHD examples * evolving grid arrays in MoL Roland Haas [1] https://trac.einsteintoolkit.org/query?status=accepted&status=assigned&stat…

1 0

remove "old" Tmunu interface
by Roland Haas 17 Oct '13

17 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, two releases ago (Oersted) we deprecated the old interface. In the last release the default was changed to no longer support the old interface. Should we (in the upcoming release) fully remove the old interface? The old interface is extremely slow (since for each grid point there is a call to CCTK_IsThornActive()) and relies on StaticConformal (which almost no other thorn supports and which will likely break in unpredictable ways). Any opinions on this? Or is this too late to remove functionality and we should instead do so immediately after the next release? 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlJe7n8ACgkQTiFSTN7SboXs0ACfXWznfYN6JE9rzDEDlwKT3cn7 mGkAoLUdxexImDSoTbDWH9S39g+SPOGp =O2yX -----END PGP SIGNATURE-----

2 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users