To setting ram disk i dont think speed ill boost too much it ill increase up to max 15 to 20 % only and there are lots of video available at you tube regarding setting of ram disk follow them.

Could you possibly change your program's code to avoid using the hard disk at all? Since you've said that you have 60+GB of RAM and you want some of it to act as a disk (RAM disk, virtually), why not just use RAM as it is and not wast CPU time on system calls for file access and manipulation (even though it would be on a RAM disk)?

Most stock LInux now have ramdisc inbuilt.

goto /dev/shm/

that is ur ramdisc.

have fun. However RAM disc will only help where you have a I/O bottleneck due to slower hard drives, if your program is a processor intensive its not gonna help really.

First check if your code is slow due to heavy access to the physical storage. If that is the case only, the RAM disk idea might help. If the program is running too many loops, the slow is due to bottleneck and RAM is of no use. So, I suggest you first recheck your code before going in to other remedies.

Hakeem, maybe this is what do you mean

http://www.pcadvisor.co.uk/how-to/desktop-pc/3417062/use-ram-disk-speed-up-your-pc-for-free/

http://www.pcworld.com/article/260918/how_to_supercharge_your_pc_with_a_ram_disk.html

Just curious what are you trying to simulate in-silico?

Dear All - Thanks for your inputs

I will check whether RAM Disk is useful to me or not using my simplest test case which takes about 1 day in my Desktop with 8 GB RAM. Then  I will decide further.

I doubt that a ramdisk will help you much.

Linux systems use Virtual Memory which consists of pages.

Most if not all Linux systems now will cache files if the programs in memory are not using those pages.   For data that only read, not modified, if the files are small enough to fit in memory (what you would need for a ramdisk) then you would read once and never again,

  For writes, the data must eventually be flushed to disk.  Pages with modified data are called dirty pages, so any cached write would be in a dirty page.  You can affect how many dirty pages there can be and how often they are flushed to disk via syctl settings like  vm.dirty_background_ratio  and vm.dirty_writeback_centisecs these allow more pages which have been modified to stay in memory so writes to a file will not be flushed to disk as often. 

sysctl -a will show you all syctl settings.  You can modify on the fly with

sysctl -w

commands, or make a permanent change by modifying the file /etc/sysctl.conf

You should be aware that a RAM disk is not permanent storage. When you reboot your computer all the data is gone. If you want to read in data from a file only once you can do that from the harddisk. Otherwise you would need to copy the file to your RAM disk which will probably take the same amount of time. If you want to use the RAM disk for storing results you have to copy the results back to a real harddisk if you want to keep them. Also, if your computer crashes all results will be gone because they were only available in RAM. If you want a speed-up when accessing files you should rather replace your HDD with an SSD.

I would not suggest using a RAM disk as the speed up is not that much, as mentioned by others. You may want to consider non-locking reading and writing. You can implement non-locking threads that read and write data to disk. This will help your program to carry out the calculations, as one thread in cpu is in charge of writing the data to the disk. This can help to avoid stopping the calculations for intensive reading and writing. For multi-threading you can use POSIX which can be easily learned in a couple of days if you are an avid programmer.

you should have told the O.S installed and mesh size being used then it would be straight forward to resolve the speed issue. Now you have a massive 64Gb Ram that can support approx. 35000 Lac cells without hard disc support. If virtual memory is used much of the time is lost in swapping the data, so avoid this. May be you have to closely observe why the speed is low, is it hardware problem or something else.

I have to agree with Mahesh: "May be you have to closely observe why the speed is low, is it hardware problem or something else." Don't do premature optimizations. Always first profile your software and figure out where the bottlenecks are. Then, only address these parts of the source code for optimization. If the harddisk is not your bottleneck it does not make sense to spend time on figuring out yow to configure a RAM disk.

Thanks Mahesh & Simon - I have checked with a bit coarser mesh and it worked out reasonably... It seems that hardware is not a problem... I have to do my meshing properly... Thanks again...

Start with a coarse mesh then study grid independence by grid adaptation method to resolve key regions which can impact your result.If convergence problem arise with heavy mesh then fine tune under-relaxation factors.

ALso, if there is an option to optimize mesh quality without make it coarser  to get better results then you can look for this as well.