malloc during BOLTZTRA (Pproperties)
-
Here is an old input that caused malloc on two different computer systems (I think one of these was Cineca, but that one was run for me by my colleague). I do not need the result of this calculation anymore, but I was told to share it during Crystal school this autumn.
malloc.d3
sb_wyckoff_tzvp.f9 -
Thanks!
Could you share also the .d12 CRYSTAL input that generated the .f9 file? -
Hello!
I found the source file. I have also learned that the .f9 was calculated with Crystal17, and that malloc happened in Props17, not in Props23 (I am likewise not sure whether the calculation that failed for my colleague was done using v17 or v23). This might have been a limitation of the machine that I was using, because the same calculation didn't crash with NEWK 36 72.
malloc.d12I am sorry if that turns out irrelevant, and of no use in the current version of Crystal.
-
Hi,
We have run some tests and we have identified the origin of the problem. The calculation fails in the evaluation of the Fermi energy in the NEWK option (so before getting to the BOLTZTRA step) because of large memory requirements due to a very large number of k-points being asked and because of the replicated-memory parallel implementation of that bit of code.
In that part of the code, with Pproperties (parallel version), data are replicated in memory by each process.
We have run tests on this system in parallel with different number of processes (on a computing node with 128 CPU cores) and for different shrinking factor parameters of the NEWK keyword. Results are summarized in the table below:
"ok" marks combinations for which the calculation run without errors. The trend is clear and can be rationalized as follows:
- reducing the number of k points reduces memory requirments
- reducing the number of MPI processes effectively increases the available memory/process
Hope this clarifies things and helps find a way forward,
