Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

Simfactory: Retired machines
by Erik Schnetter 15 May '15

15 May '15

Note: The two machines SHC (Caltech) and Trestles (SDSC) have been retired in the past month and are not accessible any more. Trestles has been replaced by Comet, an off-the-shelf petascale machine (if such a thing is possible) -- with that I want to say that it should be very easy to use. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/

1 0

Einstein Toolkit Meeting Reminder
by Frank Loeffler 14 May '15

14 May '15

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/ I short: the number is (+1) 225-578-4942 or (+1) 866-573-0359 and the conference id is 118682#. My agenda contains: - Fall workshop - PLEASE let us know if you come [1]! - Hotel booking - Release planning - release date: Mon Oct 24 2011 - freeze date: Mon Sep 26 - the day of the call! - branch name: ET_2011_10 - List of release-concerning bugs [2] - ET paper: proposed "freeze" by Oct 3rd (Mon after this call) As always: feel free to add to this list. Frank Loeffler [1] https://docs.einsteintoolkit.org/et-docs/ET_Workshop_Fall_2011#Fall_Einstei… [2] https://trac.einsteintoolkit.org/query?status=!closed&milestone=ET_2011_11&…

10 31

Test case requiring strict floating point operation ordering
by Ian Hinder 13 May '15

13 May '15

Hi, The test case test_local_interp_2 in LocalInterp2 is only supposed to pass if the compiler generates code strictly conforming to the ordering dictated by the parentheses in the source code. While this is a part of the C standard, we usually don't insist on this, and use optimisation settings which allow the compiler to reorder expressions if it can be made faster. In a test of the McLachlan RHSs that I did in 2013, I measured a 25% speed reduction from insisting on source-level operation ordering. The ordering of the expressions in the source is usually not meaningful, so reordering does not make it less correct, physically-speaking. The test_local_interp_2 test is specifically testing code which is designed to exactly reproduce symmetries, even including floating point roundoff, and so needs to have strict ordering of operations to be correct. Given that we do not require this ordering in general, having a test which only passes when it is respected is problematic. This raises the question of what to do about this test. I see the following options: 1. Force the compiler to use strict ordering on that section of the code or that file (I don't know how to do this) 2. Disable the test when strict ordering is not available 3. Remove the test entirely 4. Allow the test to fail on machines whose optionlists do not respect IEEE semantics in decreasing order of my own preference. -- Ian Hinder http://members.aei.mpg.de/ianhin

5 6

OpenCL OpenCLRuntime
by Christopher Ramirez 11 May '15

11 May '15

Hello All, I'm trying to include the OpenCL thorns to try and get WaveToyOpenCL to run. When compiling, I run into the following errors. COMPILING arrangements/CactusUtils/OpenCLRunTime/src/kernel-info.cc "/home/ram0311/Cactus/arrangements/Carpet/CarpetLib/src/typeprops.hh", line 62: warning: statement is unreachable return -1; ^ "/home/ram0311/Cactus/arrangements/Carpet/CarpetLib/src/typeprops.hh", line 73: warning: statement is unreachable return -1; ^ "/home/ram0311/Cactus/arrangements/Carpet/CarpetLib/src/typeprops.hh", line 84: warning: statement is unreachable return -1; ^ "/home/ram0311/Cactus/arrangements/CactusUtils/OpenCLRunTime/src/device.hh", line 19: catastrophic error: cannot open source file "CL/opencl.h" # include <CL/opencl.h> ^ 1 catastrophic error detected in the compilation of "/home/ram0311/Cactus/configs/opencl/build/OpenCLRunTime/kernel-info.cc". Compilation terminated. make[3]: *** [kernel-info.cc.o] Error 2 make[2]: *** [make.checked] Error 2 make[1]: *** [/home/ram0311/Cactus/configs/opencl/lib/libthorn_OpenCLRunTime.a] Error 2 I've removed the comments from the einsteintoolkit manifest to update to include everything in the thorns. I had the same error when compiling the OpenCL thorn as well.

2 5

Looking at all open tickets?
by Erik Schnetter 11 May '15

11 May '15

There used to be a link on the ET trac that lists all open tickets. Was this removed? I found this quite useful. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/

3 4

Re: [Users] [ET Trac] [Einstein Toolkit] #1764: Error with compilation of HWLOC
by Zach Etienne 11 May '15

11 May '15

