Diference between variable Displacements and Disp&Def for postprocessing deformed results?

I have re run with Contact Output and friction of 0.5, this is the COPEN results at the first bar (all are the same), so from what I understand there is no separation or penetration, I don´t understand why the deformated representation show such a big gap in the first and second bars, and in the third in the right side is against the frame but in the left is separated as well (the pretension and contact definition is the same for all allen bolts)

This is the CPRESS field… cero in the faces that are separating, but I see a litlle of pressure in the non separated bar (?)

This is the summatory of the forces at the selected face, I have applied a pre tension force of 165kN

And this is measured at the lower face of the head bolt. The curve looks better, but I don´t understand why I don´t see something like the 165kN applied

This is the third bar, the one that don´t separate:

Great, thanks. I’ll give it a go in Abaqus and PrePoMax.

CalculiX stores only negative values of COPEN (penetrations) and sets positive values (clearance) to zero. Unlike Abaqus, it doesn’t limit COPEN output to contact regions. Might be good to cut the legend around 0 and show it in gray for clarity.

Keep in mind it’s only shown on the slave side. But indeed, even without hiding one part and looking inside the connection, it seems to be zero there. Did you try pulling the bolt in the direction perpendicular to it in the second step ? Do you have adjustment enabled ?

I would try *SECTION PRINT for the bolts. It’s implemented in the dev version of PrePoMax. The FORC field and RF outputs can be confusing.

Hi @SergioP1975,

I’m not sure I understand your machine.

It looks like you have a set of spacer bars (in green) with a threaded hole drilled on each extreme. On each side an Allen bolt is threaded from the outside of each plate. The initial preload If I understand correctly should hold the spacers in place and avoid the slipagge when pulling them . Is that correct?

It seems your preload isn’t tightening the Allen bolt?.Is that possible? It seems to be pointing in the opposite direction. Shouldn’t the two arrows be pointing one to each other?. Maybe it’s a different Prepomax convention? Preload should close the space in between the contact surfaces and put the contacts in pressure. Similar to when you tight the nuts. I would try to set them in manual and not autocompute.

This is a simplified version of how I understand your model. The plate is inbetween the nuts. The pretension is limited to the space inbetween the nuts. Outside that space there shouldn’t be almost load.

I’ve increased the frame stiffness (Almost Rigid) because the frame base also acts as another spacer and it’s puzzling me.

My model is constrained in the frame with a 3, 2, 1 setup and reaction forces on those nodes are marginal. Bolts don’t have any external BC. All loads are developed internally. There is no external load on the machine yet. Just preload.

The load distribution “seems right” without separation. The center bar load is very small compared to the connection area.

When I measure the preload value through the CPRESS Integral , the result isn’t the preload applied (60KN) but a much larger value (606KN).(Suspiciously like 60KNx10) . I’m still trying to figure out what’s going on or if I have set up something wrong. In your case, I would suggest to simplifying the setup as much as possible to understand what’s happening first.

Regards

PrePoMax always displays them this way, even if you enter a negative value of the bolt load:

In Abaqus, entering a negative value inverts the arrows:

2 Likes

Thanks @ANYS for taking the time to recreate the model, saddly this is a comercial work and cannot make it public. I was looking for the same deformed/stressed shape as in your results, tomorrow will recreate the bc in Mecway and re run again.

@FEAnalyst Could it be defined a pre tension load that separate the bolts? I have defined all as positive loads, but have sense to have a negative pretension feature in the program/solver?

Sure, you just have to enter the value with minus. The symbols won’t change, but the load will act in the opposite direction, as can be seen on my third screenshot.

Maybe autocompute has fail to compute the right pretension direction. ?¿?

It should just make CalculiX use element normals instead of manual specification:

The force and the displacements are applied in the direction of a vector, which is the normal to the surface (…) If the vector is specified away from the elements whose faces belong to the surface (…), a positive force or positive displacements correspond to tension in the underlying structure. If no such vector is defined by the user, it is calculated automatically as the mean of the normals away from the elements whose faces belong to the surface (…)

Even when the direction is specified manually, the arrows don’t change with a change in the preload sign. It might be good to check a single bolt separately if there’s a doubt regarding the correctness of its preload definition, but it’s likely correct.

Illustration from Abaqus documentation:

1 Like

I see this could be a problem. I need to see the code, and I will fix the arrow directions accordingly.

1 Like

In PrePoMax +100 N pretension force is converted to CacluliX *Cload of 100 N and results in positive stress = tension. That is why I am thinking of showing
image
for positive force and
image
for a negative force.

I would not like to change the sign of force from PrePoMax to Calculix input.

Does this make sense? This would be a little different from Abaqus.

1 Like

It makes sense for me.

1 Like

Definitely makes sense and is even better than in Abaqus. We’ve always found it confusing how the arrows are pointed in Abaqus.

2 Likes

So I think I have now covered all possible variations:

Tension force/displacement

Compression force/displacement

Zero or fixed displacement

3 Likes

Great, Abaqus doesn’t have a separate symbol for that:

2 Likes

That way of checking the preload is very innacurate. The right procedure is to request :

*SECTION PRINT,SURFACE=PRETENSIONSECTION,NAME=Preload_forces
SOF,SOM

Sergio used the FORC field which can be really confusing. Unfortunately, reading RF from pretension section node doesn’t seem to work correctly in CalculiX for some reason, even though it’s the standard approach in Abaqus. So indeed, section print is the best way for solid bolt models and I always use it in such cases.

1 Like

The direction of the arrows is always controversial. It’s great that there’s a distinction. It’s easy to get used to and makes sense :grinning_face: