Users February 2013

users@lists.einsteintoolkit.org

20 participants
25 discussions

Re: [Users] [Commits] [svn:einsteintoolkit] EOS_Omni/trunk/ (Rev. 74)
by Ian Hinder 24 Feb '13

24 Feb '13

On 24 Feb 2013, at 00:43, cott(a)tapir.caltech.edu wrote: > User: cott > Date: 2013/02/23 05:43 PM > > Added: > /trunk/tables/ > README, SLy_Tabulated.dat > > Modified: > /trunk/ > param.ccl, schedule.ccl > /trunk/doc/ > documentation.tex > /trunk/src/ > EOS_Omni_Handles.c, EOS_Omni_Module.F90, EOS_Omni_SingleVarCalls.F90, make.code.defn > > Log: > * add support for cold tabulated EOS (P=P(rho)) that > can be supplemented with a thermal gamma law Hi Christian, The automated build and test system picked up a problem with this commit; the build is failing now. I think you forgot to commit EOS_Omni_ColdEOSReadTable.F90. This is listed in make.code.defn: > jenkins@cactus-test:~/workspace/EinsteinToolkit$ svn cat https://svn.einsteintoolkit.org/cactus/EinsteinEOS/EOS_Omni/trunk/src/make.… > # Main make.code.defn file for thorn EOS_Omni > > # Source files in this directory > SRCS = EOS_Omni_Module.F90 EOS_Omni_Startup.F90 EOS_Omni_SingleVarCalls.F90 \ > EOS_Omni_SingleVarCalls_harm.F90 EOS_Omni_Handles.c \ > EOS_Omni_MultiVarCalls.F90 EOS_Omni_ColdEOSReadTable.F90 > > # Subdirectories containing source files > SUBDIRS = nuc_eos but is not in the repository: > jenkins@cactus-test:~/workspace/EinsteinToolkit$ svn ls https://svn.einsteintoolkit.org/cactus/EinsteinEOS/EOS_Omni/trunk/src/ > EOS_Omni_Handles.c > EOS_Omni_Module.F90 > EOS_Omni_MultiVarCalls.F90 > EOS_Omni_SingleVarCalls.F90 > EOS_Omni_SingleVarCalls_harm.F90 > EOS_Omni_Startup.F90 > make.code.defn > nuc_eos/ -- Ian Hinder http://numrel.aei.mpg.de/people/hinder

2 1

Bad Links: tools OpenDx import links
by David Bradley 24 Feb '13

24 Feb '13

I have been trying to download from the tools page the following is the results: 1. http://www.einsteintoolkit.org 2. http://cactuscode.org/documentation/visualization/ clicked on OpenDx, 3. http://cactuscode.org/documentation/visualization/openDX/ beneath the two graphics was a section OpenDXutils Package with several enumeration paragraphs like 1. importHDF5 4. Each of them resulted in : http://cactuscode.org/documentation/visualization/Visualization/ImportHDF5 Page Not Found - Error 404 Apologies, no page exists at this address. Please let the Cactus team know if there's a bad internal link somewhere.

5 5

logic of scheduling SelectBoundConds in McLachlan?
by Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] 20 Feb '13

20 Feb '13

Hi. Can someone explain to me why ML_BSSN calls SelectBoundConds within MoL_PostStep? It seems like the kind of once-off routine that would happen near the start of a simulation, rather than something that has to be performed every single timestep. I wouldn't mind, but while trying to understand why ML_BSSN was evolving so slowly on one of our machines, I looked at the TimerReport files, and saw that SelectBoundConds was taking *much* more time (like 20 times as long) than the actual RHS calculation routines. Bernard

5 13

UIUC's GRMHD Primitives (Recovery) Solver
by Zach Etienne 19 Feb '13

19 Feb '13

