Hi users,
I try to perform a computation on a mesh that is composed of both structured and unstructured hexa but the simulation fails before the first time step with the following error: SIGSEGV signal (forbidden memory area access) intercepted!
I think the error can be caused by the mesh since the same setup works well on another mesh (that is composed of only structured hexa).
I am using GMSH to perform the mesh (.msh). Below are some files that could help understanding the error.
As the mesh is quite big I uploaded it on filesender: https://filesender.renater.fr/?s=downlo ... 5f76eda79a
Notice that there are warnings in the listing file about the mesh but I suppose that they are not responsible for the SIGSEV error since the error occurred before the first time step.
May you help me to understand and solve this issue ?
Best regards
forbidden memory area access
Forum rules
Please read the forum usage recommendations before posting.
Please read the forum usage recommendations before posting.
forbidden memory area access
- Attachments
-
- error_r015.txt
- (685 Bytes) Downloaded 253 times
-
- end_of_listing.txt
- (1.1 KiB) Downloaded 265 times
-
- preprocessor.log
- (6.97 KiB) Downloaded 260 times
-
- Posts: 4207
- Joined: Mon Feb 20, 2012 3:25 pm
Re: forbidden memory area access
Hello,
Do you have user-defined functions/subroutines ? According to your stack trace, the error could be there ?
Regards,
Yvan
Do you have user-defined functions/subroutines ? According to your stack trace, the error could be there ?
Regards,
Yvan
Re: forbidden memory area access
Hi Yvan and thanks for your answer.
Yes I have user-defined subroutines. I perform other tests with a smaller mesh size to run the calculation in sequential and identify the issue. The computation failed due to a user-defined subroutine and more particularly when trying to calculate and store the two vertices of each edge. Here is the code:
This code works well on fully structured mesh. I do not see what causes trouble when the mesh is also containing non structural cells. Do you have an idea?
The obtained error is:
Yes I have user-defined subroutines. I perform other tests with a smaller mesh size to run the calculation in sequential and identify the issue. The computation failed due to a user-defined subroutine and more particularly when trying to calculate and store the two vertices of each edge. Here is the code:
Code: Select all
Nseg = 36 ! number of edges+diagonals per cell
allocate(Vcell(ncelet,Nseg*2)) ! save the 2 vertices coordinates for each edge (for each cell)
allocate(Cptcell(ncelet)) ! counter of Vcell = 6(cells)*6(edges)*2(vertices per edge)=72
Vcell(:,:) = 0
Cptcell(:) = 0
! For all interior faces
! save the 2 vertices of each edge
do ifac = 1, nfac
iel1 = ifacel(1,ifac)
iel2 = ifacel(2,ifac)
do ii = ipnfac(ifac),ipnfac(ifac+1)-2
do jj = ii+1, ipnfac(ifac+1)-1
inod = nodfac(ii)
jnod = nodfac(jj)
Vcell(iel1,Cptcell(iel1)*2+1) = inod
Vcell(iel1,Cptcell(iel1)*2+2) = jnod
Cptcell(iel1) = Cptcell(iel1)+1
Vcell(iel2,Cptcell(iel2)*2+1) = inod
Vcell(iel2,Cptcell(iel2)*2+2) = jnod
Cptcell(iel2) = Cptcell(iel2)+1
enddo
enddo
enddo
The obtained error is:
Thanks againforrtl: severe (408): fort: (2): Subscript #2 of the array VCELL has value 73 which is greater than the upper bound of 72
Image PC Routine Line Source
libsaturne-5.3.so 00007FB02661A679 Unknown Unknown Unknown
cs_solver 000000000046E391 cs_user_f_initial 428 cs_user_initialization.f90
libsaturne-5.3.so 00007FB024A07353 inivar_ 197 inivar.f90
libsaturne-5.3.so 00007FB0244F67B2 caltri_ 577 caltri.f90
libcs_solver-5.3. 00007FB027EF7835 cs_run 429 cs_solver.c
libcs_solver-5.3. 00007FB027EF7B85 main 654 cs_solver.c
libc-2.28.so 00007FB012CC8CF3 __libc_start_main Unknown Unknown
cs_solver 000000000040E13E Unknown Unknown Unknown
solver script exited with status 152.
Error running the calculation.
-
- Posts: 4207
- Joined: Mon Feb 20, 2012 3:25 pm
Re: forbidden memory area access
Hello,
You crash seems to be due to an incorrect estimation of arrays size/allocation. Are you sure about the number of edges + diagonals per cell ? Are you using only hexahedral elements ?
Recent versions of the code (v7.0, or v8.0-beta)have higher level operators (in C) allowing building various mesh adjacencies in a safer manner, so upgrading could be useful (and in any case, v5.3 has been retired since the release of v6.0 in September 2019).
Regards,
Yvan
You crash seems to be due to an incorrect estimation of arrays size/allocation. Are you sure about the number of edges + diagonals per cell ? Are you using only hexahedral elements ?
Recent versions of the code (v7.0, or v8.0-beta)have higher level operators (in C) allowing building various mesh adjacencies in a safer manner, so upgrading could be useful (and in any case, v5.3 has been retired since the release of v6.0 in September 2019).
Regards,
Yvan
Re: forbidden memory area access
Hi Yvan and thanks.
Yes, this routine has been used for a long time in fully structured hexa mesh with success. Yes, according to GMSH there are only hexahedral elements.
I see that Cptcell(iel1) and Cptcell(iel2) sometimes become bigger than the allocated size of Vcell (Nseg*2=72) whereas they should not. I do not see a reason for this behavior.
For the moment, to unblock the situation, I used a if statement to allocate Vcell only if Cptcell(iel1) and Cptcell(iel2) are lower than 72. It works well on single processor but crashes on parallel computation. I do not see why in parallel computation issues occur. There are no error file created, the listing is suddenly interrupted after the partionning step. The slurm file gives:
Note that, if I remove the code provided in the message above there is no issue in parallel computation.
The moving to newer versions of the code is planned.
Yes, this routine has been used for a long time in fully structured hexa mesh with success. Yes, according to GMSH there are only hexahedral elements.
I see that Cptcell(iel1) and Cptcell(iel2) sometimes become bigger than the allocated size of Vcell (Nseg*2=72) whereas they should not. I do not see a reason for this behavior.
For the moment, to unblock the situation, I used a if statement to allocate Vcell only if Cptcell(iel1) and Cptcell(iel2) are lower than 72. It works well on single processor but crashes on parallel computation. I do not see why in parallel computation issues occur. There are no error file created, the listing is suddenly interrupted after the partionning step. The slurm file gives:
I provide the end of the listing file and the only partition_output file in attached file (i added the .txt extension to be able to upload it). The mesh output can be uploaded following the link: https://filesender.renater.fr/?s=downlo ... 65d6b35bcbAbort(17) on node 8 (rank 8 in comm 0): Fatal error in PMPI_Waitall: See the MPI_ERROR field in MPI_Status for the error code
Note that, if I remove the code provided in the message above there is no issue in parallel computation.
The moving to newer versions of the code is planned.
- Attachments
-
- domain_number_80.txt
- (278.25 KiB) Downloaded 264 times
-
- end_of_listing.txt
- (10.65 KiB) Downloaded 259 times
Re: forbidden memory area access
Hi,
I think that I have found the reason of the error. In the listing file it is written:
I think that I have found the reason of the error. In the listing file it is written:
Code: Select all
Before joining
Number of cells: 71056
Number of interior faces: 202822
Number of boundary faces: 20692
Number of vertices: 83825
Global number of boundary faces selected for joining: 11040
Element selection successfully done.
Determination of possible face intersections:
bounding-box tree layout: 3D
Global number of intersections detected: 84780
Vertex-Vertex intersections: 79557
Other intersections: 5223
Joining operation is non-conforming.
Global number of new vertices to create: 7141
Equivalences broken for 0 edges.
Edge intersections and vertex creation done.
Pre-merge for 9930 global element couples.
Max size of a merge set of vertices: 3
Excessive transitivity for 0 set(s) of vertices.
Edge removed for 0 faces (global).
Join mesh cleaning done.
Edge removed for 0 faces (global).
Join mesh cleaning done.
Merge vertices and mesh update done.
*** WARNING ***
Globally, 250 problem(s) found during the face splitting
66 open cycles,
184 edges traversed twice,
0 faces split into more than max_subfaces (= 200)
=> Eventually modify joining parameters
I think that I should not use the joining option. The user routines are not working with non conforming mesh.Joining operation is non-conforming.