Welcome to the forums. Please post in English or French.

You are not logged in.

#1 2020-08-18 17:09:04

SamuelTwain
Member
Registered: 2020-08-14
Posts: 18

Result Discrepancy between Abaqus and Code_Aster

Dear CAers:
     Recently I did a nonlinear (geometric nonlinearity and material nonlinearity) analysis using Abaqus and Code_Aster. The geometry is simply a quare plane. And the mesh is plane strain element. The left/right (node group "side") of the model is contrained in x direction. The bottom (node group "down" ) of the model is constrained in y direction. The material is elastic perfectly-plastic material, E=1e10 Pa, poisson ration=0.48, yeild stress=848.7 kPa. A displacement load in the y direction ( deltaY =-0.002 ) is exerted on a portion of top surface ( node group "load" ). The schematic diagram, mesh file and command file are attached below.
     Although setups of Abaqus and Code_Aster are generally the same with each other, the results differ. Total Reaction force of group "load "  is 1.31e6 N for Abaqus, but 1.76e6 N for Code_Aster. Result from Abaqus is closer to the analytical solution.
    I'm not able to figure out the reason of this discrepancy. Also, I'm not assured that all the configurations in Code_Aster are set up correctly. Would anyone kindly please give me some advice?

Thanks a lot

Samuel

Last edited by SamuelTwain (2020-08-20 10:27:23)


Attachments:
Stage_1.comm, Size: 2.71 KiB, Downloads: 35

Offline

#2 2020-08-18 17:11:25

SamuelTwain
Member
Registered: 2020-08-14
Posts: 18

Re: Result Discrepancy between Abaqus and Code_Aster

I can't post schematic diagram, mesh file and command field in one thread simultaneously. So I list them one by one. The mesh file is attached here.


Attachments:
Mesh.unv, Size: 484.7 KiB, Downloads: 31

Offline

#3 2020-08-18 17:17:08

SamuelTwain
Member
Registered: 2020-08-14
Posts: 18

Re: Result Discrepancy between Abaqus and Code_Aster

Below is the schematic diagram. I didn't adopt the same mesh as the diagram because it's too coarse. I have refined the mesh.


Attachments:
shcematicDiagram.jpg, Size: 101.26 KiB, Downloads: 57

Offline

#4 2020-08-18 23:03:47

mf
Member
Registered: 2019-06-18
Posts: 118

Re: Result Discrepancy between Abaqus and Code_Aster

Hi,

that is a classic mistake, try using 2nd order elements in the mesh module. 1st order introduces artificial stiffness-->increased reaction force.

I did a LINE_QUAD with your mesh and I get -1.30183E+06, so you are within 0.6% from Abaqus. However, convergence is quite bad (did not investigate why).

Modified .comm and .resu attached. Please mark as solved,

Mario.

Last edited by mf (2020-08-18 23:06:14)


Attachments:
LINE_QUAD.zip, Size: 1.57 KiB, Downloads: 32

Offline

#5 2020-08-19 08:26:18

SamuelTwain
Member
Registered: 2020-08-14
Posts: 18

Re: Result Discrepancy between Abaqus and Code_Aster

mf wrote:

that is a classic mistake, try using 2nd order elements in the mesh module. 1st order introduces artificial stiffness-->increased reaction force.

Thanks a lot for your helpful response. The result of Code_Aster really improves after changing mesh from first order to second order. The new mesh file, command file and result file are also attached below.

mf wrote:

However, convergence is quite bad (did not investigate why).

The difficulty of convergence might come from the strict covergence criteria. I had set 1e-6 for the relative error. By adjusting it to 0.001, convergence reaches faster without large reaction force discrepancy. In addition, ELASTIC matrice for NOWTON method also leads to more iterations.

Finally, when I did the the same simulation in Abaqus, I used the default plane strain element. I think the default element is first order. So I'm confused why second order must be used in Code_Aster to get a satisfactory result. Any idea?

Regards
Samuel


Attachments:
CA.rar, Size: 62.68 KiB, Downloads: 30

Offline

#6 2020-08-19 11:25:35

mf
Member
Registered: 2019-06-18
Posts: 118

Re: Result Discrepancy between Abaqus and Code_Aster

Hi,

second order should always be used for mechanical calculations (especially when bending is involved), in any FE-software package, if stresses are interesting (which they are in most cases).

I assume this element is also 2nd order in Abaqus but I don't know. Last time I used Abaqus was ~15 years ago.

There are 16 plane strain elements in Abaqus, 6 of which are quadratic/biquadratic. Which one did you choose/which one is the default?

