Users August 2015

users@lists.einsteintoolkit.org

18 participants
30 discussions

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

24 Aug '15

Present: Frank, Roland, Jonah, Steve, Peter, Matt, Erik, Josh, Zach ENO operator: * remove broken code, annotate ticket to this effect. No one is currently using it. svn on OSX: * add note to website * add test to GetComponents for behaviour Continuous Runge-Kutta interpolation in time for mesh refinement: * Ian Hawke sent around an ipython notebook outlining method * Ian Hinder may be interested to implement * transition zone inside of restricted region may not be required to get this to work Adding metadata to the HDF5 files: * no new other than what is in the email/trac thread * all information is now present (incl. active points) but Carpet supports many complex grid structures that make it hard to handle the files IllinoisGRMHD: * Zach has been cleaning up the compatibility layer * asks for second round of review Yours, Roland

1 0

IllinoisGRMHD Code Compatibility Layer
by Zach Etienne 24 Aug '15

24 Aug '15

Hi all, In conjunction with the recent update to IllinoisGRMHD, I just made public a couple of thorns that provide a HydroBase <-> IllinoisGRMHD compatibility layer. ID_converter_ILGRMHD: This thorn converts Valencia formulation variables into variables IllinoisGRMHD can read, making it possible to input HydroBase-compatible initial data into IllinoisGRMHD. convert_to_HydroBase: This thorn converts IllinoisGRMHD GRMHD variables into variables compatible with HydroBase every "convert_to_HydroBase_every" iterations. This thorn enables you to use HydroBase-compatible analysis thorns with IllinoisGRMHD. There are a couple items on the TODO list for these thorns: 1) Because there is no uniform scheduling bin that runs after HydroBase_Initial, one must edit ID_converter_ILGRMHD/schedule.ccl to force the ID converter to be run AFTER the final initial data function in HydroBase_Initial 2) As we discussed during the Aug 17, 2015 ET telecon, there are symlinks inside these thorns to IllinoisGRMHD source code, requiring these thorns to be placed in the same subdirectory as the main IllinoisGRMHD code. If the symlinks must go, I would like to know the least painful way of getting rid of these symlinks without duplicating code. Here's a link to the bitbucket repo: https://bitbucket.org/zach_etienne/illinoisgrmhd_compatibilitylayer -Zach * * * Zachariah Etienne Assistant Professor of Mathematics West Virginia University

3 6

Einstein Toolkit Meeting Reminder
by Frank Loeffler 23 Aug '15

23 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 Löffler

1 0

visualization-friendly HDF5 format
by Frank Loeffler 20 Aug '15

20 Aug '15

Hi, We had quite a discussion about the problems the current visualization tools have reading our hdf5 format. It became clear that we have to change/extend it, but before we think about how, I would like to see what specifically the readers have problems with. Let me start here with what I can recall, and please freely add to that. One of the problems is that readers currently have to iterate over all datasets present to get to some information they need. Getting the list of all datasets by itself can take quite a while on a regular hdf5 file, but then readers also have to look at attributed within each dataset. While of of this is necessary to visualize all data in a given file, most of the time not all of the data is actually necessary, and certainly not for just 'opening the file'. operations a reader needs to be fast: - list of variables (at a given iteration) - list of time steps / iterations - AMR structure for one given iteration (all maps, rls and components) Regardless of these additional meta-data, we already established the need for a meta-data file, effectively a copy of all datasets but without the actual data. Am I remembering correctly that the idea was to write this at run-time (eventually - right now it could be generated as post-processing)? Is this all readers would need? Frank

4 6

Re: [Users] debugging kranc .m
by Comer Duncan 20 Aug '15

20 Aug '15