Just to add my own data point: I am using my own build script in Ubuntu with OpenMPI, and I have performed many MPI-based runs (on my desktop and on clusters) with no hitch. While I'm not pushing for a switch to OpenMPI, an ubuntu-openmpi.cfg script would be convenient... -Zach * * * Zachariah Etienne Assistant Professor of Mathematics West Virginia University On Mon, May 11, 2015 at 10:09 AM, Einstein Toolkit < trac-noreply(a)einsteintoolkit.org> wrote: > #1764: Error with compilation of HWLOC > > ------------------------------------+--------------------------------------- > Reporter: maxim.barkov@… | Owner: eschnett > Type: defect | Status: assigned > Priority: blocker | Milestone: ET_2015_05 > Component: EinsteinToolkit thorn | Version: development version > Resolution: | Keywords: HWLOC > > ------------------------------------+--------------------------------------- > > Comment (by eschnett): > > Is there a reason to switch to OpenMPI? If MPICH works fine, then let's > stick with it for the release. Everything is open again one or two weeks > from now. > > Regarding Boost: I don't think we need to add such a comment. If people > want Boost, then they'll figure out that they either have to install it or > to build it themselves (maybe via Cactus). Also, Boost 1.50 is quite > outdated; Boost 1.58 is current, and with two releases per year this makes > it four years old. I expect many packages to simply not work with Boost > 1.50. > > We are very shortly before a release. Now is not the time to clean up > things. Now is the time to test things, and to fix important things that > can't be worked around. > > -- > Ticket URL: <https://trac.einsteintoolkit.org/ticket/1764#comment:18> > Einstein Toolkit <http://einsteintoolkit.org> > The Einstein Toolkit > _______________________________________________ > Trac mailing list > Trac(a)einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/trac >

1 0

Einstein Toolkit Meeting Reminder: Release
by Frank Loeffler 10 May '15

10 May '15

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 and the conference id is 118682#. All issues are welcome. The most important issue will be the upcoming release. In particular, we need to take care of all known issues that hold the release back. Please test the current state of the development version in any way you like, on machines you depend on, and report your findings. Frank Löffler

1 0

release tasks
by Frank Loeffler 09 May '15

09 May '15

Hi, Our goal is to release next week, at the beginning of next week if at all possible. This can only be achieved if we fix some things, and we agreed on working on it this week. Apart from an on-going discussion about include paths, we still have a long list of things to do. Since I might not have seen the progress on some points on this list I ask to report it here. What is left so far: - hwloc 'fiasco': we need to come to a state that builds for standard systems, for everyone who tries. Right now we have conflicting reports for Ubuntu. - include path trouble on multi-arch that might (mostly) influence users that need Fortran HDF5 support. We might suggest to build HDF5 in these cases. - regenerate thorns using Kranc (Peter): status? - test gallery examples (Frank): not done yet - tutorials (Frank): will be updated once release branches exist - Queenbee (Peter): was working on it, but is not in simfactory yet - Comet (Erik): fails too many tests - Supermuc (Bruno): any update on testsuites? - Fermi & Galileo (Italian machines, Frank): testsuites all pass, simfactory entries will be added soon - mike: updated configuration exists, but was causing trouble for Erik for unknown reason that couldn't be reproduced. At this point I would have loved to create release branches. With the current status we shouldn't. We need a little of everyone's time to make this release happen. See if you can find something to help moving things along, and if that isn't something for you, give a fresh checkout a try, to see if that works as it should on your machine. Frank

4 4

Reverted changes to Mike Simfactory entry
by Erik Schnetter 07 May '15

07 May '15

I've reverted the recent changes to Mike's Simfactory entry. With these changes I saw build failures. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/

3 4

ET Meeting Minutes
by Frank Loeffler 04 May '15

04 May '15

Hi, Present were: Bruno, Eloisa, Erik, Frank, Ian, Matt, Peter, Steve, and Zach. Zach mentioned that once the release is done he would like to get the Illinois MHD code into the ET as fast as possible. The necessary changes to Carpet have already been made (staggered operators). Bruno mentioned that it might be beneficial to have the determinant of the metric as extra GF because it might/is used in a lot of places. Performance tests would need to be done to see what the impact of that would be. Bruno also would like to see a function that would return, in some form or another, the checked out version of the ET - to be used in some of his code. It was suggested to introduce this in EinsteinBase, after the release. Ian mentioned that lately he has trouble running out of memory, although Carpet doesn't report increased usage. He sees signs of memory fragmentation and is interested to know if others see similar problems. Peter did performance tests of the rewrite branch of McLachlan, and found at most a few percent slowdown. However, some interesting parameter setting haven't been tested by this yet. Release details: Relevant wiki page: https://docs.einsteintoolkit.org/et-docs/Release_Details Release time frame: get everything possible done _this week_, release next week. Thorns generated by Kranc will be checked/regenerated by Peter. The test gallery examples will be tested/updated by Peter and Frank. Frank will also update the tutorials, where necessary. We will also need to consolidate all the tutorials that have been written at some point, and in some cases got forgotten. Results from automated tests can be found here: https://build.barrywardell.net/view/EinsteinToolkitMulti/job/EinsteinToolki… Queenbee will be added to this list, once a suitable configuration is generated (Peter), the same holds for Comet (Erik). Supermuc is unlikely to be added to that list, but will be tested manually by Bruno. Stampede-mic is (still) not working, and will not be part of the release. Pandora also shows a lot of failures, and due to its age and decreased interest will be dropped. Systems with a few failures will be looked at: mike (Peter), shelob (Frank) Standard machine files that will be tested are: - Debian (Frank) - Ubuntu (Bruno) - Fedora (Steve) - Mac OS (Erik & Ian) The release name will be "Hilbert". Frank Loeffler

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users