CFX CPU time & real time
 

Hi, i would like to ask the following. When i run a simulation with a dens mesh the CPU time might be an hour and the real time is usualy more than a day! When i run the simulation, anything irrelevant is switched off so no memory or cpu is taken. Therefore, i believe all my com strength goes to solving. If so, why is there such a big difference between the two? Is it possible that RAM is not enough, so dumping itterations to RAM requires more than actually solving and thus CPU actual time is less? Can someone help me? Finally, i use CFX 10. Thank you all in advance.

Nick

Re: CFX CPU time & real time
 

It could be swapping memory (so yes, not enough RAM). Take a look at the memory the solver assigned at the start of the run and compare this to the amount of available free RAM on your machine. Mike

Re: CFX CPU time & real time
 

I got the message saying not enough memory and the run then stopped if the memory is really not enough. BTW, I use Windows XP and CFX 10.

Re: CFX CPU time & real time
 

This only tells you if you have enough virtual memory, not RAM. How much memory do you have installed? In the out file, how much memory does the solver report needing?

-Robin

Re: CFX CPU time & real time
 

I would not think it is virtual memory. I have 2G RAM for each computer node. The case that went through reported 1.4G memory used on the node. If I increase the mesh a little bit(probably exceed 1.6G), the solver will report not enough memory and stop the run.

Another possibility is one thread of 32-bit solver-pvm only can take less than 1.7 or 1.8G RAM.

Re: CFX CPU time & real time
 

Hi Bian,

go to advance solver controls(start run window) and increase the memory allocation factor to 1.05 or 1.10. Sometimes the estimated memory requirement is not good enough. 10% more memory allocation will fix it.

Re: CFX CPU time & real time
 

Hi Bian,

I think you are misinterpreting what Virtual Memory is. The OS allocates memory in Virtual Memory space. This is the combination of both physical and scratch space. Typically, you would have 1.5x to 2x more Virtual Memory than RAM. My point to Nick is that he may have 256 MB of RAM but the solver could still allocate 1 GB, as long as he has this much virtual memory. The solver cannot check how much physical RAM is available.

Regarding the practical limit that you run into on Windows, this occurs because of how Windows manages memory and how the solver requests it. The solver will make a single memmory allocation call to get all the memory required for the run. The memory allocation call takes a signed, 32 bit integer and is thus limited to 2 GB. However, the operating system will only allocate the memory if there is a single contiguous chunk of virtual memory available that is large enough. Under Linux this is not generally a problem, unless you have other applications running that are taking up your memory. Windows, however, pre-loads a lot of DLL's and arranges them randomly throughout the virtual memory space. As a result, the solver is often limited to ~1.4 to ~1.7 GB per process, the largest contiguous chunks.

Sometimes you can access more, sometimes less. I have seen the limit drop to as low as 850 MB! You can get around this by running in parallel and spreading the memory requirements across multiple processes, even on a single CPU, although it will cost you a parallel license.

If you run into this problem, you should decrease the memory requirements of the solver by specifying a mem factor of less than 1. The solver generally overestimates the required memory, so there is usually some room to maneuver (Note that the extra memory does not go to waste. The solver will use it to store data that would otherwise be written to the scratch file).

One final note to everyone reading this. If the solver stops due to a memory error, READ THE ERROR MESSAGE CAREFULLY! (all caps to stress the point, not shout :). There are two types of memory allocation errors and how you respond to them is very different:

1) The solver tried to allocate more memory than what was availabe. 2) The solver did not allocate enough memory.

If you run into case 1), you must either close open applications, or reduce the memory required by the solver by either specifying a mem factor less than 1.0, or by splitting the job among multiple solvers.

If you run into case 2), the solver's memory requirements exceeded the estimated value and does not have enough memory to run. If this is the case, you need to increase the memory estimate factor above 1. Try increasing the mem factor by small increments (1.1, 1.2, ...) until you have enough memory to run. Be careful that your error message doesn't change to case 1 as you do this, which may occur if you were close to the virtual memory limit. Case 2 is much more common, by the way.

Hope this helps.

Regards, Robin

Regards, Robin

Re: CFX CPU time & real time
 

Bravo!

Thanks Robin for your detailed explanation.

Here is my summary, correct me if I am wrong. 1) Solver allocates memory from virtual memory of operating systems. If the required memory exceeds physical RAM, wall time will be longer than CPU time, and be careful to your hard drive as it is used for memory swap.

2) If Solver alloactes less memory than actual required, then increase the allocation factor.

3) If there is not enough continues memory for Solver to allocate, reduce the allocation factor to see if the Solver can run. Otherwise, reduce the mesh or break the case into more parallel processing.

Re: CFX CPU time & real time
 

Hi Bain,

Just on your point 1 - just because a bit of swap space is being used as you have gone beyond the available physical RAM does not necessarily mean the job will grind to a halt. Windows has some smarts in it so in time it keeps frequently used memory in physical memory and writes rarely used memory to swap. This means if the memory written to swap is rarely used the simulation run time will not be too much longer than if it had all fit in physical RAM.

The guide I use is to look at the task manager when a job starts up. Generally when disk IO is occuring the CPU load for that processor will drop. As the job starts as you expect it to do a bit of disk IO, but after the job has set up if the CPU load is near 100% then you know you should be right. If the CPU load never gets back to near 100% after starting then you know this job will involve a very long wait.

Glenn Horrocks