Thanks for the suggestions. I've made some modifications and the make gets a lot further along now. It complains about a lookup error: Error: lookup failure: key Name not found in map {} in CreateKrancThorn/Param`Private`userParameterStructs/lookup I attach the .m file and the .err file. Can someone tell me what is missing now? Thanks! Comer On Tue, Aug 18, 2015 at 9:07 AM, Eloisa Bentivegna < eloisa.bentivegna(a)ct.infn.it> wrote: > On 17/08/15 22:35, Comer Duncan wrote: > > Eloisa, > > > > Thanks. I've made the change. Unfortunately it did not seem to make a > > difference in the output. > > Hi Comer, > > the change gets rid of the error message for me, but then I bump into a > number of other syntax issues with the notebook (for instance, the > expression "one -> 1" can't be used outside of a calculation, and should > be replaced by "one = 1"). I can try to comb through the code if you > like, but I'll need a day or two to finish. > > Eloisa > >

2 1

Timelike and null geodesic integrator
by Yosef Zlochower 19 Aug '15

19 Aug '15

Hi, I was looking for advice on implementing an integrator for timelike and null geodesics during an ET simulation. The confusion I have is how to deal with AMR. Ideally, I'd like to use RK4 and MoL, but I foresee several issues with geodesics crossing from coarser to finer and finer to coarser zones. I do have a horrible hack that may possibly be used, but it seems overly convoluted to me. Basically, I update the grid arrays in MoL in local mode, and unless the local grid happens to be the finest grid that owns the geodesic, I set RHS to zero (there are additional hacks because MoL copies the past time level onto the current one automatically). But still there is the issue of geodesics crossing AMR boundaries. In particular, when moving from fine to coarse, the geodesic may end up being behind because the finer grid may be at an earlier time than the coarser one. One possible workaround would be to update the geodesics during every iteration on the finest level. This would imply that I would need to interpolate the metric, shift, and lapse (and their derivatives) during each ministep of the finest level even if the point being interpolated doesn't exist on the finest level. This, in turn, means that the carpet would need to interpolate those points in time during the ministep where the local time will at some intermediate time between cctk_time(old) and cctk_time(new). I don't think this works correctly in the current version of carpet. An alternative method I was considering was a second-order in time integration. For this, I would need to be able to interpolate the metric and its derivatives during the current (finest level) time and the previous (finest level) time. For the moment, I'd be happy to assume that the finest refinement level will not change during the evolution. -- Dr. Yosef Zlochower Center for Computational Relativity and Gravitation Associate Professor School of Mathematical Sciences Rochester Institute of Technology 85 Lomb Memorial Drive Rochester, NY 14623 Office:74-2067 Phone: +1 585-475-6103 yosef(a)astro.rit.edu CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

3 5

Re: [Users] debugging kranc .m
by Ian Hinder 18 Aug '15

18 Aug '15

On 11 Aug 2015, at 15:07, Comer Duncan <comer.duncan(a)gmail.com> wrote: > Hi Ian, > > Yes, I have a recurring error which I can't track down. In fact there are probably several things wrong with the script. I am attaching the script BrillAnalytic.m and BrillAnalytic.err. I can not seem to locate a missing paren or bracket or brace. vi tells me that there is a mismatch of 1 in the occurrence of a '[' and a ']' . Also I am not at all sure that I have configured the calculation of TrRicci correctly. On one hand I specify gxx,gxy,gxz, etc but never associate these expressions with g[la,lb]. I guess I don't understand well enough the working of Kranc. Thanks for taking a look! Hi Comer, Observations in the order I have them: You can't define q[rho1_,zcyl_] in the way that you have, inside the calculation. The mathematica expression f[x_] := y has the effect of defining the function f, but returns Null. So you effectively have epsi -> one, Null, rho1 -> Sqrt[x*x + y*y], in your calculation. Just move this to outside the calculation. Get["KrancThorn`]"; should be Get["KrancThorn`"]; *that* was a subtle mistake! I commented out the whole of the rest of the file before I found it! The issue is that the closing parenthesis is inside the string (before the ") so Mathematica thinks the whole of the rest of the file is inside the Get[], and when it reaches the end of the file, it complains that the Get hasn't been terminated. This is your main error. 1/detg detgExpr is indeed 1. However, detg is calculated from g only once, rather than in every component of gu, so it is more efficient. You need to define g as a tensor. Anything which is used as a tensor in the .m file needs to be defined as a tensor with DefineTensor. This is the cause of the RecursionLimit errors, which happen in MatrixInverse. Kranc could in fact detect this; I am thinking about how to add such a check. The standard 3+1 metric variables are defined in the ADMBase thorn, and are called gxx, gxy, etc. Kranc needs tensors to be called g11, g12, etc, so we usually just redefine these components: g11=gxx; g21=gxy; g22=gyy; g31=gxz; g32=gyz; g33=gzz You might want to take a look at https://bitbucket.org/einsteintoolkit/einsteinanalysis/src/master/WeylScal4… which is a thorn for computing the Weyl scalars from the ADMBase variables, which is similar to what you are trying to do in TrRicciCalc. -- Ian Hinder http://members.aei.mpg.de/ianhin

3 5

Einstein Toolkit Meeting Reminder
by Frank Loeffler 17 Aug '15

17 Aug '15

1 1

build of debian on Parallels on mac
by Comer Duncan 17 Aug '15

17 Aug '15

I couple of days ago I bought Parallels for my mac and then installed debian jessie. After installing some required packages today I am attempting to build ET-Hilbert. The build goes ok until the end when I get some complaints and then a make failure. I attach the output toward the end. I used the stock debian.cfg file. There seems to be a problem with MPI. I have openmpi installed as suggested at the top of the debian.cfg file. I do not have any other mpi flavors installed. Can someone please take a look at the attached file and let me know whether something sticks out? Thanks very much. Comer

5 10

Problem with the latest version of ET and example Bondi par file
by Petra Suková 17 Aug '15

17 Aug '15

Hello, I am a new user of ET and during my initial tests with the latest version of ET and the example parameter file for Bondi inflow I encountered an error, which terminates the run. I have discovered, that the problem is connected with the new variable defined in thorn EinsteinAnalysis/Hydro_Analysis in this way: CCTK_REAL Hydro_Analysis_core_rho_centroid_gf[4] type = GF Timelevels = 3 tags='checkpoint="no" tensortypealias="4u"' This variable was not in the previous version of ET. During execution of the file interpolate.c from CactusNumerical/RotatingSymmetry90, the check of the number of variables and vector length for this variable does not pass: else if (CCTK_EQUALS (tensortypealias, "4u") || CCTK_EQUALS (tensortypealias, "4d")) { assert ((numvars == (DIM+1)*vectorlength)); } because numvars = 4 and vectorlength=4. I fixed the problem in the way that I added another condition (similarly to the case of usual three-vector u or d, which is just above) else if (CCTK_EQUALS (tensortypealias, "4u") || CCTK_EQUALS (tensortypealias, "4d")) { assert ((numvars == (DIM+1)*vectorlength)|| (numvars == (DIM+1) && vectorlength == (DIM+1))); } It works for me, however, I am not sure, if it will not cause problems in some other cases. Maybe the quantity Hydro_Analysis_core_rho_centroid_gf should be defined rather as a group of four variables and not as a four-vector. Best regards, Petra --- Tato zpráva byla zkontrolována na viry programem Avast Antivirus. https://www.avast.com/antivirus

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users August 2015