Users May 2016

users@lists.einsteintoolkit.org

11 participants
15 discussions

Re: [Users] [ET Trac] [Einstein Toolkit] #1326: running loopcontrol on strange number of threads fails
by Erik Schnetter 11 Apr '19

11 Apr '19

Do you have a backtrace? -erik On Sunday, March 22, 2015, Einstein Toolkit < trac-noreply(a)einsteintoolkit.org> wrote: > #1326: running loopcontrol on strange number of threads fails > ------------------------------------+--------------------------------------- > Reporter: rhaas | Owner: > Type: defect | Status: new > Priority: minor | Milestone: > Component: EinsteinToolkit thorn | Version: > Resolution: | Keywords: LoopControl > ------------------------------------+--------------------------------------- > > Comment (by rhaas): > > This still happens even with current (Sun Mar 22 18:46:21 CET 2015) trunk, > though failure looks a bit different now: > {{{ > actus_sim: > /data/rhaas/postdoc/gr/ET_trunk/configs/sim/build/LoopControl/loopcontrol.cc:312: > T {anonymous}::divexact(T, T) [with T = int]: Assertion `i % j == 0' > failed > }}} > > -- > Ticket URL: <https://trac.einsteintoolkit.org/ticket/1326#comment:1> > Einstein Toolkit <http://einsteintoolkit.org> > The Einstein Toolkit > _______________________________________________ > Trac mailing list > Trac(a)einsteintoolkit.org > http://lists.einsteintoolkit.org/mailman/listinfo/trac > -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/

3 2

No Einstein Toolkit Meeting
by Frank Loeffler 12 Jun '16

12 Jun '16

Hi, There will *not* be an Einstein Toolkit meeting today (Mon Feb 08th). The next meeting will be on Mon Feb 15th, 2016, at the new time (half an hour earlier than 'usually': 9:30am US central time). Frank Loeffler

1 1

meeting minutes for 2016-05-16
by Roland Haas 02 Jun '16

02 Jun '16

