I tried to analyse a shell model with two load cases in a single analysis ie, by creating two “steps”.
But when I analysed the two load cases as two different analysis the results were different from the previous one.
Is creating different load cases possible?
Yes, It was disabled
What about other forms of nonlinearity - was plasticity or contact included in the model ?
Nothing like that was included
Make sure that loads are deactivated in steps in which they shouldn’t act. Maybe some are propagated to subsequent steps and hence the difference in results.
so its not possible to get results of all load cases in a single analysis…
Can you share the file with that multistep analysis ? It should work when there are no nonlinearities and loads/BCs are properly managed in each step. Here’s an example of such multistep load case analysis:
Analysis.pmx (373.7 KB)
I have attached the analysis file.
I’ve found the source of the problem. PrePoMax by default sets op=new for loads and BCs in each step. This limitation was discussed here: BCs and Load Op=New vs continuation
Your analysis will work correctly if you export the input file and change this line within the second step:
*Boundary, op=New
to this:
*Boundary, op=Mod
@Matej For now (until the BC/Load Manager will possibly be added in the future), may I suggest the implementation of an option to use op=mod instead of op=new ? Maybe somewhere in the model settings, with a warning for users. In this case, it seems that there’s no way to solve this multistep analysis correctly without the need to manually edit the input file. But maybe you know some other workarounds for that ?
I checked the model, and that is not supposed to happen. I deleted your 2nd step and duplicated Step-1, creating a simulation with 2 identical steps. And the results for steps 1 and 2 are different.
According to the documentation, using op=New should remove all previous definitions. So using 2 identical steps should give 2 identical results.
I tried this using a solid mesh, and 2 identical steps result in 2 identical results. So it works for solid meshes.
Based on that, I do not think this is a PrePoMax bug but a CalculiX bug. If you think the same we could report this on the CalculiX discourse group. Or am I wrong?
Still, having an option to select MOD or NEW would not hurt.
You are right, I also tried the same analysis with a solid model and got the right results.
If I understand it correctly, op=new has a side effect (but not a bug) - zero-valued BCs redefined in the second step may return the nodes to their original positions instead of keeping them fixed. Here’s a quote from Abaqus documentation (the CalculiX’s one doesn’t mention this but it works in the same manner) where they explain this using a particular example:
Specifying a prescribed displacement magnitude of 0 (or omitting the magnitude) in degree of freedom 1 in the next step would return the nodes in node set EDGE to their original locations.
Using *Boundary, fixed could be a workaround but it works only for translational DOFs and shells use rotational ones as well (maybe that’s what causes the difference in your tests).
Because of that, op=mod can be crucial in some cases.
The way I understand the following quote:
If a new boundary condition is prescribed with a value of 0 or without the value, it acts as a new boundary condition defined in the step. It sets the displacements of the node to 0 in regard to the initial node position. This is as expected. This is why the parameter FIXED was introduced and is also implemented in PrePoMax. I could not find the limitation of the FIXED parameter for the translational DOFs only. So I do not think this is the reason for the strange behaviour in the shell case.
There is definitely a problem with shells and rotational DOFs, but in other ways. I think it could be a bug. Could someone run such a simulation in Abaqus?
Right, I created a similar model in Abaqus (rectangular shell subjected to bending but due to gravity to avoid issues with differences in surface/load definitions in Abaqus and CalculiX). I defined two identical steps with op=new (Abaqus uses op=mod by default) and the results were the same for both steps. Then I solved the same input file with CalculiX and there was a difference in results, similar to what we saw here.
I can report this problem on the CalculiX forum.
I get this error when Fixed is defined for rotations:
*ERROR in bounadd: parameter FIXED cannot
be used for rotations
Hello FEAnalyst,
I’m new to the forum, so hello everyone!
Do you know if there has been a solution for this bug yet?
I’m using Calculix 2.20 but I still seem to have some weird issues that I dont really understand.
I have created a shell model of a simple beam with end plates. Within the model ther are four steps, where step 2 is a duplicate of step 1 and step 4 is a duplicate of step 3. All steps have the same load on the top surface of the bearm
Therefore, step 1&2 and step 2&3 should give the same results.
The difference between step 1&2 and step 2&3 is the boundary conditions. In step 1&2 I have fixed the surface of the end plates. In step 3&4 I have fixed the circumference of the the end plates.
When I run the analysis, the results are as expected. Step 1&2 are equal and step 3&4 are equal.
DISP, ALL
step 1: 0,02066
step 2: 0,02066
step 3: 0,03461
step 4: 0,03461
When I now deactiveate step 1&2 and only run the analysis for step 3&4, the result of step 3&4 is not equal any more. And the result is different to the first simulation run where I solved all three steps.
DISP, ALL
Step 3: 0,03321
Step 4: 0,03486
As I am a new user of the forum, I cannot upload a model.
So i hope my explanations are ok…
Any idea, why this happens? There does not even seem to be consistency in this bug or at least I cant see it…
p.s.: Thank you very much for all the helpful content you provide!
You can use some hosting website like Google Drive, Dropbox or WeTransfer and share the link here. It will be easier to help if you share the model.
Good Idea, here you go:
https://www.dropbox.com/s/po65wtcu5gb9wez/Shell_Multistep.pmx?dl=0
I hope that works
Thank you!