Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

meeting minutes for 2015-08-03
by Roland Haas 03 Aug '15

03 Aug '15

Present: Josh, Yosef, Steve, Peter, Matt, Erik, Frank, Roland No call next week due to ET meeting in Stockholm. * Apply clang-format-3.5 to CactusBase and EinsteinBase. * PITTNullCode is mostly solved, patch needs to be applied, test tolerances can then be tightened * IllinoisGRMHD: Josh is using it, Frank is trying it * script to process backtraces, ticket 1798: fine to include in either flesh or Carpet (depending on whether Carpet actively writes the backtrace or not) * rewrite branch of McLachlan: still one open issue in comments, Erik to open a new ticket with the outstanding issue * general agreement that having MoL allocate storage for ScratchSpace itself is fine, want to change client thorns to no longer set these parameters Yours, Roland

1 0

Re: [Users] Einstein Toolkit Meeting Reminder
by Frank Loeffler 01 Aug '15

01 Aug '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#. Frank Loeffler

1 0

Meeting minutes for 2015-07-27
by Roland Haas 27 Jul '15

27 Jul '15

Hello all, Present were: Josh, Matt, Roland, Peter, Yosef, Steve, Christine, Erik Merge rewrite of McLachlan: * Ian not present. Skipped. The RIT group tried McLachlan starting from ET parfile. Find that McLachlan runs significantly slower than LazEv. Will move discussion to the mailing list. Number of timelevels: * Roland raises the question of whether CCTK_MaxTimeLevels should be changed to return what CCTK_MaxActiveTimeLevels such that CCTK_MaxTimeLevels is an upper bound on CCTK_ActiveTimelevels at this point in time * consensus: rename CCTK_MaxTimeLevels to CCTK_MaxDeclaredTimeLevels * consensus: require that interface.ccl declared at least 2 timelevels to allow dynamic increase * no clear agreement yet about whether to have the driver copy data forward in time * currently Carpet internally copies data during time level cycling * suggestion to add restriction that grid functions with multiple timelevels must exist globally * worry about situation where a third party thorn enables more timelevels for variables of a thorn * want to provide as many safety features as we can rather than allow all possible uses of the code * static_assert: accept with suggestion to add CCTK_ATTRIBUTE_UNUSED Yours, Roland

1 0

Einstein Toolkit Meeting Reminder
by Steven R. Brandt 26 Jul '15

26 Jul '15

1 1

McLachlan-rewrite has landed
by Erik Schnetter 24 Jul '15

24 Jul '15

I just pushed all the changes related to the McLachlan-rewrite merge. Apart from the McLachlan Kranc scripts and the respective generated code, there are a few thorns that needed to have test results updated. I see zero test failures with these changes on Bethe, Blue Waters, Carver, Datura, Edison, Hopper, Mike, Nvidia (a Perimeter workstation), Philip, Queen Bee, Shelob, and Stampede. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/

2 11

Kranc and xAct
by Comer Duncan 22 Jul '15

22 Jul '15

Do Kranc and xAct play well together? Just curious since sometimes I do things in xAct and then may want to do the same in Kranc and it would be nice if I could just say import xAct and the work done in it to a developing Kranc script. Of course, there are several pieces of xAct, so maybe my question is not formulated precisely enough, but what do you think? Thanks. Comer

3 2

Meeting minutes for 2015-07-20
by Steven R. Brandt 22 Jul '15

22 Jul '15

Hello all, Present were Steve, Peter, Erik, Zach, Joseph, Matt * no objections to merging the rewrite branch of McLachlan - the last objection was Ian, who worried about performance. Performance is as good as before. The performance of McL dissipation is much faster. - there was some discussion about the completeness of tests, whether it was to roundoff and what sort of comparisons were done. * no objections to reformatting some util thorns with clang-format, excepting thorn Accelerator. * no objections to ticket #1786, which proposed switching to c99 inline semnatics. The ticket was moved to review_ok Tickets #1794 Backport of mpi detect.pl changes #816 include SphericalHarmonicReconASCII from PITTNULLCode #1780 Correct name of Weinberg pseudotenser are all in review_ok. Someone needs to apply them. Cheers, Steve

3 3

best way to maintain CCTK_COMPLEX precision with Fortran?
by Bernard Kelly 20 Jul '15

20 Jul '15

Hi all. The Cactus documentation shows a set of C routines CCTK_CmplxXXXXXX that presumably preserve precision between CCTK_REAL and CCTK_COMPLEX types. Is there a "right" way to handle this in Cactus with Fortran (that isn't "recode in C")? Context: I have some Fortran code in a Cactus thorn that works with real & complex fields. I've noticed that when the numbers are very large in magnitude, taking a simple real(z) drops precision --- a finite but large real part ends up as +/- Inf instead. I suspect it's dropping to single precision at some stage. Switching to "dreal" doesn't help, and avoiding the use of CCTK_COMPLEX altogether --- while possible --- leads to longer, less readable code. Thanks, Bernard

2 3

'trunk' in branch thorn
by Frank Loeffler 15 Jul '15

15 Jul '15

Hi, I just removed some extra 'trunk' directories that made it into (really 'into' some of the branches. This most likely happened using a script to create these branches, and I am sorry it wasn't caught earlier. Everything worked, of course, because these extra files didn't disturb anything. I now removed these, which should only have the effect of making a checkout of a release a bit smaller. Only four thorns had this problem: pciutils, PETSc, OpenBLAS, and OpenCL Frank

1 0

Reformatting Carpet's source code
by Erik Schnetter 14 Jul '15

14 Jul '15

I've come to like to use a tool to automatically indent and format source code. This has several advantages -- the code has automatically a consistent style, indentation errors become obvious, and one doesn't have to spend time formatting the code manually while coding. clang-format is the best such tool of which I'm aware. It's vastly better than e.g. GNU indent. I propose to re-format Carpet's source code via clang-format. Usually, changing the source code format is disruptive, since patches or local modifications won't apply cleanly any more. However, with clang-format, I don't think that this is an issue -- one can use clang-format on the modified code (e.g. a branch), which should eliminate gratuitous changes. Please comment. -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/

5 13

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users