Welcome to www.arepo-code.org Forums Arepo forum Questions about the code functionality Setting up a Sphere in 3D Cartesian Grid

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #518
    Eesha Das Gupta
    Participant

    Hi,

    I am trying to set up a spherical system in Arepo’s 3D Cartesian grid. The code snippet from create.py for my setup is below. The code terminates on the first iteration, as soon as it starts the Delauney mesh and gives me an error ‘strange zero count’. I’m trying to understand if there is something wrong with my code that interferes with the Voronoi mesh? I would greatly appreciate any help.

    Here’s the exact error message –

    VORONOI: create delaunay mesh
    VORONOI: iter=0: 824429 local points, points/sec/task = 7.19241e+06, took 0.00716405 secs
    task=7 flags=1 0 0 0  (axb)*c = 0.202966
    task=7 pp0=0 pp1=-3 pp2=-2 pp3=-1 p=1 IDs=(460098 0 0 0 469998) pos_0=(6.31456|5|1.39804) pos_1=(5|47.4264|-10) pos_2=(-31.7423|-16.2132|-10) pos_3=(5|5|50) pos=(6.31456|5|1.39804)
    TERMINATE: ******!!!!!******  Code termination on task=7, function InTetra(), file src/mesh/voronoi/voronoi_3d.c, line 3136: strange zero count

    Here is my code snippet-

    BoxSize = 10.0
    Radius = [0.0]
    xPosFromCenter = [0.0]
    yPosFromCenter = [0.0]
    zPosFromCenter = [0.0]
    
    costheta = np.linspace(1,-1,100)
    polar_angle = np.arccos(costheta)
    phi = np.linspace(0.,2.*np.pi,100)
    
    rad = np.linspace(d_ring, 0.71*Boxsize, 100)
    
    for radius_this_cell in rad:
    
        for p in phi:
             for t in polar_angle:
                xcoord = radius_this_cell * np.sin(t) * np.cos(p)
                ycoord = radius_this_cell * np.sin(t) * np.sin(p)
                zcoord = radius_this_cell * np.cos(t)
                ## only include the cell if coordinates are within the box
                if xcoord >= -0.5*Boxsize and xcoord < 0.5*Boxsize and ycoord >= -0.5*Boxsize and ycoord < 0.5*Boxsize and zcoord >= -0.5*Boxsize and zcoord < 0.5*Boxsize:
                    Radius.append( radius_this_cell )
                    xPosFromCenter.append( xcoord )
                    yPosFromCenter.append( ycoord )
                    zPosFromCenter.append( zcoord )
    #521

    It is hard to say what exactly is going wrong, but a crash at the first Voronoi-mesh construction generally hints towards a problem with the positions.

    The only thing I notice here that might go wrong is that usually numpy.linspace has by default endpoint=True, which means e.g. that you include both 0 and 2 pi as points in your phi array. This might lead to two points with identical coordinates. Adding endpoint=False should help, if this is the problem.

    A few other things to check:
    – all positions are in between 0 and Boxsize
    – there are no two identical positions
    – the assumed Boxsize in create.py is identical to the one in param.txt
    – visualizing the positions, there are no empty regions

    Let me know if any of this solves your problem.

    #522
    Eesha Das Gupta
    Participant

    Thanks! I changed upper limits for phi and polar_angle arrays so that values don’t overlap, and that fixed it. The code runs and returns a sphere for reflective boundary conditions. However, when I try running it for inflow/outflow boundary conditions (REFLECTIVE_X = 2, REFLECTIVE_Y = 2, REFLECTIVE_Z = 2) , it terminates and gives me a runtime error –
    TERMINATE: ******!!!!!****** Code termination on task=11, function timebins_get_bin_and_do_validity_checks(), file src/time_integration/timestep.c, line 741: time-step of integer size 1 not allowed

    My setup has nonperiodic selfgravity and I have HIERARCHICAL_GRAVITY turned on in my Config file as well. I have had this problem before in a 2D setup with nonperiodic selfgravity and inflow/outflow boundary conditions. Is there some issue with timestepping gravity with Inflow/Outflow boundaries or is there something I’m missing? Thanks!

    #523

    This can happen if the code operates on a moving mesh, has an outflow through boundaries, and no de-refinement active. The reason is that while gas is flowing out, the corresponding cells do not, but are ‘squished’ to the boundary. Eventually, these cells become so small that their timestep drops below the allowed value. Allowing derefinement should solve this problem, since tese boundary cells will then be simply merged with surrounding ones when they are no longer needed.

Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.