Unexpected large Real Time on Macos
20 views
Skip to first unread message
Thierry Leininger
Sep 16, 2025, 6:47:27 AMSep 16
to molpr...@googlegroups.com
Dear Molpro Users
I recently noticed a strange behavior running a calculation on a MacMini (M4 Pro 64Gb memory Sequoia 15.6.1) with Molpro 2025.3.0 (ie the binary available on Molpro web site) using 1 core.
I am computing a potential energy curve of a diatomic and the times below correspond to different bonding distances.
As can be seen, the CPU time is almost always the same along the potential curves but the Real time is really huge for some iterations.
No other calculation is running on the computer.
One of my colleague told me that he noticed the same behavior for some steps during a geometry optimization using molpro2023 on his Mac.
Any hint on what is going on?
Best wishes,
Thierry
tibo...@gmail.com
Sep 16, 2025, 12:18:14 PMSep 16
to molpro-user
Dear Thierry,
Something is wrong with at least one of these timings. The real time can never be shorter than the CPU time if you are using only 1 core. Yet in your table there is an entry where the real time increment is only 5 seconds, while the CPU time is
2724 s.
You should be able to confirm that it is really only 1 thread running with something like htop (if that's available on Mac).
With that said, I recommend checking your disk utilization while Molpro is running (in terms of disk busy%).
The most likely reason for real time being much higher than CPU time (especially when running on only 1 core) is a disk bandwidth bottleneck.
This can be exacerbated by giving Molpro either too much or too little memory, but some methods in Molpro always do a lot of disk IO.
If you are indeed IO-bound, I have no good recommendations I am afraid.
Under Linux you can work around this by setting some kernel tunables to maximize write caching by the OS in free RAM. But this might not be possible under MacOS.
And in general I would caution against running IO heavy quantum chemistry on Macs, unless you are mindful of the impact it can have on the lifespan of your SSD. Like most SSDs, the Mac's storage is made out of NAND chips, which have a rather finite write endurance. Every write to disk damages the NAND chips a tiny amount, which is usually not a concern, but workloads with a lot of disk writes WILL wear out your storage chips. This is especially painful on modern Macs, where replacing the storage chips is unreasonably costly, even in cases where they are on an easy-to-replace module.
The situation is even worse for Macbooks and other Macs where the NAND chips are soldered to the logic board.
I guess one option would be to buy a high-quality (cooling!) Thunderbolt 40 Gbps M.2 NVMe SSD enclosure, fit that with a fast NVMe SSD, and use that external drive as your Molpro scratch drive. This would also spare the expensive internal SSD from being worn down by the large amount of writes.
If that is still not sufficient bandwidth, you could try a Thunderbolt 5 80 Gbps external enclosure (if your Mac has TB5) or multiple TB4 SSDs in RAID 0.
Best,
Tibor
Thierry Leininger
Sep 17, 2025, 7:01:51 AMSep 17
to tibo...@gmail.com, molpro-user
Dear Tibor
Thank you for your explanation. I did indeed extract a wrong timing for the one with REAL TIME=5s but it does not change the global picture as you can see in the new table below.
I was also surprised that the REAL TIME was smaller than the CPU TIME, but unfortunately this is how it appears in the output as you can seen in the joined extract.
As far as I can see I am using just one thread.
Thank you for the information on Mac’s ssd drives. I wasn’t aware of this problem. Then, what about ‘direct’ calculations on Mac?
Anyway, as you suggest I will look for an external drive solution.
Best regards,
Thierry
tibo...@gmail.com
Sep 18, 2025, 9:59:58 AMSep 18
to molpro-user
Dear Thierry,
Integral direct calculations can indeed be a better choice if disk IO is a bottleneck. However, not all methods in Molpro support integral-direct.
Another thing to consider would be density fitting. DF variants of methods often have substantially lower RAM and IO demands. Of course the magnitude of savings and the accuracy penalty differs between methods.
Usually with properly chosen auxiliary basis sets DF is quite accurate.
You could also consider using a smaller basis and MRCI-F12 instead of MRCI.
Best,
Tibor
Reply all
Reply to author
Forward
0 new messages