Context for the first code branch is that some edge neighborhood is reconstructed, since the table only stores the exclusively connected element via the edge. However, there are more elements connected by this edge (but also by a face) in 3D

I'm not sure if I understand when this will fail. Which assumptions are you talking about?
Do you have a specific case showing the that we could test for?

Regarding the performance, that is clear

grid = generate_grid(Quadrilateral, (2,2));
top = ExclusiveTopology(grid);

Latest release (btiming: 55.127 ns (2 allocations: 128 bytes))

julia> getneighborhood(top, grid, FaceIndex(1, 2), true)
2-element Vector{FaceIndex}:
 FaceIndex((2, 4))
 FaceIndex((1, 2))

Master (btiming: 363.636 ns (19 allocations: 1.50 KiB))

julia> getneighborhood(top, grid, FacetIndex(1, 2), true)
2-element Vector{EdgeIndex}:
 EdgeIndex((2, 4))
 EdgeIndex((1, 2))

I'm not sure if I understand when this will fail. Which assumptions are you talking about? Do you have a specific case showing the that we could test for?

It fails if you cannot fulfill what is expected of a cell, because edges is called on a cell. The adaptive cells don't know what their global edge ids are. This doesn't matter too much, since the computations done in the code branch don't make sense anyway. The problem is how to test it

Hi! Recently I have tryed the adaptive mesh. However I find that there is something wrong with the hanging nodes. The balance tree failures at some edges. Is it something to do with the getneighborhood function?

Have you tried on the latest mk/p4est commit ?

Hi! Recently I have tryed the adaptive mesh. However I find that there is something wrong with the hanging nodes. The balance tree failures at some edges. Is it something to do with the getneighborhood function?

To answer the question: I don't think it is related to the function, since I explicitly call the neighborhood tables now. It's more likely that this is a bug from an old commit, that is hopefully fixed on a more recent commit. There were some leftover cases in the balancing code which didn't take care of some hanging nodes. Maybe it's a bug that hasn't been fixed. Is that the adaptivity example from the docs?

Hi! Recently I have tryed the adaptive mesh. However I find that there is something wrong with the hanging nodes. The balance tree failures at some edges. Is it something to do with the getneighborhood function?

To answer the question: I don't think it is related to the function, since I explicitly call the neighborhood tables now. It's more likely that this is a bug from an old commit, that is hopefully fixed on a more recent commit. There were some leftover cases in the balancing code which didn't take care of some hanging nodes. Maybe it's a bug that hasn't been fixed. Is that the adaptivity example from the docs?

No, it not from the doc examples. The examples works all right.

Interesting, do you have a MWE?

Interesting, do you have a MWE?

No. What is the MWE ? :)

ah sorry! minimum working example such that I can try to reproduce the non-balanced case :)

ah sorry! minimum working example such that I can try to reproduce the non-balanced case :)

OK, I will prepare for it as quick as possible.

Following is the script for the AMR process

using Ferrite, FerriteMeshParser
using DelimitedFiles

function iniatial_refine!(adaptive_grid, region_func; lmin=0.01)

    ip = Lagrange{RefQuadrilateral, 1}()
    qr = QuadratureRule{RefQuadrilateral}(2)
    cv = CellValues(qr, ip)

    ifVec = [false,false,false,false]

    for k = 1:100

        @info k

        marked_cells = Vector{Int64}()

        grid = Ferrite.creategrid(adaptive_grid) 

        dh = DofHandler(grid)
            add!(dh, :p, ip)
        close!(dh)

        cc = CellCache(dh)

        for cellid in 1:getncells(grid)
            reinit!(cc, cellid)
            reinit!(cv, cc)

            coords = getcoordinates(cc)

            for (i, x) in enumerate(coords)
                ifVec[i] = region_func(x)
            end

            if_close = true in ifVec

            for q_point in 1:getnquadpoints(cv)
                dΩ = getdetJdV(cv, q_point) #wᵢ * Jξ
                le = sqrt(dΩ)*2 
                ifVec[q_point] = le > lmin
            end

            if (true in ifVec) && if_close
                push!(marked_cells, cellid)
            end
        end

        if_refine = ~isempty(marked_cells)

        if ~if_refine
            break
        end

        # update the grid and buffer infomation
        Ferrite.refine!(adaptive_grid, marked_cells)
        Ferrite.balanceforest!(adaptive_grid)

    end

