Users May 2014

users@lists.einsteintoolkit.org

15 participants
23 discussions

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

PARAMCHECK and non fatal but inefficient parameter choices
by Roland Haas 03 Oct '14

03 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all, the PARAMCHECK routines normally abort if inconsistent parameters are given. I have a situation where the parameter choice is valid and the result of the simulation should be identical with or without the parameter set (assuming not bugs...), however setting the parameter is likely going to make the simulation slower. Im this particular case the parameter is CarpetLib::use_higher_order_restriction when used for a run with Carpet::refinement_centering = "vertex". In that case restriction is just a copy operation and independent of use_higher_order_restriction, for cell-centered runs this is not true anymore and this is the situation that use_higher_order_restriction was implemented for. However there is code in Carpet/Evolve.cc that calls POSTREGRID multiple times if use_higher_order_restriction is set (it has to in order to get symmetry, outer boundaries and also ghost zones right). For vertex centering nothing should happen (since there is a second call to POSTRESTRICT after all restriction is done). Options are: * do nothing since these parameters are perfectly valid if slow * warn with level CCTK_WARN_COMPLAIN ("the user should know about this but the problem is not terribly surprising") * warn with level CCTK_WARN_ALERT ("the results of this run will be wrong, and this will surprise the user, but we can still continue the run") * abort since the user most likely did not want to set the parameter Note that current practise in most code seems to be to use CCTK_WARN_COMPLAIN (Level 1) for warnings about situations that do not invalidate the result and CCTK_WARN_ABORT (Level 0) for anything that invalidates results, ie. we do not adhere to the meaning of the levels documented in src/include/cctk_WarnLevel.h . 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 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlNqrvQACgkQTiFSTN7SboVuBQCg0IhvBi92zRKRVKoe216Q6wND NEYAn25pqT33i90JbhXmBJ90jKNAP4wd =+2Fk -----END PGP SIGNATURE-----

3 4

Stampede
by Ian Hinder 07 Aug '14

07 Aug '14

Hi all, Has anyone run into problems recently with Cactus jobs on Stampede? I've had jobs die when checkpointing, and also mysteriously hanging for no apparent reason. These might be separate problems. The checkpointing issue occurred when I submitted several jobs and they all started checkpointing at the same time after 3 hours. The hang happened after a few hours of evolution, with GDB reporting > MPIDI_CH3I_MRAILI_Get_next_vbuf (vc_ptr=0x7fff00d9a8d8, vbuf_ptr=0x13) > at src/mpid/ch3/channels/mrail/src/gen2/ibv_channel_manager.c:296 > 296 for (; i < mv2_MPIDI_CH3I_RDMA_Process.polling_group_size; > ++i) Unfortunately I didn't ask for a backtrace. I'm using mvapich2. I've been in touch with support and they said the dying while checkpointing coincided with the filesystems being hit hard by my jobs, which makes sense, but they didn't see any problems in their logs, and they have no idea about the mysterious hang. I repeated the hanging job and it ran fine. -- Ian Hinder http://numrel.aei.mpg.de/people/hinder

5 13

Cleaning up "personal" machines in Simfactory
by Erik Schnetter 03 Jun '14

03 Jun '14

The following machines are marked "personal" in Simfactory's MDB. Without an active maintainer, these entries may be outdated or even useless. Please let me know if you are maintaining or using one of these; otherwise, they may be removed if they look abandoned. bethe cfermi generic hedges numrel02 numrel05 numrel06 numrel07 numrel08 numrel09 numrel10 spine tesla topf -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/

4 5

Enabling CUDA/OpenCL thorns by default in Simfactory?
by Erik Schnetter 29 May '14

29 May '14

The Einstein Toolkit thorn list contains a set of thorns for CUDA or OpenCL. These are disabled by default, since many machines don't support this. These thorns are thus checked out by default, but are not built. I suggest to add these thorns to "enabled-thorns" in Simfactory for these machines. That means that these thorns would also be built by default. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/

5 14

Make "rewrite" branch of McLachlan the default
by Erik Schnetter 28 May '14

28 May '14

I believe the "rewrite" branch of McLachlan is sufficiently stable and accurate to become the master now. The code is significantly cleaner and easier to understand, and it has (since I've been using it myself for some time now) also some features and corrections that may be desirable to have. I suggest to make this the default now. I would give a brief presentation on one of the coming Mondays explaining the design choices and the differences, and after some brief testing we would switch over. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/

1 0

Meeting Minutes
by Frank Loeffler 26 May '14

26 May '14

Hi, Present were - Peter Diener - Erik Schnetter - Ian Hinder - Frank Löffler It was decided that the thorns HelloWorldCUDA and HelloWorldOpenCL will be included in the toolkit (not enabled by default, due to their nature). Also, Ian Hinder concluded that the possibilities Cactus provides for "variables" in parameter files are sufficient for him, so that he does not plan to look further into using a scripting language for parameter files. Developers interested in the inclusion of the Illinois hydro code should be looking at the code until next week, when we will likely discuss it's inclusion. Frank Löffler

1 0

Errors in build- non-existent include directories - latest release
by David Bradley 24 May '14

24 May '14

I have been trying to build the latest release, and run into many warnings such as: COMPILING arrangements/LSUThorns/SummationByParts/src/Derivatives_6_3.F90 Warning: Nonexistent include directory "/opt/Cactus/arrangements/LSUThorns/SummationByParts/src/include" Warning: Nonexistent include directory "/opt/Cactus/arrangements /LSUThorns/SummationByParts/src/includ" Any thoughts on the above fragment. The number is puzzling. Dave

2 1

Einstein Toolkit Meeting Reminder
by Frank Loeffler 23 May '14

23 May '14

1 0

Re: [Users] [Einstein Toolkit] #1548: stdout redirection in multithreading scenario
by Gengbin Zheng 22 May '14

22 May '14

yes, that should work. But CCTK_stdout may also need to be thread private variable to avoid race condition by multiple SMP threads. So this will be similar to what I proposed to have a cctk_printf function. Gengbin On 5/22/2014 1:53 PM, Einstein Toolkit wrote: > #1548: stdout redirection in multithreading scenario > ----------------------------------+----------------------------------------- > Reporter: gzheng@… | Owner: > Type: defect | Status: reopened > Priority: major | Milestone: > Component: Cactus | Version: development version > Resolution: | Keywords: stdout redirection > ----------------------------------+----------------------------------------- > > Comment (by rhaas): > > After Gengbing's talk today and studying #1618, would it be possible to do > something as simple as this: > {{{ > static AMPI_TLS FILE *CCTK_stdout = NULL; > ... > CCTKi_CommandLineFinished(...) > { > ... > if(CCTK_MyProc(cctkGH) != 0) { > CCTK_stdout = fopen("CCTK_ProcX.out"); > } else { > // or just = stdout since we never close the file handle anyway > CCTK_stdout = freopen(stdout); > } > ... > } > }}} > ? > > We would then use CCTK_stdout in CCTK_VWarn etc. We'd still keep the > {{{dup()}}} code around for the benefit of Fortran code that does > {{{write(*,*)}}} etc. and requires redirecting the OS level file > descriptors (which may need some code to protect against multiple AMPI > ranks trying to redirect the same file descriptor). Such Fortran code > would not be compatible with AMPI (not much we can do about this I think > unless we want to change the file descriptors each time the thread > changes). > > This would make this ticket a sub-ticket of #1618 (supporting AMPI). >

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users May 2014