DATASETS * FILE LENGTH - too small value and long REAL TIME in parallel

[Leonid Shirkov]

Dear Molpro Community,

I have installed the parallel version of Molpro with  Intel MPI-2. 

I noticed a problem when running Molpro in parallel - the value under LENGTH (MB) is much smaller

than when running in serial (9.14 vs 431.21). As a result (?),  the "REAL TIME  *" of parallel execution 

is a few times larger  comparing to serial, though "CPU TIMES  *" is decreasing as the number of cores is increasing as it should be

(to some limit).  Is there a way to cure it? 

Similar topic has been already discussed

https://www.molpro.net/pipermail/molpro-user/2011-April/004340.html

but it seems this is not my case. 

Another thing is that I see the message in the output  "GA-space will be limited to   8.0 MW (determined by -G option)".

Should this value be increased? I changed it to 1GW, but it didn't help. Is it safe to use the default 8.0 MW for GA-space for all the jobs?

I'm attaching the test input just in case. I tried to run it in parallel on different Molpro installations and it was ok - both cpu and real times were increasing. 

Thank you in advance.

Regards,

Leonid 

[Leonid Shirkov]

Update. It looks like the value LENGTH (MB) must be small in the output when run in parallel and this is 

NOT the reason why my real time is so long. If possilbe, pls change the topic title to "Too long REAL TIME in parallel".

[Tibor Győri]

There are a number of reasons that can cause poor parallel scaling.

Are you having this issue on a supercomputer, cluster or other similar shared computer? Or are you just running this on your PC?

If you are on a cluster this could by caused by the queuing system not assigning multiple CPUs to your job correctly.

[Leonid Shirkov]

This is a stand-alone PC, but I was using some network drive (probably NFS ) for scratch directory. Once changed to local one,

the problem disappeared. Anyway I would like to use the network drive for scratch, what settings have to be changed on it or in Molpro?

[Tibor Győri]

In my opinion using an ordinary network drive as a scratch disk is a very poor choice. So my advice would be to stop trying to use network drives as scratch.

If for whatever reason you really need to use a network drive as scratch, then you have to make sure that:

1. The server providing the network drive has fast disks, especially if multiple PCs are using it as scratch at the same time.

2. The network drive protocol (NFS, Lustre or whatever you use) is properly configured for maximum performance. NFS is probably not the best option, unless you use the latest NFSv4 standard (I think its 4.2 or 4.3) with the new performance enhancements.

3. The network connection between the PC and the server is very fast, ordinary 1 gigabit ethernet is not fast enough for maximum performance, 10 gigabit ethernet or Infiniband is more appropriate.

These three things can be hard and expensive to ensure, so I would again recommend using local scratch. If you want to enhance IO performance, you can fiddle with the disk write cache parameters of the Linux kernel, to better use leftover free RAM as a disk cache. I have seen massive speed boosts on computers that have large amounts of RAM, but slow disks.