Steps fail for cantilever flat beam (shell)

Bug Reports
1

Hi, I’m quite new in the FEA in general and in use of this Prepomax in particular, so it must surely be just me, however:

I encountered an issue with a shell defined cantilever beam simulation, where I fix one end (edge) and apply a displacement to the other (edge). It went all fine until I wanted to check solutions for different displacements by duplicating the step and setting a different value (even without changing the value). Second step makes a mess with the nodes, looks to me like some nodes were pulled the right value and others were constraint to 0mm. If I deactive the first step, the solver get it perfectly right for the second (and only).

image
image1148×835 66.4 KB

2

Can you share the .pmx file ? It might be a known CalculiX bug such as this one: Wrong results in a multistep analysis with shells and *BOUNDARY, OP=NEW · Issue #13 · Dhondtguido/CalculiX · GitHub

3

I tried to attach it to this message but I get a “new user limitation”

4

Please try again now. Unless the file is too large - then maybe you could use some hosting website and share the link here.

5

TEST LAME_02.pmx (550.3 KB)

Great here is the file.

I tried also to perform the same analysis with a solid beam, two steps worked fine.

6

My file seams corrupted.. here i built it again

TEST LAME_03.pmx (528.0 KB)

7

For what I understand this is related with the use of shell model. This is just a part within a system, if I keep it as a shell will I get the same issue once I add the other parts? I can just activate the steps one by one but I understand it will be way more time consuming.

8

Yeah, apparently, it’s that issue I linked above. You can export the input file, remove the *BOUNDARY, OP=NEW entries in some text editor and submit outside of PrePoMax: Using standalone CalculiX

9

I have come to the same conclusion. And we are again at the point of how to solve the OP=New setting.

10

I thought about this, and maybe I can look at the OP parameter as a Step Control:

image
image445×523 7.7 KB

I can add new available controls for Boundary, Cload, … Then a user can change the OP parameter behaviour here. The default behaviour would stay the same.

I know it is not a general solution, but with a small amount of work, it will allow removing OP parameters from the UI and running analysis from PrePoMax. Any ideas?

11

I’m interested in a detailed procedure since I don’t understand these parameters. For the moment it is easier to me to just run the steps one by one.

12

Indeed, it sounds like a very good idea. The only disadvantage is that step controls (*CONTROLS in Abaqus and CalculiX) store different kinds of settings, but it’s still most likely the best location for OP parameter controls at the moment (since there’s no manager for step-dependent features yet). It is an advanced step-wise setting after all, even if not related to solver controls/incrementation settings.

The easiest way to run both steps at the moment is to:

  1. Use: File → Export → CalculiX *.inp
  2. Open the exported .inp file in any text editor (such as Windows Notepad or Notepad++)
  3. Search for *Boundary, op=New and delete both these entries.
  4. In the folder with that .inp file, open command line (type cmd and press Enter in the path field).
  5. Type for example:
    "D:\PrePoMax\PrePoMax v2.3.0\Solver\ccx_dynamic" TEST_LAME_03
    but replace the path with your path to the Solver folder under PrePoMax installation directory. And avoid spaces in the input file name (I added underscore there).
  6. When it’s done, use File → Open and select the .frd file to postprocess the results in PrePoMax.
2 Likes
13

It worked! But since the simulation uses only 1cpu it takes longer than having the steps resolved one by one directly from Prepomax.

14

To set the desired number of CPUs for such a standalone ccx run, just enter this in the command line before submitting the analysis:

setx OMP_NUM_THREADS "number_of_your_cpus"

1 Like
15

Don’t ask me why but this problem solves activating *Step,NLGEOM=ON in the second step.

EDITED: Sorry, Not right. It has not solved but start giving error messages that I think it helps to understand the reason.

BC on Rotational degrees of freedom can not be redefined or fixed. *ERROR in meanrotmpc: MPC has wrong number of terms. As NEW removes them they can’t be reinstated and the problem becomes unconstrained.

Yep. I don’t see other way to solve it.

16

At the end, it is not a PrePoMax bug but a CalculiX bug. But a feature is missing in PrePoMax to handle such problems.

1 Like
17

Indeed. Especially since Nlgeom is not always desired (one may just want to run an analysis with linear load cases) and may lead to convergence issues.

But it’s good to know there’s another workaround too.

1 Like