*ERROR in u_calloc: error allocating memory variable=sideload

1

Hello,

I am running into issues with memory allocations for the sideload array in ccx_2.1x.c. I have a thermal model with a mesh that contains about 160k elements with lots of surfaces for consideration of radiation and convection. Due to the high number of surfaces and subsequent uses of *FILM and *RADIATE, the _nload variable increases considerably so that the allocation NNEW macro (line 290 in ccx_2.1x.c) passes a number (variable num) to u_calloc that can not be represented via the default size_t data declaration. (num comes in as a negative integer and raises the memory allocation error.)

I was wondering if anyone has an idea of how to fix this? Is there any way to define elemental surfaces more efficiently so that the _nload stays low, or re-write some code in the memory allocation functions to allow passing larger integer numbers?

I am using:

  • ccx_2.16
  • compiled via msys64 (Windows64)

Any help is appreciated!

  • Christian
2

If you want to send me your deck I can try running it through the GNU debugger…

3

Hi there,

Yes please, your help would be apprechiated. I have attached the example model; even though the model uses the dflux subroutine, you should be able to recreate the error anyhow since it occurs during allocation.

Up until now, I thought the OP=NEW parameter deletes pre-existing definitions for *DFLUX, *FILM etc. which I thought was somewhat reflected in the source code as well. However, looking at allocation.f I can see that calculix increasingly allocates memory independent of what the OP parameter is. This makes my example of course not the most efficient one.

Here is the link to the model:
https://drive.google.com/drive/folders/1wN0ltO02v0EtYpojYGo49LNkaA9bvt5U?usp=sharing

Please let me know your thoughts.

  • Christian
4

I think the memory allocation is hitting some 32-bit integer size limit. The largest size sideload can be is 2,147,483,647 bytes. But the value your model wants to allocate for sideload is 20 * 167444624 or 3,348,892,480 bytes.

In the debugger below it prints out some ridiculous number for “num” since the limit has been exceeded I think…

We’ll need to research more to see if this is indeed the issue or something else…

Breakpoint 2, u_calloc (num=167444624, size=size@entry=4, file=file@entry=0x93a425 "ccx_2.18.c", line=line@entry=294,
    ptr_name=ptr_name@entry=0x93a54c "idefload") at u_calloc.c:36
