[molpro-user] Permanent installation of dependencies
Gregory Magoon
gmagoon at MIT.EDU
Mon Jul 25 16:13:22 BST 2011
I was able to get it to work (I think) for -auto-ga-tcgmsg-mpich2 by copying
/src/mpich2-install to a permanent location and editing the LAUNCHER variable
in the script file.
A couple more quick questions:
-Is use of mpptune.com recommended or is this deprecated? I think I was
able to
figure out how to run it, but I wasn't sure whether this is helpful or not,
performance-wise.
-I noticed that a text file called libmol.index is kept open by molpro during
execution (and possibly read from (?))...I'm thinking this may be adversely
affecting performance when the file happens to be on an NFS file system. If my
suspicions are correct, is there any way the file can be cached by
reading into
memory?
Thanks,
Greg
Quoting Andy May <MayAJ1 at cardiff.ac.uk>:
> Greg,
>
> Glad to hear you got Molpro running. At the moment the auto-build
> options are marked as experimental, however the only known issue is
> the installation problem you mention. I'm not sure one can simply
> move mpich2/openmpi installation directories, but we will try to
> implement a solution.
>
> Best wishes,
>
> Andy
>
> On 24/07/11 04:12, Gregory Magoon wrote:
>> After some work I was finally able to trace this to some sort of
>> issue between
>> NFSv4 and MPICH2; I can get this to work properly when I mount the
>> NFS drives
>> as NFSv3 (as opposed to NFSv4), so the issue is now more-or-less resolved.
>>
>> A quick follow-up question: Is there a recommended approach for permanent
>> installation of the mpich2 dependency (and maybe also GA?) when
>> using the auto
>> build approach? By default, it seems that the installation scripts leave the
>> mpiexec in the compile directory. I saw that the
>> makefile/installation scripts
>> mention an option called REDIST which seemed like it might allow this,
>> but they
>> don't seem to make use of this option (REDIST=NO).
>>
>> Thanks,
>> Greg
>>
>> Quoting Gregory Magoon<gmagoon at MIT.EDU>:
>>
>>> Hi,
>>> I have successfully compiled molpro (with Global Arrays/TCGMSG; mpich2 from
>>> Ubuntu package) on one of our compute nodes for our new server, and
>>> installed
>>> it in an NFS directory on our head node. The initial tests on the
>>> compute node
>>> ran fine but since the installation, I've had issues with running
>>> molpro on the
>>> compute nodes (it seems to work fine on the head node). Sometimes
>>> (sorry I can't
>>> be more precise, but it does not seem to be reproducible), when
>>> running on the
>>> compute node, the job will get stuck in the early stages, producing a
>>> lot (~14+
>>> Mbps outbound to headnode and 7Mbps inbound from headnode) of NFS
>>> traffic and
>>> causing fairly high nfsd process CPU% usage on the head node. Molpro
>>> processes
>>> in the stuck state are shown in "top" command display at the bottom of the
>>> e-mail. I have also attached example verbose output for a case that
>>> works and a
>>> case that gets stuck.
>>>
>>> Some notes:
>>> -/usr/local is mounted as NFS read-only file system; /home is mounted
>>> as NFS rw
>>> file system
>>> -It seems like runs with fewer processors (e.g. 6) are more likely to run
>>> successfully
>>>
>>> I've tried several approaches for addressing the issue, including
>>> 1. Mounting
>>> /usr/local as rw file system, and 2. Changing the rsize and wsize
>>> parameters
>>> for the NFS filesystem but none seem to work. We also tried piping<
>>> /dev/null
>>> when calling the process, which seemed like it was helping at first,
>>> but later
>>> tests suggested that this wasn't actually helping.
>>>
>>> If anyone has any tips or ideas to help diagnose the issue here, it
>>> would be
>>> greatly appreciated. If there are any additional details I can
>>> provide to help
>>> describe the problem, I'd be happy to provide them.
>>>
>>> Thanks very much,
>>> Greg
>>>
>>> Top processes in "top" output in stuck state:
>>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>> 10 root 20 0 0 0 0 S 10 0.0 0:16.50 kworker/0:1
>>> 2 root 20 0 0 0 0 S 6 0.0 0:10.86 kthreadd
>>> 1496 root 20 0 0 0 0 S 1 0.0 0:04.73 kworker/0:2
>>> 3 root 20 0 0 0 0 S 1 0.0 0:00.93 ksoftirqd/0
>>>
>>> Processes in "top" output for user in stuck state:
>>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>>> 29961 user 20 0 19452 1508 1072 R 0 0.0 0:00.05 top
>>> 1176 user 20 0 91708 1824 868 S 0 0.0 0:00.01 sshd
>>> 1177 user 20 0 24980 7620 1660 S 0 0.0 0:00.41 bash
>>> 1289 user 20 0 91708 1824 868 S 0 0.0 0:00.00 sshd
>>> 1290 user 20 0 24980 7600 1640 S 0 0.0 0:00.32 bash
>>> 1386 user 20 0 4220 664 524 S 0 0.0 0:00.01 molpro
>>> 1481 user 20 0 18764 1196 900 S 0 0.0 0:00.00 mpiexec
>>> 1482 user 20 0 18828 1092 820 S 0 0.0 0:00.00 hydra_pmi_proxy
>>> 1483 user 20 0 18860 488 212 D 0 0.0 0:00.00 hydra_pmi_proxy
>>> 1484 user 20 0 18860 488 212 D 0 0.0 0:00.00 hydra_pmi_proxy
>>> 1485 user 20 0 18860 488 212 D 0 0.0 0:00.00 hydra_pmi_proxy
>>> 1486 user 20 0 18860 488 212 D 0 0.0 0:00.00 hydra_pmi_proxy
>>> 1487 user 20 0 18860 488 212 D 0 0.0 0:00.00 hydra_pmi_proxy
>>> 1488 user 20 0 18860 488 212 D 0 0.0 0:00.00 hydra_pmi_proxy
>>> 1489 user 20 0 18860 488 212 D 0 0.0 0:00.00 hydra_pmi_proxy
>>> 1490 user 20 0 18860 488 208 D 0 0.0 0:00.00 hydra_pmi_proxy
>>> 1491 user 20 0 18860 488 208 D 0 0.0 0:00.00 hydra_pmi_proxy
>>> 1492 user 20 0 18860 488 208 D 0 0.0 0:00.00 hydra_pmi_proxy
>>> 1493 user 20 0 18860 488 208 D 0 0.0 0:00.00 hydra_pmi_proxy
>>> 1494 user 20 0 18860 492 212 D 0 0.0 0:00.00 hydra_pmi_proxy
>>>
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Molpro-user mailing list
>> Molpro-user at molpro.net
>> http://www.molpro.net/mailman/listinfo/molpro-user
>
More information about the Molpro-user
mailing list