Present: Erik, Frank, Barry, Ian, Matt, Yosef, Zach, Steve, Eloisa LIGO September event simulation * Barry, Eloisa, and Ian have set up a parameter file for the GW event that LIGO detected in September * the simulation is short since the event was high masss * there is a webpage and tutorial visualization using VisIt available * provide full 3d output which is ~1TB and lightweight data which is about 500GB * an extensive Mathemtatica Notebook using SimulationTools [http://simulationtools.org/] is provided showing how to do all sorts of analysis for the simulation * restructured gallery page to have little headings about each example Feedback: * add pointer to LIGO publications eg the PRL article * point out scaling of results * get DOI or simimlar for this, plan to have "proper" publication as well, want to also publicize it in talks and to communities that do not yet produce full GR simulations ordinarily eg the physics today magazine, conceivably also include in LIGO data releases * try provide data online suggest eg NCSA's data services * suggest to make plots and movies available for download ET release: * hwloc https://trac.einsteintoolkit.org/ticket/1717 * HDF5 https://trac.einsteintoolkit.org/ticket/1851 suggest to apply https://gist.github.com/eschnett/baa8b20fd64eb524c42f https://trac.einsteintoolkit.org/raw-attachment/ticket/1851/0002-detect.sh-… and https://trac.einsteintoolkit.org/raw-attachment/ticket/1851/0001-detect.sh-… Roland to review * https://trac.einsteintoolkit.org/ticket/1853 accept revert on master for release and fix diagonal output, move into feature branch, on feature branch will merge the diagonal part of the old code and the non-diagonal code of the new code * piraha error messages https://trac.einsteintoolkit.org/ticket/1881 accept current solution * AHFinderDirect https://trac.einsteintoolkit.org/ticket/1880 Roland will commit new data, many of the now failing tests fail due to extra lines of output that was not found before * create wiki page with outstanding issues and progress documenting why each item is fixed/not fixed * collect suggestions for new release name 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.

3 7

Test failures on OS X
by Ian Hinder 01 Jun '16

01 Jun '16

Hi, I have run the ET tests on OS X. There are 5 failures (https://build.barrywardell.net/view/EinsteinToolkitMulti/job/EinsteinToolki…): IOHDF5.test_recover/1procs SphericalHarmonicReconGen.SpEC-h5-test/1procs CT_MultiLevel.boostedpuncture/2procs IOHDF5.test_recover/2procs SphericalHarmonicReconGen.SpEC-h5-test/2procs and also when running the test EinsteinInitialData/Exact/test/Schwarzschild_EF.par on one process on OS X, the test hung after running. The Cactus process was a zombie, and mpirun was waiting for it to finish. I killed the mpirun process, and everything went smoothly after that. Several of the test failures seem to be related to HDF5 (see the output pages from the link above). For example, I get these warnings: HDF5-DIAG: Error detected in HDF5 (1.10.0) thread 0: #000: H5Dio.c line 170 in H5Dread(): can't read data major: Dataset minor: Read failed #001: H5Dio.c line 418 in H5D__read(): unable to set up type info major: Dataset minor: Unable to initialize object #002: H5Dio.c line 953 in H5D__typeinfo_init(): not a datatype major: Invalid arguments to routine minor: Inappropriate type WARNING[L1,P0] (IOHDF5Util): HDF5 call 'H5Dread (dataset, rec_info->hdf5type, H5S_ALL, H5S_ALL, H5P_DEFAULT, data)' returned error code -1 and the diffs say phi.xl: substantial differences significant differences on 165 (out of 165) lines maximum absolute difference in column 2 is 1.4849088247045 maximum relative difference in column 2 is 3.18869248642747 for example, in IOHDF5.test_recover/1procs. This might be because MacPorts is now using HDF5 1.10.0, and I don't know how much this has been tested with Cactus. It introduces a format change in HDF5, but the new version is supposed to be able to read files written by old versions, so that shouldn't be an issue here. Erik, have you run the tests on any system with HDF5 1.10.0? I'm also a bit concerned that Cactus didn't abort after those HDF5 errors. -- Ian Hinder http://members.aei.mpg.de/ianhin

4 6

status release
by Frank Loeffler 31 May '16

31 May '16

Hi, I would like to give you a little update about the release. All testsuites pass now (on Jenkins). For the most part, this was 'fixing the testsuites', rather than fixing actual code. Some tickets still need to be addressed, and/or need more input: #1897 [1]: external library build issues #1853 [2]: diagonal Carpet output. The troubling patch will be moved to a feature branch and be reverted from both release and master until fixed. #1850 [4]: Stampede performance problem (reviewed ok, but not resolved) Would-be-nice tickets that potentially could make it into the release include: #1881 [3]: improve piraha error messages (needs review, and a decision about inclusion in the release, which I'll leave to the reviewer). #1894 [5]: TwoPuncture potential segfault fix (reviewed ok, but not pushed) I propose we'll use today (and tomorrow for people in the EU) to fix all of those. I'll create release branches after that, hopefully tomorrow morning (US time). I'll then send around a request to start testing as heavily as you can/dare. If you do start working on one of those tickets, leave a note here: https://trac.einsteintoolkit.org/ticket/1895 to avoid duplicated work. What is the current status of the re-worked gallery? Frank Loeffler [1] https://trac.einsteintoolkit.org/ticket/1897 [2] https://trac.einsteintoolkit.org/ticket/1853 [3] https://trac.einsteintoolkit.org/ticket/1881 [4] https://trac.einsteintoolkit.org/ticket/1850 [5] https://trac.einsteintoolkit.org/ticket/1894

4 8

Einstein Toolkit Meeting Reminder
by Frank Loeffler 30 May '16

30 May '16

Hi Please consider joining the weekly Einstein Toolkit phone call at 9:30 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/ We use a Google hangout, with the URL: https://hangouts.google.com/call/5xt7voshalqmdcztr4zhfeox2ia Frank Löffler

1 0

syntax for pointers from array in Cactus?
by Bernard Kelly 24 May '16

24 May '16

Hi. I'm having a compilation issue involving a Cactus array. I'm trying to simplify my declarations & storage by declaring/assigning storage for an array called "dataslice" in my thorn's interface.ccl (numtheta & numphi are thorn parameters): CCTK_REAL data_slices TYPE=ARRAY DISTRIB=CONSTANT DIM=3 SIZE=59,numtheta,numphi { dataslice } In my C source file, I get the pointers from the 0th rank of this array, for passing into an interpolator: CCTK_POINTER outputs[59]; for(m=0;m<59;m++){ outputs[m] = &dataslice[m][0][0]; } ---------------------------------------------------- But during compilation, I get the error >error: expression must have pointer-to-object type >outputs[m] = &dataslice[m][0][0]; Note that I *don't* get this error if I instead declare dataslice in the C file, as CCTK_REAL dataslice[59][numtheta][numphi]; So it appears that the Cactus ARRAY is not quite the same type as the C array I was using before. Can anyone enlighten me as to how I should be handling the array? Thanks, Bernard

2 3

Fwd: [Hdf-forum] hdf-1.10 and collective metadata success story
by Erik Schnetter 24 May '16

24 May '16

As many of you know, restarting a simulation from checkpoints is often slower than it should be, and we have in the past implemented several performance improvements and work-arounds to address this. However, this is still an unsolved problem. The performance of accessing HDF5 datasets (i.e. opening the datasets and/or reading attributes) was often substantially slower than expected. The performance of reading the data themselves seems to be fine. A few weeks ago, HDF5 1.10 was released. This features (optionally) a new file format that stores metadata (i.e. group directories and attributes) in a more efficient way. I always suspected that this should help with performance, but didn't run benchmarks at scale yet. Today, I see this email from Rob Latham <http://www.mcs.anl.gov/~robl/> on the HDF5 mailing list, which I copy below. Essentially: HDF5 1.10 can provide a significant performance increase, and is worth a try. If you try this at home, remember that HDF5 1.10 can create files that are backward compatible with 1.8. Obviously, if you do this, you will not see the performance benefits of the new file format. Please read the release notes to learn more about this, and about backward compatibility. Note that HDF5 1.10 also ships with a tool "h5format_convert" that converts from the 1.10 to the 1.8 format in case you have tools that can't read the new format. This conversion is very quick. -erik ---------- Forwarded message ---------- From: Rob Latham <robl(a)mcs.anl.gov> Date: Tue, May 24, 2016 at 10:44 AM Subject: [Hdf-forum] hdf-1.10 and collective metadata success story To: hdf-forum(a)lists.hdfgroup.org Since I've spent oh, only the last 8 years beating you up a bit about HDF5 metadata reads at scale, it is only fair that I share with you some good news. Thanks for implementing a scalable metadata read. It's already paying off. There was a user trying to read a large dataset on our Blue Gene. We got him using 1.10, and presto: Here's a quote from the user: Yes, I can now restore data (with hdf5 1.10). I did a large test simulation on cetus (with fewer nodes than I'd usually run, so a lot of data per node), and then followed up by restoring a real 1024-node simulation on mira: this read 6 "field files" of 3.8 GB each and 2 "particle files" of 396 GB and 2 "particle files" of 69 GB in 442 seconds. Previously it was taking on the order of an hour to read in a 4 GB field file. ==rob _______________________________________________ Hdf-forum is for HDF software users discussion. Hdf-forum(a)lists.hdfgroup.org http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org Twitter: https://twitter.com/hdf5 -- Erik Schnetter <schnetter(a)gmail.com> http://www.perimeterinstitute.ca/personal/eschnetter/

1 0

Einstein Toolkit Meeting Reminder
by Frank Loeffler 23 May '16

23 May '16

2 1

Cactus only using one "tags" string per group in interface.ccl?
by Bernard Kelly 20 May '16

20 May '16

Hi. I only just found out that these two interface.ccl declarations are *not* equivalent: * tags='checkpoint="no" Prolongation="none"' tags='tensortypealias="Scalar" tensorweight=0 tensorparity=1' * tags='checkpoint="no" Prolongation="none" 'tensortypealias="Scalar" tensorweight=0 tensorparity=1' Both compile, but in the first case, the contents of the first "tags" string is ignored (I realized this only when I was getting crashes from CarpetLib's ggf.cc on attempted prolongation). So given that only one tags value is being used for each group, Is there a reason why the compilation stage SHOULDN'T flag/fail on a repeated tags definition like the first example? Since it didn't, I just assumed it was concatenating the two strings and using all the info. [Yes, I know it's silly to have two assignments where one will do, but as often happens, I inherited some code that did it.] [I'm still using ET_2015_05 for this, in case anything's changed.] Thanks, Bernard

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users May 2016