36        if(num==0){
(gdb) cont
Continuing.
ALLOCATION of variable idefload, file ccx_2.18.c, line=294, num=167444624, size=4, address= 23452792877072

Breakpoint 2, u_calloc (num=18446744072763476800, size=size@entry=1, file=file@entry=0x93a425 "ccx_2.18.c", line=line@entry=295,
    ptr_name=ptr_name@entry=0x93a555 "sideload") at u_calloc.c:36
36        if(num==0){
(gdb) n
41        a=calloc(num,size);
(gdb) p num
$3 = 18446744072763476800
(gdb) p size
$4 = 1
(gdb) n
42        if(a==NULL){
(gdb) p a
$5 = (void *) 0x0
(gdb) n
43          printf("*ERROR in u_calloc: error allocating memory\n");
(gdb) n
*ERROR in u_calloc: error allocating memory
44          printf("variable=%s, file=%s, line=%d, num=%ld, size=%ld\n",ptr_name,file,line,num,size);
(gdb) p num
$6 = 18446744072763476800
(gdb) n
variable=sideload, file=ccx_2.18.c, line=295, num=-946074816, size=1
48          exit(16);
(gdb)
5

I can add that for the i8 2.16 (PARDISO) version, the above-mentioned error does not occur:

hcpy_1
hcpy_1995Ă—700 12.8 KB

6

Indeed,
I get the exact same numbers, and I can confirm that num is out of what can be interpreted with the default size_t data type and causes the error. I am just not sure how to get around this. It seems like Rafal (post below) could confirm that this problem does not occur with the i8 version of calculix. But I am wondering if there is a way to define facial loads more efficiently since the operator OP=NEW keeps on increasing nload. Or, if changes can be applied to allocate.f to make sure nload is not increasing this much.

Again, any ideas are welcome.

Thanks for your help!

7

I also can confirm the model runs fine with pardiso on linux. I think simplest solution is to upgrade your installation to 2.18 .

My understanding is the software reads the entire input deck once and stores all the facial loads into that sideload variable. Even though you have OP=NEW, the software treats each step as different loads. So not sure, there is any workaround… Anyways the model only used a few GB of memory, so not something I would worry about :slight_smile:

1 Like
8

Hi, I’m trying to use Calculix version 2.20 for an Heat Transfer Analysis. I have a model with around 716’000 elements corresponding to an inp file of 180Mb. In submitting the analysis I obtained this error that seems similar of that one described above:

*ERROR in u_calloc: error allocating memory
variable=emeini, file=nonlingeo.c, line=841, num=518045496, size=8

Correct if I’m wrong, as described in the chat above this error seems related to the Code and not to the Hardware right? Was there found a solution for this issues that seems again present withe the version 2.20?
Thanks & Regards

9

Can you try running this in older versions of CalculiX and using different solvers (Spooles, PaStiX, Pardiso) ? Also try reducing the mesh density and removing some advanced features to see if they can be the cause.

10

Thanks for the answer, really appreciated.
Sorry, this is my firts run with Calculix so I’m not expert. Is it possible to set a different solver with this actual version 2.20 or I have to install the previous one (i.e. 2.18) ?
Furthermore how is possible set the solver inside Prepomax?
I would avoid to change the mesh density because we have standard mesh specification to follow and my scope is check the differences in terms of results.

11

You can change the solver using the SOLVER parameter associated with the keyword defining the type of the step. For example:

*STATIC, SOLVER=PARDISO

This parameter can also be changed in PrePoMax when defining a step. The default solver in 0.20 is PaStiX (fast but sometimes not working correctly), for most older releases it’s Spooles (the slowest one). I would especially try with Pardiso (fast and reliable) but you will have to download some additional libraries.

12

I tried with setting the Solver Pardiso but it seems the same. Any other suggestion?

*ERROR in u_calloc: error allocating memory
variable=stiini, file=nonlingeo.c, line=840, num=518045496, size=8

13

You are trying to allocate about 4GB of RAM.
Please check whether you have enough RAM and try the calculation with a smaller model.

14

How can I delete elements from prepomax? In order to reduce te size of the model, how suggested, I would like to delete an half of the existing mesh. I’m not finding the way inside Prepomax for delete elements and furthermore it seems that the tab Mesh is disactivated, could be this the issue?

15

You can create an element set, convert it to part and then delete that part.

16

I have a similar situation, thermal case 160k elements. Memory allocation error in relatively small mesh with cavity radiation.

 *ERROR in u_realloc: error allocating memory
 variable=auview, file=radflowload.c, line=527,
 size(bytes)=-1132281728, oldaddress=-639647680

I am using:
CalculiX 2.22
local machine with 24 GB RAM
HPC node with 256 GB RAM

I tried using different solvers like spooles, pastix, pardiso, iterative cholesky
All failed with same error.

(Unfortunately I cannot share the model files. )
I understand that i8 verison of ccx can be the solution.
What is that and where can I download it?

Sorry for my (possibly) trivial questions. I would appreciate any help.

The complete relevant output is below:

  The numbers below are estimated upper bounds

  number of:

   nodes:        72729
   elements:       163779
   one-dimensional elements:            0
   two-dimensional elements:            0
   integration points per element:            1
   degrees of freedom per node:            3
   layers per element:            1

   distributed facial loads:        50327
   distributed volumetric loads:            0
   concentrated loads:            0
   single point constraints:         9649
   multiple point constraints:            1
   terms in all multiple point constraints:            1
   tie constraints:            0
   dependent nodes tied by cyclic constraints:            0
   dependent nodes in pre-tension constraints:            0

   sets:           31
   terms in all sets:       399852

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

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


 STEP            1

 Static analysis was selected

 Newton-Raphson iterative procedure is active

 Decascading the MPC's

 Determining the structure of the matrix:
 Using up to 8 cpu(s) for setting up the structure of the matrix.
 number of equations
 40294
 number of nonzero lower triangular matrix elements
 206106

 number of radiation equations
 22786
 number of nonzero radiation matrix elements
 519201796
 
 increment 1 attempt 1 
 increment size= 2.000000e-01
 sum of previous increments=0.000000e+00
 actual step time=2.000000e-01
 actual total time=2.000000e-01

 iteration 1

 Calculating the viewfactors

 *ERROR in u_realloc: error allocating memory
variable=auview, file=radflowload.c, line=527, size(bytes)=-1132281728, oldaddress=-736972736

 Job failed - no results exist.

Process elapsed time:       37.188 s
17

@umut You don’t mention anything about if it should be a 64bit windows or linux version.

I have a ccx_2.22 windows version capable of running pardiso in 64bit mode but I need to admire that I haven’t tested it with that number og equations. It have not PaStix included.

You can get it here windows ccx_2.22_i8