end

# Read the mesh file
grid_ini = get_ferrite_grid("snep.inp");
adaptive_grid = ForestBWG(grid_ini,#=maxlevel=#15);

if_in_reg_fun(x) =  abs(x[2]) < 0.01 && abs(x[1]) < 0.01

iniatial_refine!(adaptive_grid, if_in_reg_fun; lmin=0.0025)

grid_ini_fine = Ferrite.creategrid(adaptive_grid) 
ip = Lagrange{RefQuadrilateral, 1}()
dh = DofHandler(grid_ini_fine)
    add!(dh, :p, ip)
close!(dh)

VTKFile("ini_mesh", dh) do vtk
end

data = readdlm("marked_cell.txt",',')
n_refine = size(data, 1)
n_max_elem = size(data, 2)
marked_cell_Vec = Vector{Vector{Int64}}()
for k_refine in 1:n_refine
    mark_cells_now = Vector{Int64}()
    for kelem in 1:n_max_elem
        if ~isempty(data[k_refine, kelem])
            push!(mark_cells_now, data[k_refine, kelem])
        end
    end
    push!(marked_cell_Vec, mark_cells_now)
end

pvd = VTKFileCollection("ada.pvd", grid_ini_fine);
for k_refine in 1:n_refine
    @info k_refine
    Ferrite.refine!(adaptive_grid, marked_cell_Vec[k_refine])
    Ferrite.balanceforest!(adaptive_grid)
    grid = Ferrite.creategrid(adaptive_grid) 
    dh = DofHandler(grid)
    add!(dh, :p, ip)
    close!(dh)
    
    vtk = VTKFile("test/ada-$(k_refine)", grid) 
    addstep!(pvd,vtk,k_refine)
end
close(pvd)

awe.zip

The whole package is attached, which includes the mesh for each iteration. The edge belongs to cell 207(+1). I think that there may be some problem with the balance_tree! function.

Interesting! I can reproduce it. There should be some issue with the balanceforest! code, because balance_tree only balances within a single tree and if I understand the example correctly, then the problem is between two trees:

I think the usage of the functions are correct but I need to take a closer look. Anyhow, thanks for reporting :)

@termi-official and me found the problem (at least we think so). The last picture of my latest post is your initial grid, is that correct? If so, then you already start from a non-conforming grid, i.e. included hanging nodes. You need to start from a grid without hanging nodes. The topology can only handle conforming meshes and the adaptive approach relies quite heavily on the topology object

@KnutAM maybe worth to include in #974 when working on the ExclusiveTopology docs a note or warning that the stuff only works for conforming grids

@termi-official and me found the problem (at least we think so). The last picture of my latest post is your initial grid, is that correct? If so, then you already start from a non-conforming grid, i.e. included hanging nodes. You need to start from a grid without hanging nodes. The topology can only handle conforming meshes and the adaptive approach relies quite heavily on the topology object

The initial grid here is the .inp file snep.inp, which is a conforming one. Then the mesh is read and the mesh of center region (|x| < 0.01 and |y| <0.01 ) is refiened at first. After that the refined area will expand. So I think the initial mesh may not lead to the unbalance. The unbalanced mesh only appears at the last frame. I noticed the problem because it will lead to the error of nested affine constrain.

sorry for the confusion @bplcn ! I took a closer look and I think I resolved the issue on the latest commit of mk/p4est. It was some remaining logical error when the balancing happens. Specifically, the problem was that in case of refinement due to balancing another non-conformity is introduced, the check was wrong that something is "still happening" in the balancing. Could you please try the latest commit again with your code? The example works now for me:

pre balance

Now a vertex balance is triggered where the arrow tip points to, which leads on the previous version to

and now on the latest version you should get

sorry for the confusion @bplcn ! I took a closer look and I think I resolved the issue on the latest commit of mk/p4est. It was some remaining logical error when the balancing happens. Specifically, the problem was that in case of refinement due to balancing another non-conformity is introduced, the check was wrong that something is "still happening" in the balancing. Could you please try the latest commit again with your code? The example works now for me:

pre balance

Now a vertex balance is triggered where the arrow tip points to, which leads on the previous version to

and now on the latest version you should get

I have tried the last commit. It works all right now and no more errors now. Many thanks!