Users

users@lists.einsteintoolkit.org

3 participants
3984 discussions

Assertion `ox' failed
by Hamilton, Maria 22 Apr '21

22 Apr '21

Hello, Could I please get some help in activating the horizon finder correctly in a bns run? This is what I have in the par file: ActiveThorns = "AHFinderDirect" AHFinderDirect::find_after_individual_time[1] = 1500 AHFinderDirect::find_every = 64 AHFinderDirect::output_h_every = 128 AHFinderDirect::geometry_interpolator_name = "Lagrange polynomial interpolation" AHFinderDirect::geometry_interpolator_pars = "order=4" AHFinderDirect::surface_interpolator_name = "Lagrange polynomial interpolation" AHFinderDirect::surface_interpolator_pars = "order=4" AHFinderDirect::which_surface_to_store_info[1] = 0 AHFinderDirect::initial_guess_method [1] = "coordinate sphere" AHFinderDirect::initial_guess__coord_sphere__radius[1] = 0.3 AHFinderDirect::initial_guess__coord_sphere__x_center[1] = 0.0 AHFinderDirect::N_horizons = 1 AHFinderDirect::max_allowable_horizon_radius[1] = 3 AHFinderDirect::reset_horizon_after_not_finding[1] = "no" AHFinderDirect::origin_x[1] = 0 AHFinderDirect::move_origins = "yes" AHFinderDirect::predict_origin_movement = "yes" AHFinderDirect::reshape_while_moving = "yes" AHFinderDirect::track_origin_from_grid_scalar[1] = "yes" AHFinderDirect::track_origin_source_x[1] = "Hydro_Analysis::Hydro_Analysis_rho_max_loc[0]" AHFinderDirect::track_origin_source_y[1] = "Hydro_Analysis::Hydro_Analysis_rho_max_loc[1]" AHFinderDirect::track_origin_source_z[1] = "Hydro_Analysis::Hydro_Analysis_rho_max_loc[2]" AHFinderDirect::track_origin_from_grid_scalar[2] = "yes" AHFinderDirect::track_origin_source_x[2] = "Hydro_Analysis::Hydro_Analysis_rho_max_loc[0]" AHFinderDirect::track_origin_source_y[2] = "Hydro_Analysis::Hydro_Analysis_rho_max_loc[1]" AHFinderDirect::track_origin_source_z[2] = "Hydro_Analysis::Hydro_Analysis_rho_max_loc[2]" And this is what happens when is activated: cactus_bns: /home/babiuc/ET_2020_11/Cactus/configs/bns/build/AHFinderDirect/driver/Newton.cc:109: void AHFinderDirect::track_origin(const cGH*, AHFinderDirect::patch_system&, AHFinderDirect::AH_data*, int, bool): Assertion `ox' failed. Rank 0 with PID 22304 received signal 6 Writing backtrace to BNS_BSSN_Sly_myAHF_dx12/backtrace.0.txt ------------------------------------------------------- Primary job terminated normally, but 1 process returned a non-zero exit code. Per user-direction, the job has been aborted. thanks, Maria _______________________ Maria C. Babiuc Hamilton, Ph.D. Professor, Department of Physics College of Science, Marshall University, 1 John Marshall Drive, Huntington, WV, 25755 Room S 257, Phone: (304)696-2754

3 4

Einstein Toolkit Meeting Reminder
by users＠einsteintoolkit.org 21 Apr '21

21 Apr '21

Hello, Please consider joining the weekly Einstein Toolkit phone call at 9:00 am US central time on Thursdays. For details on how to connect and what agenda items are to be discussed, use the link below. https://docs.einsteintoolkit.org/et-docs/Main_Page#Weekly_Users_Call --The Maintainers

1 0

ET testsuite using GitHub actions
by Roland Haas 21 Apr '21

21 Apr '21

Hello all, Mohammed Jamil, who is working with the ET NCSA gravity in a summer internship, has been implementing a GitHub actions based testing system for the ET. At this point the implementation is nearly feature complete and we would like to solicit some input from the community to see where we missed thing and collect suggestions for improvement. Mohammed also agreed to give short (20 min max) presentation next week on how the system is set up so that it can be more easily used and adapted to other similar systems. Please take a look at: https://mojamil.github.io/einsteintoolkit for the current output and at https://github.com/mojamil/einsteintoolkit/gh-pages for the code behind it (in the Python scripts). Right now, clicking on older runs you can also (somewhat) see the evolution of the report page. Yours, Roland and Mohammed -- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu .

1 0

ET 2021 summer school at UIUC date selection
by Roland Haas 21 Apr '21

21 Apr '21

Hello all, we make an (almost final) selection for the date of this year's ET summer school (virtual, hosted by UIUC) in this week's ET call https://docs.einsteintoolkit.org/et-docs/Meeting_agenda at Thursday April 13th 9am US Central time. We will also discuss possible presentation / lecture / tutorial topics. Yours, Roland -- My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu .

2 2

Agenda for Thursday's Meeting
by users＠einsteintoolkit.org 19 Apr '21