Dear ET folks, I had a recent discussion with Tanja Bode about the GRMHD primitives solver in Maya/ET. It seems both of our primitives (recovery) solvers (aka conservative-to-primitives routines) are based on the open-source HARM code, and there is a real push now to get GRMHD working in ET. The Illinois group would like to become more involved in contributing to the ET community, and as a show of our support, I am sending this email. I have discussed the situation with Stu Shapiro, who is happy to contribute and has permitted me to attach our HARM-based primitives solver to this email. This code is GPL version 2 or 3 (whichever you prefer to maximize compatibility with ET and the existing HARM license). As you are already familiar with HARM's solver, we include no documentation. The current solver can handle Gamma-law equations of state. It will require some work, but it should be straightforward to extend the solver to arbitrary equations of state. The solver contains a driver with some quality-control features, like taking a norm of how much the conservatives have changed before and after the solver. It also contains a standalone version, so that when the solver fails during a run, it can dump a file with all the information necessary to rerun the solver *independently of the evolution code* and debug the solver. It also outputs benchmarks (# primitives/second) by default each time it is called. Finally, it includes all of the fixes our group has developed over the years (see appendix in Etienne et al., Phys. Rev. D 85, 064029 (2012)) to assess and repair the physicality of conservatives *before* going through the Newton-Raphson routine, as well as fixing unphysical primitives when they appear. With these features, we have some confidence in the robustness of our solver. There are parts of the code where you'll find commented-out lines, as evidence that a lot of tweaking has gone into this. As with all of our codes, this solver is a work in progress. As we haven't used it, we haven't updated the standalone solver in a while, so you may need to port some of the features from primitives_generic.C if you would like to use the standalone version. -Zach, on behalf of the Illinois group

2 1

meeting minutes
by Roland Haas 18 Feb '13

18 Feb '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Present were: Frank, Tanja, Philipp, Ian, Eloisa, Bruno, Peter, Steve, Erik, Josh workshops: * developer's workshop on Sat, Sun after users workshop (27-28th of July), possibly also on Monday * Erik, Roland and Philipp, Erik, Peter and Frank, ok with either option * Tanja and Ian do not know if they will make it, but likely not * ie need video conferencing setup * room should be no problem even for Monday since we are a small group * Roland will look into room rates for hotel (with Caltech rebate, likely the Saga or Vagabond Inn) * content will likely be a TOV star, which is low enough in resolution, memory footprint to be runnable by the students * will observe oscillations in central density, do fft, possibly use VisIt * add perturbation as an exercise Yours, Roland -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEi1ooACgkQTiFSTN7SboWRjwCfQPalUSJbe5n7Nrgy8QlXkC33 ViIAoLDKSe4oimsR3NcQAwQ0F4WIvlmP =vQUV -----END PGP SIGNATURE-----

1 0

McLachlan BSSN
by Erik Schnetter 18 Feb '13

18 Feb '13

Please keep all discussion on the McLachlan BSSN code on this mailing list. This ensures that everybody knows about everything that is going on, and avoid duplicate work. At the moment, we seem to have approximately three different versions of the BSSN code that seem to be incompatible: - the (official) trunk version - a version (potentially faster and more accurate) by Jim van Meter - a more flexible version (regarding gauge conditions) by Peter Diener I would suggest that we discuss things on this list before we proceed. John, Peter, could you describe your changes here? -erik -- Erik Schnetter <schnetter(a)cct.lsu.edu> http://www.perimeterinstitute.ca/personal/eschnetter/

4 6

Einstein Toolkit Meeting Reminder
by Frank Loeffler 18 Feb '13

18 Feb '13

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 or (+1) 866-573-0359 and the conference id is 118682#. Points on my agenda: - Einstein Toolkit new users workshop - schedule (Philipp: please post schedule of summer school) - how to advertise to students not attending summer school (only with some existing knowledge in nr) - Einstein Toolkit developers meeting - following ET new users meeting - logistics (need local organizer) As always, please feel free to ask any question somehow related to the toolkit. Frank Loeffler

2 2

VisIt HDF5 AMR Vectors and Streamline Rendering
by Gregory Colten 14 Feb '13

14 Feb '13

