-
-
May 3, 2019 at 2:33 pm
abcdandy
SubscriberHelloÂ
I have been having issues with the memory for quite some time due to my comprehensive model. It has quite large at 2.5 million nodes, but the details and contact pairs necessitates a fine mesh.
To mitigate the issue, I have already tried the following
- running iterative solver
- running out of core
- increasing virtual memory
- using msave
however, even after all this I still get the error message:Â
"There is not enough memory for the Sparse Matrix Solver used by the PCGÂ
 solver to proceed using the out-of-core memory mode. The total memory Â
 required by all processes = 186543 MB. The total physical memory that Â
 is available on the system = 115895 MB. Please decrease the model   Â
 size, or run this model on another system with more physical memory."
Â
Currently, I have 125GB physical memory and just added 80GB swap memory. However, the error message only reflects the physical memory while I have ample hardware to meet the requirement of 186543MB.Â
I already allocated all the RAM in 'solve process settings' yet this issue is still persisting.
Please help and thank you,
Â
Andy
Â
Â
-
May 3, 2019 at 3:16 pm
peteroznewman
SubscriberWhat do you mean by this?
I already allocated all the RAM in 'solve process settings' yet this issue is still persisting.
You may be causing your own problem. Please show the solve process settings you have been using.
-
May 3, 2019 at 5:10 pm
-
May 3, 2019 at 7:21 pm
peteroznewman
SubscriberYou are causing your own problems. You have 125 GB of RAM and you allocated 200 GB of RAM for Workspace and 200 GB of RAM for Database. Don't do that, it is the cause of the error. If you are interested, read ANSYS Help on Memory Management. Here is a useful paragraph:
Mechanical APDL memory is divided into two blocks: the database space that holds the current model data and the scratch space that is used for temporary calculation space (used, for example, for forming graphics images and by the solvers). The database space is specified by the -db command line option. The initial allocation of total workspace is specified by the -m command line option. The scratch space is the total workspace minus the database space.
In general, specifying a total workspace (-m) or database memory (-db) setting at startup is no longer necessary. Both the scratch space and database space (64-bit systems only) grow dynamically, provided the memory is available when the memory manager tries to allocate additional memory from the operating system. If the database space is unavailable (or forced not to grow dynamically via a negative -db value), the program automatically uses a disk file (.PAGE) to spill the database to disk.     Â
I have never had to Manually specify Mechanical APDL solver memory settings on a well equipped computer. The only time I did was to help a student on an old computer with only 2 GB of RAM, while ANSYS specifies the minimum RAM is 4 GB. The default setting for Database is 2 GB of RAM which caused the same error you saw on a computer that only has 2 GB of RAM. To help that student, I recommended 1 GB of memory for the Database and that allowed that small model to solve.
What is the error you get when you uncheck Manually specify Mechanical APDL solver memory settings?
Â
-
May 4, 2019 at 7:50 pm
-
May 4, 2019 at 8:32 pm
peteroznewman
SubscriberI don't know what will fix that. Someone like tsiriaks from ANSYS will have better advice.
Does this happen even after a fresh restart of the computer?
What OS are you running this on?
I can try to run it on my large memory computer if you want to upload an archive.
-
May 4, 2019 at 8:47 pm
abcdandy
SubscriberHi Peter
I am running on a virtual machine CentOS Linux 7 through VMware and yes, even after a reboot.
That would be appreciated. How would I proceed to do that?
-
May 4, 2019 at 9:12 pm
peteroznewman
SubscriberRMB on Model and Clear Generated Data to delete the mesh.
File > Save.
File > Archive.
That will generate a .wbpz file.
Post a reply and say which version of ANSYS you are on, 19.2 or 2019R1 etc.
After you post a reply, the Attach button will show up on the right. Click that, browse to the file and click Upload.
The .wbpz file must be < 120 MB in size for the upload to succeed.
Â
-
May 4, 2019 at 9:36 pm
abcdandy
SubscriberHi Peter it is Ansys 18.2.
Thanks again.
-
May 4, 2019 at 9:40 pm
abcdandy
SubscriberThere seems to be an internal error and I cannot attach it. Is there another method by which I can send to you? The file is 4637 KB.Â
Regards
-
May 4, 2019 at 9:53 pm
peteroznewman
SubscriberIf you have Gmail, you have a Google drive for holding large attachments. Attach that file to an email to send to anyone. The Google drive link will be created in the body of the email instead of an attachment. Copy that link and paste it into your reply.
-
May 4, 2019 at 10:18 pm
peteroznewman
SubscriberIt's meshing...
-
May 5, 2019 at 11:46 am
peteroznewman
SubscriberI tried solving on 18.2 your model on a computer with 192 GB of RAM, requested 15 cores. The only changes I made to your model is I set the Solver type to Iterative (PCG) instead of Direct (Sparse) and I removed the Command Object named shared out of core. I let it run for 6 hours.
It has used 148 GB or 77% of the RAM and doesn't seem to be solving anymore.
The files on disk are < 9 GB.
The last few lines of solve.out are shown below:
ELEMENT TYPE 323 IS SHELL281. IT IS ASSOCIATED WITH ELASTOPLASTIC
MATERIALS ONLY. KEYOPT(=2 IS SUGGESTED AND HAS BEEN RESET.
KEYOPT(1-12)= 0 0 0 0 0 0 0 2 0 0 0 0
ELEMENT TYPE 324 IS SHELL281. IT IS ASSOCIATED WITH ELASTOPLASTIC
MATERIALS ONLY. KEYOPT(=2 IS SUGGESTED AND HAS BEEN RESET.
KEYOPT(1-12)= 0 0 0 0 0 0 0 2 0 0 0 0
*** NOTE *** CP = 4610.360 TIME= 00:489
This nonlinear analysis defaults to using the full Newton-Raphson
solution procedure. This can be modified using the NROPT command.
SOLUTION MONITORING INFO IS WRITTEN TO FILE= file.mntr
*** WARNING *** CP = 6576.456 TIME= 01:17:25
Material property EX of material 155 of element 259042 is evaluated at
a temperature of 22, which is below the supplied temperature range.
Temperature range checking terminates.
*WARNING*: Some MPC/Lagrange based elements (e.g.73784041) in real
constant set 726 overlap with other MPC/Lagrange based elements
(e.g.73786553) in real constant set 728 which can cause
overconstraint.
I think the solver is still running. It doesn't look like it, but it didn't run out of RAM or disk space.
When I issued the Stop command on the Solution control dialog, it stopped gracefully.
-
May 5, 2019 at 6:19 pm
abcdandy
SubscriberInteresting. My first post had the screenshot that said the total memory required by all processes = 186543 MB so it should've been able to run on your computer. What would you recommend as the next step?
-
May 5, 2019 at 9:08 pm
peteroznewman
SubscriberI tried suppressing most of the internal bodies to make sure that the solver would eventually start. Keeping just the 4 cylinders at the bottom, I started that on ANSYS 2019R1 and allowed it 8 cores.
The solver is definitely working on this problem, though will not end up converging. I can see 8 cores being used fully. The computer is using 64 GB of RAM. Here are the last few lines in the Solution Output (solve.out) file.
Iteration= 2750 Ratio= 1.330395E+33 Limit= 1.000000E-08 Wall= 3500.4
Iteration= 2810 Ratio= 6.750189E+32 Limit= 1.000000E-08 Wall= 3576.9
Iteration= 2870 Ratio= 3.321855E+33 Limit= 1.000000E-08 Wall= 3653.3
Iteration= 2930 Ratio= 4.380177E+34 Limit= 1.000000E-08 Wall= 3729.8
Iteration= 2990 Ratio= 3.309826E+35 Limit= 1.000000E-08 Wall= 3806.2
Iteration= 3050 Ratio= 1.183019E+35 Limit= 1.000000E-08 Wall= 3882.6
I'm going to stop that solution now. You can try to suppress half the cylinders and see if that allows the solver to start.
I recommend you reduce the mesh density on the small pads until the model starts running.
-
May 6, 2019 at 3:17 am
peteroznewman
SubscriberWith all the bodies unsuppressed, setting all the small element sizes like 0.25 mm up to 0.8 mm creates a model that will run incore in 14.5 GB of RAM in the Direct (Sparse) Solver using 15 cores on 2019R1. It doesn't converge on a solution, because some elements become highly distorted, but that is another problem.
I then doubled all the small element sizes instead of setting them to 0.8 mm. The Direct solver will not begin iterations in the 2019R1 release and there is no error in solve.out as to why it didn't start iterating. Something goes wrong as the element sizes get smaller, but I don't know what the problem is.
-
May 6, 2019 at 6:37 pm
abcdandy
SubscriberHi Peter
Yes, the contact pairs necessitates those fine meshes. It will experience material distortion past 0.3 mm.Â
What would you recommend as a next step?
Thank you very much,
Andy
-
May 6, 2019 at 7:51 pm
peteroznewman
SubscriberWhen you say Material distortion, do you mean element distortion? Element distortion can happen with small elements and large elements. Making smaller elements does not automatically resolve element distortion problems. Applying the load in smaller increments is typically the best way to avoid element distortion. But once the load has slowly ramped up to a significant value, the elements can become too distorted to continue no matter how slowly the load increments. That is when remeshing may be required, but there is a better approach...
I have had models where the elements were created with a high aspect ratio, in anticipation of being distorted to a lower aspect ratio as the solution progressed. If the elements had started out with an aspect ratio of 1 (perfect cube), the load would not have gotten very large before the solver stopped with a distorted element error. With tall elements at the beginning, the load was able to be increased to its full value without a distorted element error. Using larger elements actually made it easier to mesh these tall elements. Smaller elements would not have been as successful. The same can be said for pre-skewed elements that experience shear. They become less skewed as the shear load increases.
I ran the full model in 18.2 with all the small element sizes tripled, using the Iterative solver, and it made it to the point of iterating. The computer is using 113 GB of RAM. The Direct solver is preferred if the model will solve incore.
Time at end of element matrix formulation CP = 7754.63818.
Memory resident data base increased from 8192 MB to 16384 MB.
ALL CURRENT ANSYS DATA WRITTEN TO FILE NAME= file.rdb
FOR POSSIBLE RESUME FROM THIS POINT
FORCE CONVERGENCE VALUE = 119.0 CRITERION= 0.6074
MOMENT CONVERGENCE VALUE = 4.150 CRITERION= 0.2117E-01
curEqn= 16340 totEqn= 16340 Job CP sec= 7786.977
Factor Done= 100% Factor Wall sec= 0.092 rate= 260.2 Mflops
Iteration= 10 Ratio= 0.172054 Limit= 1.000000E-08 Wall= 6.9
Iteration= 105 Ratio= 3.345729E-03 Limit= 1.000000E-08 Wall= 111.0
Iteration= 160 Ratio= 2.004384E-03 Limit= 1.000000E-08 Wall= 173.0 -
May 7, 2019 at 2:46 am
abcdandy
SubscriberI did not know this. I will definitely try with bigger meshes. Yes I was meaning element distortion.
May I ask how many substeps you used?
Also when you say 'it made it to the point of iterating,' did the solver crash then, or did you terminate it?
Thank you always!
-
May 7, 2019 at 6:57 pm
peteroznewman
SubscriberI used what you had, which was Initial Substeps 1000.
After it started iterating properly, I stopped the solution.
-
December 11, 2019 at 12:48 pm
patriciagomez
SubscriberSPAM
-
December 21, 2020 at 12:49 am
-
- The topic ‘Increased RAM, but still says insufficient memory’ is closed to new replies.
-
3597
-
1273
-
1107
-
1068
-
953
© 2025 Copyright ANSYS, Inc. All rights reserved.