search

QMCPACK / qmcpack

Main repository for QMCPACK, an open-source production level many-body ab initio Quantum Monte Carlo code for computing the electronic structure of atoms, molecules, and solids with full performance portable GPU support
http://www.qmcpack.org
Other
307 stars 139 forks source link

Discussion: Converter for latest Quantum Espresso (v6.1) #266

Closed prckent closed 6 years ago

prckent commented 7 years ago

Currently we have a patch for QE5.3 to produce the pw2qmcpack executable. This works well but newer QE versions are improved, particularly in the area of exact exchange and threading for memory usage.

Updating the converter is sometimes not trivial due to changes in the QE fortran. We had been planning to use the QE HDF5 implementation so that we can write a converter "once and for all", but the format does not yet appear stable.

I suggest we update the converter for the old .save format used by QE6.1, so that we are up to date with QE. We will benefit from the QE workflow tests developed by @ye-luo .

Comments on this route?

ye-luo commented 7 years ago

QE I/O is still changing drastically. They not only introduced hdf5 but also they are removing IOTK in the case w/o hdf5. The changes will be released in 6.2 at end of august. My plan was to start looking at the changes later July or beginning of august when QE 6.2 is about to release.

1) Using QE hdf5 file? I think the answer is no. Our format is different from QE hdf5 format in many aspect and we don't want to vastly change how we load the data in QMCPACK and get affected by changes in QE hdf5 format. 2) Use hdf5 configuration setup from QE? Yes, we can avoid the painful fixing autoconfigure. Handling the reset source files are much simpler. 3) Not sure if QE adopt hdf5 collective I/O. If so, we can further improve the converter. 4) Once the converted is updated, we can communicate with QE group to see if we can further integrate our converter as an arguement to pw.x. This is pretty doable in coding.

prckent commented 7 years ago

We would convert their HDF5 to our HDF5.

ye-luo commented 7 years ago

@prckent There is no exact one to one mapping between that data and our data. I think it is better to do what we are doing now. Dump the from memory to HDF5. Loading their hdf5/binary file to memory will be handled by QE.

prckent commented 7 years ago

This discussion is intended to be about scheduling. So far no one has replied to say that they really need it or that it would help their efficiency.

[ In the future I would prefer that we don't have to patch QE source code - this is extremely inconvenient to users and to us. If the QE HDF5 output is stable, we can convert it independent of QE source code. ]

jtkrogel commented 7 years ago

If this really made hybrids accessible for the system sizes we care about, then I would use it in the next studies I begin on TMO's. Whether it is critically important or not would depend on its performance relative to LDA+U, but we don't know this yet as we can't evaluate it...