Fot testing the time of the simulation I would use a larger model. But i know it takes time to prepare it. We should also not compare it to a normal boudary condition but to another compression only boundary condition like contact. I am also wondering if transversal displacement is possible.
I tried with a bigger model (cube consisting of 200 C3D8R elements) and the difference is much lower. On average, analysis with gap elements is just 1.04 times slower. In some runs it’s even a bit faster.
I plan to compare it with contact with a rigid surface as well but for the first tests I wanted to see how gap elements themselves increase the calculation time and thus how many times longer the analysis will take if a user replaces standard fixed support with compression-only support.
As a reference I have set up a model with contact + plasticity:
-Slave surface 140 nodes
-Master surface 187 nodes
Overall model :
nodes: 878
elements: 381
CalculiX Time: 4.81 sec
¿Is it possible to display the results in a different unit (MPa) than the one chosen at the beginning? Pa is not very friendly.
@Matej .The problem I see with the contact approach is that I’m not sure if you can automate this. You would need to generate a support surface against which to build the contact ¿isn’t it? . ¿Is that possible?.
I added contact with a rigid shell (1 or 4 S8 elements) to my cube model. I checked 2 different contact formulations (surface-to-surface with hard behavior and node-to-surface with linear behavior). On average, gap elements are 1.5 - 1.6 times faster than contact.
I was hoping the GAP elements would be faster. That is a good sign. Now I am only worried if they allow a transversal/slip movement which would be frictionless, I guess.
No, PrePoMax doesn’t convert the values in the .frd files. It assumes a selected unit system and adds appropriate unit abbreviations to the .frd values.
I would not want to go with this approach. It would be possible to create a shell model of the surfaces selected for the boundary condition, but too much can go wrong if contacts are used for an inexperienced user. I want to add a method which is robust enough that the user can set it up and not worry about it later. The contact approach can always be done manually.
You are right. Only compression is often tricky and hard to set up. Would be nice to have other option.
@FEAnalyst . Seems you are progressing in the right direction. I’m curious how this GAPUNI elements are set up.
They impose constraints only in one direction so the model is free to move tangentially with no stresses. I tested it as well.
It’s similar to spring elements:
*NODE
number, coordinate_1, coordinate_2, coordinate_3
*ELEMENT, TYPE=GAPUNI, ELSET=elset_name
number, node_1, node_2
*GAP, ELSET=elset_name
initial_clearance, gap_direction_1, gap_direction_2, gap_direction_3, , compression_stiffness, tensile_force
Initial clearance will typically be zero, gap direction is specified using 3 components and stiffnesses can be set to extreme values (very high for compression and very low for tension) to simulate compression-only support. Gap elements connect the nodes belonging to the model’s face being supported with additional “ground” nodes. The latter will typically have the same coordinates as the former.
It seems the code of GAP element has been changes from previous versions. More useful since the stiffness can be set from default 10^12 in compression and 10^-3/-infinite in tension
That is great. I read about it in the manual but was unsure how it works.
I assume this direction does not change during the analysis, so it is useful only for small displacements on arbitrary geometry or larger displacements on a plane.
Yes, the direction is fixed in space. Also in Abaqus.
Hi all,
I have read the above GAP Keyword function and understood most, but just have a couple queries on how to apply it practically:
-
Do we need use both the *NODE and the *GAP Keywords (see below)?
-
If so, could someone elaborate a little more on what the *NODE is for ? This part is a little confusing to me.
-
Then, if I have a common book shelf bracket that is bolted against wall, do I need to model the wall surface too OR is just the bracket back face (assigned in the ELSET) needed ?
Otherwise, if a simple example could be shared in a .pmx file, that would be very usefule.
Yes, *NODE is necessary because the GAP elements are defined just like other element types - based on nodes. The *NODE keyword is used to define the nodes that form the element. So *NODE defines nodes, *ELEMENT defines elements of a particular type with those nodes and *GAP serves as a property definition (like *SOLID SECTION for solid elements).
The purpose of this approach with GAP elements is to avoid having to include rigid walls in contact with the model. But you will need GAP elements for all nodes that would normally be in contact with the wall so it can be really tedious unless some automation is introduced.
Ahh, OK this helps. Thank you @FEAnalyst
In my example then it would be easier to model the wall as a very rigid component, perhaps one element thick, as proposed above by others.
Currently (until GAP elements are implemented in the future) yes. But you can model it as a shell and apply a rigid body constraint to it.
1 Like
I have added support for compression-only gap constraint in the new developer version of the PrePoMax: A developer/preview PrePoMax version v1.5.1 has been released
3 Likes
Wow ! This is wonderful. Thank you @Matej
Closing as completed.
1 Like