19 Apr '21

Please update the Wiki with agenda items for Thursday's meeting. Thanks! https://docs.einsteintoolkit.org/et-docs/meeting_agenda --The Maintainers

1 0

Grid structure inconsistency & errors in surface mask locations
by Konrad Topolski 19 Apr '21

19 Apr '21

Thank you very much! I have managed (using a much smaller and somewhat more detailed simulation) to locate both initial horizons at least up to mass ratios around a factor of 10, which for now is sufficient for my learning purposes. In that regime, a good and quick guess can be made with r(m)=m/2 -0.0215. I had also made a very silly mistake in thinking that parameter par_b in TwoPunctures sets the position of the m_plus mass exclusively (this is what I incorrectly deduced from the TwoPunctures documentation), and the other one is deduced from center-of-mass being 0. This is of course not true. In case any future users looked here for answers, for target masses of about ~ m_plus=0.85, m_minus=0.15, I needed to go to 8 refinement levels, where the [xmin,xmax] =[-9,9], dx=0.5. A further question, if I may - what can I adjust in setting up parameters to minimize the Hamiltonian constraint violation? Best regards Konrad Topolski

2 1

Grid structure inconsistency & errors in surface mask locations
by Konrad Topolski 19 Apr '21

19 Apr '21

I have been trying a variety of initial guesses, but to no avail. The setup is, in short: par_b = 3.0 target_m_plus = 0.25 target_m_minus = 0.75 And the smaller black hole's apparent horizon gets detected easily, which cannot be said of the bigger one. My estimates for the AHFinderDirect were at -1.05 to -0.95 for the center of the ellipsoid/sphere, with initial guesses for the x_radius ranging from 0.25 to 0.4, with y_radius, z _radius about 10-20% smaller. Am I still not getting enough resolution? The refinement levels in my finest setup around x=-1 are: Carpet::max_refinement_levels =8 CarpetRegrid2::movement_threshold_1 = 0.16 CarpetRegrid2::num_levels_2 = 8 CarpetRegrid2::position_x_2 = -1.0 CarpetRegrid2::radius_2[ 1] = 64.0 CarpetRegrid2::radius_2[ 2] = 16.0 CarpetRegrid2::radius_2[ 3] = 8.0 CarpetRegrid2::radius_2[ 4] = 4.0 CarpetRegrid2::radius_2[ 5] = 3.0 CarpetRegrid2::radius_2[ 6] = 2.5 CarpetRegrid2::radius_2[ 7] = 2.0 CarpetRegrid2::movement_threshold_2 = 0.16 I do not know a-priori if this apparent horizon is best approximated by an ellipsoid (can one see this before performing the numerical simulation?) or not, but I don't know if I'm on the right track. It seems weird to me that I cannot find the x=-1 AH, even though the corresponding black hole it is ~3 times more massive. In another attempt, I tried to copy the philosophy of the setup in the GW150914.rpar file, setting the center_offset for the two punctures and other parameters, but that didn't work either. I took target_mp=0.75, target_mm=0.25, separation D=6, so xp=D*mm = 1.5, xm=D*mp=-4.5, par_b=D/2 = 3.0, center_offset=xp-half_D=-1.5 (all here: https://gist.github.com/konrad-topolski/1c208415d3edac2f428ded637153f639) I'm starting to doubt if any of these setups is correct. By the way, can I somehow redirect the outputs of all MPI processes to one file at real time, better still, override the creation of CCTK_Proc files altogether? Best regards Konrad Topolski

2 2

Grid structure inconsistency & errors in surface mask locations
by Konrad Topolski 17 Apr '21

17 Apr '21

Changing the shiftout did not help unfortunately. Here's the link to the output, errors, parameter file and my running script: Let me know if that's a preferable format. https://gist.github.com/konrad-topolski/57af20b18539cd7bcb4ae2d11993144f If it helps troubleshooting in any way, when I set up fully nonsymmetric version (i.e. zmin=-120) (no reflection symmetry in z), the error persists but now the last coordinate is affected, as in: CCTK_InterpLocalUniform(): interpolation point is either outside the grid, or inside but too close to the grid boundary! (this may be caused by a global interpolation with driver::ghost_size too small) 0-origin interpolation point number pt=2963 of N_interp_points=2964 interpolation point (x,y,z)=(2.63796e+243,1.58133e+243,3.77779e+243) grid x_min(delta_x)x_max = -122.5(1.25)122.5 grid y_min(delta_y)y_max = -122.5(1.25)122.5 grid z_min(delta_z)z_max = -122.5(1.25)3.75 Best regards Konrad Topolski

2 1

Re: [Users] 3D Carpet component with one grid point along the z direction
by Erik Schnetter 17 Apr '21

17 Apr '21

On Wed, Apr 14, 2021 at 2:06 PM Gabriele Bozzola <bozzola.gabriele(a)gmail.com> wrote: > > Hi Erik, > > thank you. > > > To correct the actual bug you noticed, one could apply a correction > > that is local to OutputSlice.cc. The code there has access to the grid > > spacing, which is the same for all components, and which could > > therefore be calculated in the same place where coord_lower and > > coord_upper are calculated (function "GetCoordinates"), and could then > > be passed to the routine that outputs the "delta" attribute. > > Is there a way to do this cleanly? In my simulation I assume dx=dy=dz, so > I can check if coord_delta[d] = 0 and set coord_delta to the correct value > as read from the other directions (in the function "GetCoordinates"). But > this would only be a workaround. If in the future I forget about this and run > with different grid spacings, this would lead to a small error that would be > pretty much impossible to find. > > Also, when I look at the function I see: > > rvect const cctk_delta_space = delta_space.at(m) * rvect(mglevelfact); > > what is delta_space? Does the 0 come from here? No; this is where the good data live. The problem is that this routine doesn't return the "delta" value, only "lower" and "upper", and "delta" is later re-calculated from these. Which is not possible if "lower" and "upper" are the same. I created a Carpet branch "eschnett/delta" where I jotted down my idea. I did not test it. Could you? In particular, there could be an error in calculating the grid spacing, and it might now be wrong, which should be easy to detect in a small test run. -erik > Thanks, > Gabriele > > On Tue, Apr 13, 2021 at 11:45 AM Erik Schnetter <schnetter(a)gmail.com> wrote: >> >> Gabriele >> >> This is indeed a funny component shape. To my knowledge, certain >> thorns will not handle it correctly, because they assume that the >> width of the domain is at least the same as the number of ghost or >> boundary points. (This assumes you're using more than one ghost and >> boundary points.) >> >> There is special code in Carpet to handle the case where a component >> is only one point wide, and which sets the width to 0 in this case. >> The reason is that Cactus does not store the grid spacing internally, >> but only the lower and upper bound of the grid. Both are identical in >> this case, so it is not possible to determine the grid spacing. >> >> In your case, the proper solution would be to ensure that no such >> component is created, as it is quite inefficient. Unfortunately, the >> domain decomposition algorithm already has to satisfy many >> constraints, and modifying it is thus difficult. One way would be to >> set "Carpet::granularity" to e.g. 4, which forces all grids to have a >> size that is a multiple of 4. This would also restrict the total >> domain sizes you can have, so using this is not straightforward. >> >> To correct the actual bug you noticed, one could apply a correction >> that is local to OutputSlice.cc. The code there has access to the grid >> spacing, which is the same for all components, and which could >> therefore be calculated in the same place where coord_lower and >> coord_upper are calculated (function "GetCoordinates"), and could then >> be passed to the routine that outputs the "delta" attribute. >> >> -erik >> >> On Tue, Apr 13, 2021 at 11:04 AM Gabriele Bozzola >> <bozzola.gabriele(a)gmail.com> wrote: >> > >> > Hello, >> > >> > one of my evolutions produced the attached file. >> > >> > What is interesting about this file is that refinement level 10 has a component >> > that has shape (1, 53, 105). So, we have only one point along the z direction. >> > I am not entirely sure how this came to be, but the problem is that the HDF5 >> > attribute 'delta' reports a cell width of 0 along the z direction: >> > >> > In [12]: with h5py.File("alp.xyz.file_0.h5") as f: >> > ...: print(f['ADMBASE::alp it=55296 tl=0 rl=10 c=0'].shape) >> > (1, 53, 105) >> > >> > In [13]: with h5py.File("alp.xyz.file_0.h5") as f: >> > ...: print(f['ADMBASE::alp it=55296 tl=0 rl=10 c=0'].attrs['delta']) >> > [0.072 0.072 0. ] >> > >> > I would have expected the value of 0.072, even if the cell has only one grid point. >> > >> > Is this a bug? >> > >> > Thanks, >> > Gabriele >> > _______________________________________________ >> > Users mailing list >> > Users(a)einsteintoolkit.org >> > http://lists.einsteintoolkit.org/mailman/listinfo/users >> >> >> >> -- >> Erik Schnetter <schnetter(a)gmail.com> >> http://www.perimeterinstitute.ca/personal/eschnetter/ -- Erik Schnetter <schnetter(a)gmail.com> http://www.perimeterinstitute.ca/personal/eschnetter/

1 0

Grid structure inconsistency & errors in surface mask locations
by Seven Eight 17 Apr '21

17 Apr '21

Hi, thanks for your response I have updated my parameter file slightly, but I am still getting some worrying warnings about interpolation. Here's the link: https://gist.github.com/konrad-topolski/f8e7ca1699ac176afeb4e31b0fc4f404 What bothers me is that the situation seems to be asymmetric with regards to coordinates x and y despite my best efforts to setup a totally symmetry-free file. grid x_min(delta_x)x_max = -126.25(1.25)125 grid y_min(delta_y)y_max = -126.25(1.25)5 <------ this is worrying grid z_min(delta_z)z_max = -6.25(1.25)125 I think that could be the reason for later failure. Also, I have added more refinement levels, but I want to fix this problem first before finding the horizons. Best regards Konrad Topolski

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

Users