Here is an overview of our goal: We are trying to visualize vectors in the default build of VisIt 2.6.0. Our data is in 3 sets of HDF5 files, one for each of the x, y, and z components. And for each component, there are 48 files (chunked as the output of each of the 48 processors). The simulation uses Cactus AMR grids. The total size of all of these files is roughly 30 GB, and each one individually is roughly 210 MB. We find it either takes an absurd amount of time or doesn't work at all. We have found one method of visualizing these vectors, but it is outrageously slow. Working method: This method uses 100% of one CPU and ~57% of the RAM (of 8 GB in total). It takes nearly 25 minutes to render one timestep when displaying just the Vectors module. Here's what the method includes: Database correlation between the three components (Correlation Method: Time) Data-Level comparisons: Between meshes in two different databases *Position*-Based CMFE Simply place it on the target mesh We modified the expressions to place angled brackets around <Carpet AMR grid> Made an expression that puts these three components into a vector ex {<MHD_EVOLVE--mhd_st_x>,By_position,Bz_position} Almost-working method: The only change made to the above process is in the Data-Level Comparisons: (Connectivity based instead of position based) Between meshes in two different databases *Connectivity*-Based CMFE Simply place it on the target mesh This runs significantly more quickly on the first timestep in the data. But when we try to advance to the next time step in the database correlations, we get this error: ERROR: Vector: () viewer: The databases cannot be compared because they have a different number of domains. We believe this to be a result of the moving AMR boxes, but we cannot seem to work around this. The components of the vector should each have the exact same positions as each other at all times, but VisIt seems to disagree with this. Our thoughts to resolve this primarily center around finding some manner to make the Connectivity based CMFE function. If that's not possible, we can try and see if building a parallel version of Visit 2.6.0 might help speed this up. Any advise on where to go from here?

2 1

Caltech GW Astrophysics School 2013
by Christian D. Ott 12 Feb '13

12 Feb '13

Dear Colleagues, it is a pleasure to announce the ************************************** Caltech Gravitational Wave Astrophysics School (CGWAS 2013) July 22 - 26, 2013 California Institute of Technology ************************************** CGWAS is a summer school for senior undergraduates and graduate students interested in the astrophysics of gravitational wave sources and their electromagnetic and neutrino counterparts. *** Application Deadline: March 31, 2013 *** Apply at http://www.cgwas.org . Limited support for accommodation is available. Topics covered include: - The physics of gravitational wave sources - Gravitational wave source populations - Gravitational wave detection and data analysis - Time-domain astronomy and electromagnetic counterparts - Neutrino counterparts and observation - Numerical relativity and The Einstein Toolkit Confirmed lecturers: D. Kasen (UCB/LBNL), M. Modjaz (NYU), S. Nissanke (Caltech), R. O'Shaughnessy (UWM), C. Ott (Caltech), A. Piro (Caltech), E. Schnetter (Perimeter), K. Scholberg (Duke), A. Weinstein (Caltech) Organizing Committee: L. Cadonati, C. Ott (chair), P. Moesta, S. Nissanke, A. Weinstein Poster download: http://www.cgwas.org/media/CGWAS_poster.pdf CGWAS is supported by NSF CAREER award PHY-1151197. -------------------------------------------------------------

1 0

Meeting Minutes
by Roland Haas 11 Feb '13

11 Feb '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Present: Frank, Philipp, Ian, Eloisa, Seth, Bruno, Matthew Turk, Vassilios Mewes, Tanja, Josh, Yosef * list of thorns possible to be added to ET - - also way to test thorns with ET that should work with ET - - remove Nirvana thorn from list - - keep as individual thorns since no volunteer (will be) found to merge them into a single thorn * simfactory now uses rsync's --checkpoint option by default. Erik will send email detailing need. Required when files are changed on workstation but not synchronized to cluster before they are compiled on the cluster. See description in [4]. * release branch backporting - - what we would ideally want is a global revision/branch for all of the ET, similar to the git super-repository which is not yet user-friendly enough however - - while we like this idea, it can involve a lot of work with little immediate benefit - - no consensus as to whether we should got ahead with this at this moment in time - - there was a discussion on the mailing list on this [1], [2], [3] - - further discussion postponed * parsing HDF5 Carpet metadata string with grid structure - - recommend using HDF5 attributes instead - - either in full files or if too slow in index files (option: CarpetIOHDF5::output_index = "yes"). - - Erik provided information on how Carpet's integer indexing scheme Yours, Roland [1] http://lists.einsteintoolkit.org/pipermail/users/2013-January/002758.html [2] https://trac.einsteintoolkit.org/ticket/1229 [3] https://trac.einsteintoolkit.org/ticket/1247 [4] https://trac.einsteintoolkit.org/ticket/737 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEZfD8ACgkQTiFSTN7SboXa+wCgrERrSzqsPlRZHEc/7ydq7eJC 6CoAoNr28agbJhj4jt2RV9yi8GlmBysP =6jiz -----END PGP SIGNATURE-----

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users February 2013