Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

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

Einstein Toolkit Meeting
by Frank Loeffler 10 Feb '13

10 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/ I short: the number is (+1) 225-578-4942 or (+1) 866-573-0359 and the conference id is 118682#. Remember that today (Feb 10th), network connections to LSU might be interrupted due to upgrades happening at LSU. This includes almost every ET service, but should be finished by tomorrow. Proposed, new thorns start to accumulate in svn.einsteintoolkit.org/manifest/branches/proposed/einsteintoolkit.th. The meeting might be a good place to present/discuss these new thorns. The current list is: CactusTest/TestFortranCrayPointers AEIThorns/TensorTypes LSUThorns/PeriodicCarpet CarpetExtra/CarpetIntegrateTest CarpetExtra/CarpetProlongateTest CarpetExtra/CarpetRegridTest CarpetExtra/Nirvana CarpetExtra/ReductionTest CarpetExtra/ReductionTest2 CarpetExtra/ReductionTest3 CarpetExtra/RegridSyncTest CarpetExtra/TestCarpetGridInfo CarpetExtra/TestLoopControl Llama/ADMDerivatives Llama/Coordinates Llama/GlobalDerivative Llama/HarmonicDecomposition Llama/Interpolate2 Llama/SphericalSlice Llama/WaveExtractL Llama/WorldTube CTGamma/CTGBase CTGamma/CTGConstraints CTGamma/CTGEvolution CTGamma/CTGGauge CTGamma/CTGMatter CTGamma/CTGRadiativeBC CTGamma/CartesianCoordinates CTGamma/Psiclops Also, backporting was an issue on the mailing list recently, mainly because we tend to do this more often than in recent years. The current status is: - There is one development branch where most of the development is supposed to be happening. This is not guaranteed to be stable, but some effort in that direction should be visible. - There might be separate development branches for features that are too disruptive, even for the development branch. They should be short-lived and be merged back as soon as possible. - There are release branches. These received some care and testing and are updated if major bugs are found. - There have been (but are not for recent releases) release tags - tagging specific versions of a release branch. This was used in the beginning of the ET, but because we hardly ever changed the release branch their usage was discontinued. This could of course be changed again. Users should not checkout using the tags, as these will (of course) not receive any fixes. - There was the question of how to find out exactly which version someone is using (keeping in mind that release branches are not a fixed code base). It was proposed to add an option to GetComponents which could list the revisions of all components and possibly even creating a hash of all of them. This could be compared with 'known versions' and would give some measure to get to this information. No patch was proposed yet to my knowledge. It would also be nice if such an option could detect any local changes/commits and flag them or possibly even create a patch. Frank Löffler

1 0

Grid structure
by Matthew Turk 08 Feb '13

08 Feb '13

Hi all, I was wondering if someone could point me at how to parse the grid structure information in a Cactus output. I hope this is the right venue for this type of question. In the output I'm examining, under the "Parameters and Global Attributes" node at root level, there's a "Grid Structure v5" dataset, which contains "grid_superstructure" and "grid_structure". Is parsing the string affiliated with the grid_superstructure component the best way of identifying the spatial extent, dimensions and refinement level of grids in the output? Thanks very much for any pointers, Matt

2 2

question about ET on Stampede (TACC)
by Bruno Giacomazzo 07 Feb '13

07 Feb '13

Hi, I'd like to compile and run ET on the new TACC cluster Stampede. Did anybody run ET on stampede? I see that there are already simfactory scripts for stampede in the ET development version, but I'm not sure if they have been already fully tested (I see that there are comments about job submission not having been tested yet). I'm also curious to know if you think that the hybrid approach can be of any use for ET/GRHydro (or ET/Whisky) on that machine. I'm not very familiar with the Intel Phi coprocessor and MIC programming (but it seems similar to GPU, except for being much easier to use). Thanks, Bruno Dr. Bruno Giacomazzo JILA - University of Colorado 440 UCB Boulder, CO 80309 USA Tel. : +1 303-492-5170 Fax : +1 303-492-5235 email : bruno.giacomazzo(a)jila.colorado.edu web: http://www.brunogiacomazzo.org ---------------------------------------------------------------------- There are only 10 types of people in the world: Those who understand binary, and those who don't ----------------------------------------------------------------------

3 9

Einstein Toolkit Seminar
by Roland Haas 04 Feb '13

04 Feb '13

Hi Please consider joining the Einstein Toolkit Seminar next week Monday, February 4h, at 10 am US central time. We will use the Einstein Toolkit Meeting venue for this, and will use a Webex seminar. Details on Webex (system requirements, how to connect, phone in numbers) will be provided in a separate email soon. Details (and eventually link to the slides) can be found at http://einsteintoolkit.org/seminars/2013_02_04/ Next weeks presenter will be Christian Reisswig from the Caltech, talking about "Three-Dimensional General-Relativistic Hydrodynamic Simulations of Binary Neutron Star Coalescence and Stellar Collapse with Multipatch Grids". Roland Haas

3 6