Are the meshes identical?

h ttps://classes.engineering.wustl.edu/2009/spring/mase5513/abaqus/docs/v6.6/books/usb/default.htm?startat=pt06ch22s01ael02.html#usb-elm-e2delem

Mario.

Last edited by mf (2020-08-19 11:28:03)

Offline

#7 2020-08-19 13:42:01

SamuelTwain
Member
Registered: 2020-08-14
Posts: 18

Re: Result Discrepancy between Abaqus and Code_Aster

mf wrote:

There are 16 plane strain elements in Abaqus, 6 of which are quadratic/biquadratic. Which one did you choose/which one is the default?

Hi Mario,
   I refered to my Abaqus model and comfirmed that the default type of plain strain element in Abaqus is CPE4R, namely 4-node bilinear, reduced integration with hourglass control. Is bilinear element first or second order?
   In Code_Aster, I used quadrangle mesh with default "linear" option, and each element has 4 nodes attached. If linear quadrangle mesh is converted to quadratic mesh, a bonus node will be added on each edge, then each element will have 8 node. So it seems that "linear" quadrangle mesh is as same as 4-node bilinear mesh.

mf wrote:

Are the meshes identical?

   Element type has some differences. I choose D_PlAN type for element in Code_Aster. Thus, the D_PLAN element is fully integrated which is different from CPE4R with reducd integration. Although I have changed D_PLAN to D_PLAN_SI ( reduced integrated plane strain element for Code_Aster ), some errors bring out  as soon as calculation is submitted. Below is the error information:
'''
JDC.py : ERREUR WITH THE EXECUTION - INTERRUPTION
>> JDC.py: DEBUT CR of execution of JDC in MIXTE
   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
   ! <S> Exception user raised but not interceptee. !
   ! The bases are fermees.                         !
   ! Type of the exception: error                   !
   !                                                !
   !  the only valid elastic behavior is ELAS       !
   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
fine CR of execution of JDC in MIXTE

REPORT
>> JDC.py: FIN REPORT
EXECUTION_CODE_ASTER_EXIT_12929-0001-saumuel=1

<I>_EXIT_CODE = 1

'''
This message is a little bit abstract for me. It seems that, as I have used ELAS_VMIS_LINE relation in COMPORTEMENT, D_PLAN_SI is not allowed. However, my material is elastic perfectly-plastic, are there any appropriate options for COMPORTEMENT except for ELAS_VMIS_LINE ?

Besides, houglass control is also a problem. I don't know which type of plain strain element in Code_Aster can control hourglass.

I'm so confused.

Any idea will be appreciated.

Samuel

Last edited by SamuelTwain (2020-08-19 13:55:49)

Offline

#8 2020-08-19 13:51:00

mf
Member
Registered: 2019-06-18
Posts: 118

Re: Result Discrepancy between Abaqus and Code_Aster

Hi,

why use reduced integration anyway? Your calculation takes a few minutes not days or weeks. I'd say reduced integration is rather useless in your case, stick with 2nd order elements. This wil give you the most accurate results. Reduced integration is only advisable if your calculation is rather large and your hardware can't cope with it.

I have no clue why the results of bilinear in Abaqus and 2nd order in CA is comparable. This is beyond what I can do, I do not use Abaqus and probably (&hopefully) never will in my remaining lifetime,

Mario.

Offline

#9 2020-08-19 14:16:26

SamuelTwain
Member
Registered: 2020-08-14
Posts: 18

Re: Result Discrepancy between Abaqus and Code_Aster

Hi Mario,
   Yeah, 2nd order is definitely more accurate and suitable for my case. And we have succeeded in validating the result smile .
   But the discrepancy between element type sparks my curiosity to find out whether CA and Abaqus can reach a same/close result under identical setups. So I want to change my element type in CA. Maybe I should refer to the documentations to look for the appropriate elements.
   All your replies are very helpful. Sincerely thanks for your effort. Hope you can keep eye on this thread. If I have further findings from documentations, I will share here.
Best regards,
Samuel

Offline

#10 2020-08-19 16:03:01

mf
Member
Registered: 2019-06-18
Posts: 118

Re: Result Discrepancy between Abaqus and Code_Aster

Hi,

you're welcome. I suppose that a (bi)linear element with hourglassing control in Abaqus gives better results than without HG-control (that was the reason for creating it in the first place), similar to 2nd order (but with reduced calculation time).

I also suppose that a (bi)linear element WITHOUT HG-control will give similar results to CA with linear elements. There should not be much difference with matching meshes.

Mario.

Offline

#11 2020-08-20 10:26:35

