*ERROR in u_calloc: error allocating memory

1

When I use calculix to deal with fluid-structure coupling problems, I need to use calculix often. I use *restart, read to ensure that calculix inherits the previous calculation results. However, after running for a while, calculix failed to generate.frd file: : *ERROR in u_calloc: error allocating memory

I am using the ccx_2.20 version, can anyone see the reason for my error message? How should it be corrected?

The following error message is reported:

CalculiX Version 2.20, Copyright(C) 1998-2022 Guido Dhondt
CalculiX comes with ABSOLUTELY NO WARRANTY. This is free
software, and you are welcome to redistribute it under
certain conditions, see gpl.htm

You are using an executable made on Tue Jul 4 16:39:43 CST 2023

*INFO: restart file yezizz.rin
has been opened for reading.
it was created with CalculiX Version 2.20

The numbers below are estimated upper bounds

number of:

nodes: 365457
elements: 5528
one-dimensional elements: 0
two-dimensional elements: 5528
integration points per element: 9
degrees of freedom per node: 3
layers per element: 1

distributed facial loads: 0
distributed volumetric loads: 0
concentrated loads: 68760
single point constraints: 401952
multiple point constraints: 672202
terms in all multiple point constraints: 717490345
tie constraints: 0
dependent nodes tied by cyclic constraints: 0
dependent nodes in pre-tension constraints: 0

sets: 4
terms in all sets: 33452

materials: 1
constants per material and temperature: 2
temperature points per material: 1
plastic data points per material: 0

orientations: 5528
amplitudes: 2
data points in all amplitudes: 2
print requests: 0
transformations: 0
property cards: 0

*ERROR in u_calloc: error allocating memory
variable=nodempc, file=ccx_2.20.c, line=272, num=-2142496261, size=4

2

In the error message, it says we need to look at line 272 of file ccx_2.20.c.
This reads:

NNEW(nodempc,ITG,3*memmpc_);

This wants to allocate a block of memory of type ITG, which is long long. On 64-bit platforms this will be a 64-bit integer, so 8 bytes.
It wants to allocate 3*memmpc_ of those.

If you search the source code for the string “terms in all multiple point constraints”, you will find that memmpc_ equals 717490345.

This means that the system wants to allocate 37174903458 bytes, or 17.2 GB (16.03 GiB)!
Apparently, you have more terms in your multiple point constraints than you have available memory.

For each multiple point constraint you have on average over a thousand terms. So I guess you have too many *EQUATIONs.

1 Like
3

So do you know how to solve this problem?

4

So do you know how to solve this problem? @rsmith

5

Reduce the number of MPC’s.

6

@rsmith
what‘s meaning of MPC? And how to reduce the number of MPC’s?
this result was executed by using the *restart,read.inp file many times (180+ times).So I don’t know how to modify it to reduce the number of mpc’s.

7

Multiple Point Constraint.

Hard to say without seeing the input.

8

@rsmith

@rsmith
the first inp:
*INCLUDE, INPUT=Node.msh
*INCLUDE, INPUT=Element.nam
*INCLUDE, INPUT=Elset.nam
*INCLUDE, INPUT=fixed1.nam
*Material, Name=Material
*Elastic
46500000, 0.35
*Density
700
*Shell section, Elset=Elall, Material=Material, Offset=0
0.001
*Restart, Write
*Step, Nlgeom, Inc=1000
*DYNAMIC
0.001,0.005
*Boundary
fixed1,1,6,0
*Cload
Nall,1,0.0
Nall,2,0.0
Nall,3,0.0
*Node file
U
*End step

the second inp:
*Restart, Read
*Step, Nlgeom, Inc=1000
*DYNAMIC
0.001,0.005
*Boundary
fixed1,1,6,0
*Cload
*INCLUDE, INPUT=force.txt
*Node file
U
*End step

The second inp file is repeated many times (about 180 crashes).
Do you need file information such as node and element? Since the number of nodes is 2800+, and I don’t know how to upload files, could you please give me your email address if necessary?

9

There is no load on your structure because your *CLOAD is 0 in all directions. So basically nothing happens.

10

Sure, but that should not be the source of the memory allocation problem. @Phonix, I believe it is best to find a way to share all the files you are using for this simulation and share a link so that someone in the community can look into it. I agree with @rsmith that the problem seems related to the number of MPCs in the model, so we would need to look at that. It seems odd to have 365,457 nodes and only 5528 elements → 365,457 nodes / 5528 elements ~ 66.1 nodes per element? Seems odd.

1 Like
11

Yeah, that caught my eye as well. I just didn’t know what to think of it. :face_with_raised_eyebrow: Especially since it’s a shell model.

But it might be as simple as gaps in the node numbering. If that is the case, fixing that would help reduce memory requirements.

Maybe @Phonix can also show a picture of the mesh?

1 Like
12

@rsmith
*Cload=0 is just the first.inp file, which only produces the initialized.frd file, the second inp file is useful (because I used *restart,read), whose *cload changes every time, forces.txt is generated by other software.

13

@jbr
So how do I share files? Could you please give me a contact information such as your email address, and then I will send the relevant documents to you?

14

@rsmith

1693788502526
16937885025261564×1372 44.4 KB

  • This is a grid photo with 2866 nodes and 5528 elements.
15

The output of the failed restarted run said “nodes: 365457”. So there is something not right.

Are the nodes numbered consecutively, like 1,2,3,4…,2863,2864,2865?
If not, remake the mesh so that they are. It will save you a lot of memory.

Question; why are you using triangle elements for such a simple geometry?
Generating this geometry with S8 (“qu8”) element in CalculiX Graphics would be relatively simple and would yield better results with much less elements.

1 Like
16

@rsmith
The node numbers are consecutive. As for the reason why I used S3, I used calculix to deal with fluid-structure coupling problems, and the flow field solver can only import stl files. I extracted the information in its stl file as node.msh and element.nam of calculix

17

Ok. But why then does the solver run report “nodes: 365457”?

1 Like
18

@rsmith
I wonder if this is the result of using *restart,read multiple times?

Since I am using calculix *restart, the specific operation of read is: Run the.inp file (using *restart,read requires a.rin file, and running the inp file will generate an rout file), delete the.rin file, change the resulting.rout file to a.rin file as the start file for the next.inp, and run the.inp file again.

The above is the specific process that I use calculix. Is it because of this process that nodes: 365457 is caused?

19

Nodes and elements are generally created by the preprocessor, not the solver. (*REFINE MESH being the exception that I know of.)

20

Doubt it. In general, your node count remains the same with restarts, and there might even be a restriction about adding more nodes/elements for restarts…