Impact Problem-Projectile penetrating plate

[jithus]

Hello all,
Before submission of my query, I would like to appreciate the forum members helping each other out through great suggestions. I seek a new one to solve my problem too.

Model: I'm simulating an Impact problem in Abaqus Explicit for a 3D composite plate made of 21 plies and meshed with linear brick elements. The impactor is modelled as a rigid body with Ref point and moving with initial velocity of 7.08m/s and mass of 260gms.
In my simulation I'm also using a VUMAT subroutine for the composite.

Problem: The simulation runs but in the results output I see that the impactor is penetrating into the composite. The property definitions are correct. Since this is a Low velocity impact, the impactor should only bend the plate but this is not happening.
I suspect problems with contact conditions but have tried almost all options. Presently it is a surface-surface contact with kinematic condition.
Attached is the description of the complete model I'm trying to simulate.

Has anybody come across a similar problem? Can you suggest areas to look into to correct the problem?

 

[rstupplebeen]

Posting your files would be helpful in diagnosing your problem. If this is proprietary just create a simplified model. Here are 3 ideas.

1. Try the defaults for general contact. Some times with tinkering with a bunch of properties a model can get far from nominal.
2. Check that in your deformation plot that the displacement is not being scaled.
3. Try running with the plate as a simple linear elastic material like aluminum.

I hope this helps.

Rob Stupplebeen

 

[jithus]

Thank you for the reply Rob.

In the past days I modified the properties of the target plate to represent an isotropic material and it appears that it runs fine. The projectile doesn't penetrate the plate but only bends as needed.
I then ran it with the same isotropic material with a damage model and involving element deletion in Abaqus. This also came out well with some elements that had failed at the bottom of the plate deleted and the projectile bending the plate.
These two cases give me confidence that probably my model definition is right. I probably can attribute the penetration to either my Vumat routine or simply due to the properties of the composite. In order to check that further, I'm in the process of formulating a simple isotropic damage Vumat routine and checking. Will update on that in next days.

Could you however clarify on the scaling of the displacement plot? I checked in options->common and the scale factor was 1. If you make it 0, ofc it appears that the projectile hasn't penetrated but it needs to be 1 right?

 

[rstupplebeen]

Scale factor of 1 is what you want. It was just a guess as a potential error.

Rob Stupplebeen

 

[gwolf2]

Jithus,

Good approach to the problem - break it down, simplify, get it working, then build the complexity back up to 'reality' noting the points at which problems occur. Text book approach, I'm sure you'll get to the bottom of it shortly.

I wish I could help more but I do not have the relevant experience.

gwolf.

 

[jithus]

Thank You gwolf2 for the encouraging comments and thank you Ron for clarifying the deformation scale factor.

As proposed before, I formulated a new Vumat to run with an isotropic material and single damage variable which either is 0 or 1. The damage variable becomes 1 when damage is detected (restricted to 0.9 to avoid division by zero) and suddenly reduces the corresponding stiffnesses to 10% of their original value. I got expected results from the simulation. Great!

Next, for my actual problem I devised another Vumat detecting damage in a progressive manner where the damage variable goes from 0 to 1 (0.9) in a progressive manner. Everything is fine for a while but I see that in between the simulation, the error "The executable C:\SIMULIA\Abaqus\6.8-1\exec\explicit.exe aborted with system error code 142" is cropping up. Normally this would mean some error in the code but I have checked through and through. Can't really figure out why this is happening.
Care has been taken to avoid division by zero. Memory is also not a reason.

Can you guys suggest what else needs to be checked? Any ideas?

 

[gwolf2]

I tried googling ABAQUS error code 142 and quite a bit came up on independent forums, some relating to UMAT, I'd take a look there for tips.

 

[jithus]

Well..actually that had been done already. I have read through most of the posts regarding this error in the past. I have ensured that my scratch directory also has enough space.
One of the things which now I can say with some confidence is that unless there is some genuine memory problems in the disk, this error with a user routine almost always points to something within the routine. It could be some error or some criteria within the routine which fails after the simulation runs for a while. I have done all combinations and though my formulation looks good in theory and in coding, while the numbers are churned out something is going wrong. It is really hard to figure that out unfortunately.

 

[gwolf2]

Just in case you didn't know - if in the UMAT you use

WRITE(*,*) Variable1, "comment etc"

You can write your own counters and debug comments to the default FORTRAN output channel. This will appear in one of the common text files like .msg, .dat or .pre. I think there is a list of channel number assignments somewhere in the advanced documentation guide.

 

[MechIrl]

A print statement will send it to the log file, saves messing with unit numbers.
PRINT *,'whatever'
I often get this error when an illegal operation is performed in the UMAT. Check divide by zeros, integer rounding, undeclared variables etc.

 

[jithus]

Thank you guys..I did try dat but found nothing of the sort of a clue to the problem.
It appears that may be it is something to do with the formulation itself. So I'm working on it now. Lets c wer dat takes me.
I have to start another post for a related but different query. Will visit here in a while.

 

[jithus]

Hello all,
I just noticed that the title problem of this post had been solved and I have moved into new areas. Hence, it is appropriate to close this post.
I see that adding certain additional stiffness by means of hourglassing control to my model has prevented the projectile penetrating into the plate.