No Einstein Toolkit Meeting (BUT Seminar)
by Frank Loeffler 01 Feb '13

01 Feb '13

Hi, As announced earlier, instead of the usual, regular Einstein Toolkit phone call at 10 am US central time on Mondays we will have an Einstein Toolkit Seminar next Monday, February 4th, at 10 am US central time. Next weeks presenter will be Christian Reisswig from the Caltech. He will be speaking about "Three-Dimensional General-Relativistic Hydrodynamic Simulations of Binary Neutron Star Coalescence and Stellar Collapse with Multipatch Grids". Details (and eventually link to the slides) can be found at http://einsteintoolkit.org/seminars/2013_02_04/ To participate, you *need to register to receive an invitation*; see <http://einsteintoolkit.org/seminars/2013_02_04/> for instructions. If you register, you will receive an invitation email about an hour before the talk with detailed instructions, as well as a fall-back phone number for calling in. Erik Schnetter will host the seminar. Frank Löffler

1 0

Using Cactus HDF5 Vector Data in Visit 2.6.0
by Brian Taylor 30 Jan '13

30 Jan '13

I am trying to use vector data in Visit 2.6.0. Each component of the data that I have is separated into three scalar quantities. I want to know how to combine these scalars into one vector quantity that can be used in visit. So far, I have tried to do this using HDF5 data organized two ways: one where all the data for each component is in one file (for example - Bx.h5, By.h5 etc.), the other way involved having the data separated by refinement grids in 32 files per component (so, Bx_file_*.h5 where "*" is from 0 to 31). With both methods I have run into issues when trying to draw vector or streamline plots. For the single file component data, I first loaded each component into its own database. Then I used the database comparison wizard to setup an evaluation of type "Between meshes in two separate databases" for my y and z component. The target database was Bx.h5 and the target mesh was "Carpet AMR-grid" while the donor database was By.h5 and Bz.h5 respectively with donor field "MHD_EVOLVE--By" and "MHD_EVOLVE--Bz." I tried both connectivity and position based CMFE. Neither seemed to make a difference. And I just chose placed the donor field on the target mesh. I then made a database correlation based on time between my three databases. Then in the expressions editor, I made a vector mesh variable defined by {<MHD_EVOLVE--Bx>,By_comp,Bz_comp} where By_comp and Bz_comp were the resultant expressions from the database comparison wizard. <MHD_EVOLVE--Bx> is the component in the active database. I then went to add a vector plot using the vector expression. When I would click draw on the vector plot I would get the following error: Vector: (InvalidExpressionException) viewer: The expression was invalid: The expression parser encountered an unexpected token: conn_cmfe(</home/projects/By.h5:MHD_EVOLVE--By>, Carpet AMR-grid) ^^^ I don't know if this matters but in the visit window, the three carets are under "AMR" Before that, I also tried pretty much the same steps with the component files containing 32 files. I then got a similar error: Vector: (InvalidExpressionException) viewer: The expression was invalid: The expression parser encountered an unexpected token: conn_cmfe(</home/projects/B5/3d_data_201207012347/By.file_* database:MHD_EVOLVE--By>, Carpet AMR-grid) ^^^ Again, the three carets are under "AMR" I should note that I am having no trouble drawing scalar quantities with volumes plots for example. The components individually will draw properly. Has anyone successfully loaded and drawn cactus vector data either by combining three scalars in visit or by using another form of data? Thanks, Brian Taylor

2 1

Releases and backporting
by Ian Hinder 30 Jan '13

30 Jan '13

Hi, Recently, the issue of backporting fixes to the released version of the Einstein Toolkit has come up. When the code is obviously wrong in the released version, especially when this is a newly-introduced problem, we have committed the fix both to the trunk and to the release branch. There have been a small number of these commits. Now that I think about it, I see that this approach has some problems. 1. If someone says in a paper that they are using "the release" of the ET, there is no way to know which version they are using if "the release" refers to the branch (which can point to different versions as people commit occasional fixes). 2. There is no way to easily test the "proposed re-released version" before moving the release branches, at which point new users will be downloading the untested version. Version control systems have both branches and tags. Branches point to "lines of development" and tags point to specific versions. In order to identify specific releases of the code, we should use tags, for example ET_2012_11.1, ET_2012_11.2 etc. Once created, these never change. Perhaps we want the following: * Branch for trunk, as currently; * Branch for "backports"; this would be things which people think should be backported and which can then be checked out and tested easily; * Tags for tested, released versions (ET_2012_11.N) * Branch for the latest tagged version (ET_2012_11) (?) The important thing is that people know (and can state in papers) what version of the code they are using. One way to ensure this is to ask people to check out the release from a specific tag, and then to check it out again from the new tag when there is a new version. An alternative would be to always check out from the release branch, but to provide a GetComponents mechanism for upgrading from one version to the next, and for verifying that the currently checked-out code is all from the same tag. I don't want to overcomplicate things, but issue (1) listed above is important. Does anyone have some better suggestions? -- Ian Hinder http://numrel.aei.mpg.de/people/hinder

3 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users