Users June 2015

users@lists.einsteintoolkit.org

18 participants
26 discussions

Einstein Toolkit Meeting Reminder
by Frank Loeffler 07 Jun '15

07 Jun '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 and the conference id is 118682#. Peter Diener will host the call this week. Frank Loeffler

1 0

Call for Manuscripts from Science and Education Publishing
by Dr. Elton Mack 07 Jun '15

07 Jun '15

1 0

VisIt reader?
by Comer Duncan 05 Jun '15

05 Jun '15

Hi, Is there an existing reader of Cactus data files for VisIt? I ask because I have VisIt installed on my mac and VisIt has a volume viz option built in which I'd like to try on some ET data sets. Also I have downloaded yt and would like to know whether anyone has written a reader of ET data files for yt? I seem to recall on this list recently someone was going to look into using yt for ET, but don't know how far along this is as yet. Please clue me in. Comer

5 6

Help needed in recovering from iadvertent hdf5 update on mac
by Comer Duncan 04 Jun '15

04 Jun '15

Hi Ian, I got back Monday night and yesterday decided to get CT_MultiLevel and rebuild so I can start learning how the multigrid stuff works with some examples. I got the CT_MultiLevel directories from bitbucket, copied it into place in EinsteinInitialdata. in the meantime I had done a weekly update of all my macports stuff (not a good idea!). I then proceeded to rebuild cactus. All went fine (the CT_MultiLevel seems to compile ok) until it got to iohdf5. It crashed complaining about iohdf5 stuff. I have pasted the build to http://pastebin.com/dqMtCL3A . Since the hdf5 stuff got updated I went through the procedure of deactivating and in some cases uninstalling hdf related stuff and believe I left it in the state in which no hdf5 is active. I have pasted a record of the various steps I went through as I discovered what depended on what and tried to get hdf5 unactivated. I believe I was successful. Please see the following paste: http://pastebin.com/4brgVdmE . With the optionfile having BUILD as the selected option for HDF5 as was the case when I implemented the workaround last week that you suggested. So now, I am back to a similar spot except that now I do not have mpi and/or gcc related issues. Also, I have the CT_MultiLevel stuff in place. Can you suggest some next steps which can get be out of this hdf5 fix? Thanks for the help!!! Comer

4 7

More Bizarre Scheduling Behavior in a Carpet Run (Bug?!)
by Zach Etienne 02 Jun '15

02 Jun '15

Hello. I am working on writing a diagnostic that reads in ADMBase variables (e.g., alp, betax, etc.) from a binary black hole simulation using McLachlan. The diagnostic is computed at CCTK_ANALYSIS, in a GLOBAL,LOOP-LOCAL context. Call the gridfunction quantity computed by this diagnostic, diag_data_gf. diag_data_gf is rather expensive to compute in general, so I only want it computed and output (to, e.g., IOASCII 2D data files) every 64 iterations. Setting regrid_every=64, I found that the diagnostic outputs reasonable-looking data every 64 iterations until the first actual AMR grid movement (at iteration 192). At this iteration, a large number of zones near AMR refinement boundaries in the IOASCII 2D output of diag_data_gf are set to undefined values (I have set IOASCII::out3D_ghosts=no). This is undesirable behavior! Here is what I want to happen: 1) every 64 iterations, the diagnostic computes diag_data_gf at all gridpoints on all refinement levels at CCTK_ANALYSIS (I believe GLOBAL,LOOP-LOCAL should do this). 2) After CCTK_ANALYSIS, diag_data_gf should be output to files So why does my scheduling choice yield obviously wrong values near AMR boundaries after the grids move. ******** Now here is where the situation becomes very weird: ******** When I set diag_data_gf to be computed at *every* iteration, the undefined value problem disappears! Remember, it is being called at CCTK_ANALYSIS in a GLOBAL,LOOP-LOCAL context, so diag_data_gf should be recomputed at all points on all levels prior to file output. Where are these mysterious undefined values coming from?! Upon further analysis, even at iteration 64 the diagnostic yields inconsistent results at all refinement levels except the finest one. ******** I have created a very simple thorn called ADMBaseMcLachlanTester ( math.wvu.edu/~zetienne/ADMBaseMcLachlanTester.tar.gz) that reproduces this problem (in both ET 2014 11 and ET 2015 05 releases) with a minimum of coding. All the thorn does is set a gridfunction called "myadmbaselapse", which appropriately enough, is set to ADMBase::alp at all gridpoints. In the thorn's par/ subdirectory, you'll find 2 parfiles: qc0-mclachlan-setlapseevery1.par and qc0-mclachlan-setlapseevery64.par. The former sets myadmbaselapse=alp at every cctk_iteration in CCTK_ANALYSIS, and the latter every 64 cctk_iteration's. You will notice that the former parfile yields reasonable data at iteration 192 in the admbasemclachlantester::admbasemclachlantestergfs.*.asc files. However, many nan's are produced at iteration 192 (corresponding to the first AMR grid movement) when using the latter parfile. What is causing this weird behavior? Have I uncovered a bug? -Zach * * * Zachariah Etienne Assistant Professor of Mathematics West Virginia University

4 14

Meeting Minutes
by Frank Loeffler 02 Jun '15

02 Jun '15

Hi, Present were Erik, Peter, Steve, Frank, and Jonah. The issue [1] about parameter ranges, quotes ect were discussed, and as conclusion Steve is to commit everything. Warnings will output for now, Kranc should be fixed soon, and quotes around ranges will be deprecated as soon as possible. Frank is working on providing shell-script support functions for external libraries to arrive at a better handling of external libraries. Hold off with changes on those, or coordinate with him please. Steve has been working on read/write directives in Cactus, and will continue to do so over the summer. Contact him if you are interested in that. Frank [1] https://trac.einsteintoolkit.org/ticket/1595

4 6

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users June 2015