SamuelTwain
Member
Registered: 2020-08-14
Posts: 18

Re: Result Discrepancy between Abaqus and Code_Aster

mf wrote:

I also suppose that a (bi)linear element WITHOUT HG-control will give similar results to CA with linear elements. There should not be much difference with matching meshes.

Hi Mario and every CAers:
    I hold the same viewpoint with Mario. Finite element theory is very ripe. As CA and Abaqus both adopt finite element method, they should reach a close result under analogous setups. smile
   But I haven't carried comparisons between CA and Abaqus. Conversely, I compared some CA cases adopting different setups and obtained some interesting ( and maybe helpful ) conclusions. The setups are different primarily in solving method and are listed as following:
   Case 1: ElASTIC matrice without RECH LINEAR
   Case 2: ELASTC matrice with CORDE method
   Case 3: tangent matrice without RECH LINEAR
   Case 4: tangent matrice with CORDE method
   All the above cases adopted 2nd order mesh benefiting from its accuracy. And the type of element is D_PLAN (plane strain element). The material is elastic perfectly-plastic. Other setups are the same with each other, although not mentioned here.
   It's notable that I didn't choose reduced intergration and hourglass control for element type. The main reason is 2nd order mesh can potently get over shear lock and is precise enough. Another reason is reduced intergrated element is not allowed for ELAS_VIMS_LINE behavior (I don't know the reason).
   Unfortunately, Case 3 has trouble in convergence. Possible reason might result from material plasticity which exacerbates the nonlinear behavior.
   Case 1, 2 and 3 get the same results. All three cases depict that the total reaction force is ~1.35e6 N which is very close to  1.31e6 N  and 1.45e6 N from Abaqus and analytical solution respectively. However, above three cases differ in convergence speed.
   Total CPU times of Case 1 is ~226s. By augmented with CORDE method, this time reduces to ~203s for Case 2. As we can see, elastic matrice have a good performance in convergence considering that tangent matrice diverges. And with the help of CORDE method, simulation time decreases by ~10%. It's hopeful that, faced by  larger model and more difficult nonliear behavior, elastic matrice + RECH LINEAR can show good performance in terms of calculation and convergence speed.
   Case 4 is of surprise to me. Although solely adopting tangent matrice fails to converge, tangent matrice with CORDE method  reach the result quickly! The total CPU time of Case 4 is merely 17s, almost as fast as that of Abaqus. Notably, Abaqus only adopts bilinear element, namely 4 nodes for a element. In contrast, CA adpots 2nd elment to which 8 nodes belong. Thus, CA has nearly the same convergence speed as Abaqus with about twice larger calculation data.
   In conclusion, CA performs a satisfactory calculation ability in terms of accuracy and speed if configurations are set up appropriately.

Hope this rash post can be helpful

Best regards,
Samuel

Last edited by SamuelTwain (2020-08-20 10:40:08)

Offline

#12 2020-08-21 08:19:27

Voulet2
Member
Registered: 2019-06-06
Posts: 27

Re: Result Discrepancy between Abaqus and Code_Aster

The reduced integration for QUAD4 elements is activated with 'C_PLAN_SI' or 'D_PLAN_SI' modelisation according to R3.06.10. It would be interresing to check the result with this kind of modelisation. Maybe this "feature" is activated by default with Abaqus ?

Offline

#13 2020-08-21 16:37:58

SamuelTwain
Member
Registered: 2020-08-14
Posts: 18

Re: Result Discrepancy between Abaqus and Code_Aster

Voulet2 wrote:

The reduced integration for QUAD4 elements is activated with 'C_PLAN_SI' or 'D_PLAN_SI' modelisation according to R3.06.10.

Hi Voulet2,
    I have used D_PLAN_SI. The problem is, for this type of element, ELAS_VIMS_LINE comportemente is not allowed. However, my material is elastc perfectly-plastic. So it's a little bit embarrasing that I don't know how to let my material behavior compatible with D_PLAN_SI.
Could you please give me some suggestions?
Samuel

Last edited by SamuelTwain (2020-08-21 16:39:05)

Offline

#14 2020-08-24 09:25:51

Voulet2
Member
Registered: 2019-06-06
Posts: 27

Re: Result Discrepancy between Abaqus and Code_Aster

I didn't see that you were already using D_PLAN_SI. All kind of MODELISATION are not available with all kind of COMPORTEMENT in code_aster. If ELAS_VIMS_LINE is not available (yet) with D_PLAN_SI, there is no magic solution and you should then use second order elements as you did to get correct result (or use a thiner mesh).

Offline