libgetkw does not compile on ubuntu 18-10

[moritz-braun]

Dear Colleagues

I am very much interested in making use of mrchem.

However I cannot compile libgetkw on ubuntu 18-10!

I proceeded as follows. I cloned MRchem , MRcpp and libgetkw from their respective github pages.

Then i installed the prerequisites mentioned in MRchem source code, compiled and installed MRcpp successfully. I then attempted to compile libgetkw as follows:

1. created a directory build in libgetkw
2. ran cmake .. in that directory
3. ran make with the error as below: ( I am only showing the first error message!) [ 11%] Building CXX object C++/CMakeFiles/getkw.dir/Getkw.cpp.o /home/braunm/libgetkw/C++/Getkw.cpp: In member function 'void Getkw::print() const': /home/braunm/libgetkw/C++/Getkw.cpp:87:7: error: no match for 'operator<<' (operand types are 'std::ostream' {aka 'std::basic_ostream'} and 'std::ostream' {aka 'std::basic_ostream'}) cout << repr(cout) << endl;

I have now realized, that a very similar error message appeared in issue #20 which has been closed. I will have a look whether I can find a work around there!

Regards

Moritz Braun

[moritz-braun]

Dear Colleagues

After reading issue #20 I realize it does not assist much.

I would appreciate if one of you could try compiling libgetkw on a ubuntu 18-10 system.

Regards

Moritz

[moritz-braun]

Dear Colleagues

I disagree with however has closed this matter so quickly. This seems to create the impression that those users that are using ubuntu18-10 are of no interest to you. I am disappointed.

Regards

Moritz

[stigrj]

Dear Moritz, thanks for your interest in our code!

From which repo did you clone libgetkw? There's an old unsupported version still around under https://github.com/juselius/libgetkw, but the proper version is located at https://github.com/dev-cafe/libgetkw. This version is supported and should compile smoothly on Ubuntu (requires boost, though).

However, it is not necessary to download MRCPP and libgetkw (and XCFun) manually as they are included as submodules of MRChem. It is also recommended that you use the CMake setup script:

git clone --recursive git@github.com:MRChemSoft/mrchem.git
cd mrchem
./setup --prefix=install-dir --omp build-dir
cd build-dir
make

This will trigger a download of and compile both MRChem, MRCPP, libgetkw and XCFun (but not Eigen3, which must be downloaded manually, along with boost). The above setup with only shared memory parallelization --omp and GNU compiler is recommended on a Ubuntu desktop, but there's also an --mpi and Intel compiler --cxx=icpc option if you are working on a cluster.

Please let me know if you run into more problems.

regards, Stig

PS: I think you closed your own issue when you commented the second time.

[moritz-braun]

Dear Stig

Thanks a lot!

I will try again.

Regards

Moritz Braun

On Fri, Dec 28, 2018 at 12:38 AM Stig Rune Jensen notifications@github.com wrote:

Dear Moritz, thanks for your interest in our code!

From which repo did you clone libgetkw? There's an old unsupported version still around under https://github.com/juselius/libgetkw, but the proper version is located at https://github.com/dev-cafe/libgetkw. This version is supported and should compile smoothly on Ubuntu (requires boost, though).

However, it is not necessary to download MRCPP and libgetkw (and XCFun) manually as they are included as submodules of MRChem. It is also recommended that you use the CMake setup script:

git clone --recursive git@github.com:MRChemSoft/mrchem.git cd mrchem ./setup --prefix=install-dir --omp build-dir cd build-dir make

This will trigger a download of and compile both MRChem, MRCPP, libgetkw and XCFun (but not Eigen3, which must be downloaded manually, along with boost). The above setup with only shared memory parallelization --omp and GNU compiler is recommended on a Ubuntu desktop, but there's also an --mpi and Intel compiler --cxx=icpc option if you are working on a cluster.

Please let me know if you run into more problems.

regards, Stig

PS: I think you closed your own issue when you commented the second time.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179#issuecomment-450244287, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYt1gZQVOgiqVOOhQSwWbPdVZdrlRrKks5u9UvzgaJpZM4ZjBjI .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[moritz-braun]

Dear Stig

Thanks a lot again for your email! I have made use of the recommended repository for libgetkw and can compile and install it now. mrcpp also did compile and install as required. However I get the following error message when trying to compile mrchem [ 1%] Building CXX object src/CMakeFiles/mrchem.dir/parallel.cpp.o In file included from /usr/local/include/MRCPP/trees/FunctionNode.h:6, from /home/braunm/mrchem/src/parallel.cpp:3: /usr/local/include/MRCPP/trees/MWNode.h:10:10: fatal error: utils/omp_utils.h: No such file or directory

include "utils/omp_utils.h"

I have tried to google for omp_utils.h but without success!

I wanted to suggest, that you consider providing a docker image with mrchem since compilation for ubuntu is a bit tricky

Regards

Moritz

On Fri, Dec 28, 2018 at 12:38 AM Stig Rune Jensen notifications@github.com wrote:

Dear Moritz, thanks for your interest in our code!

From which repo did you clone libgetkw? There's an old unsupported version still around under https://github.com/juselius/libgetkw, but the proper version is located at https://github.com/dev-cafe/libgetkw. This version is supported and should compile smoothly on Ubuntu (requires boost, though).

However, it is not necessary to download MRCPP and libgetkw (and XCFun) manually as they are included as submodules of MRChem. It is also recommended that you use the CMake setup script:

git clone --recursive git@github.com:MRChemSoft/mrchem.git cd mrchem ./setup --prefix=install-dir --omp build-dir cd build-dir make

This will trigger a download of and compile both MRChem, MRCPP, libgetkw and XCFun (but not Eigen3, which must be downloaded manually, along with boost). The above setup with only shared memory parallelization --omp and GNU compiler is recommended on a Ubuntu desktop, but there's also an --mpi and Intel compiler --cxx=icpc option if you are working on a cluster.

Please let me know if you run into more problems.

regards, Stig

PS: I think you closed your own issue when you commented the second time.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179#issuecomment-450244287, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYt1gZQVOgiqVOOhQSwWbPdVZdrlRrKks5u9UvzgaJpZM4ZjBjI .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[robertodr]

There is now a Docker image ready (or ready when Docker Hub finishes building it):

docker run --rm -it -v "$PWD":/home/mightybuilder/work mrchemsoft/mrchem_ubuntu-18.04:latest 

This has the serial and OpenMP parallel versions and you will be prompted to choose which one to use when the container starts. Note that this is still Ubuntu 18.04, tests were not passing when building on Ubuntu 18.10

[moritz-braun]

Dear Roberto

Thanks a million!

I really appreciate you efforts.

I will try it out soon.

Regards Moritz

On Sun, Jan 6, 2019 at 4:26 PM Roberto Di Remigio notifications@github.com wrote:

There is now a Docker image ready (or ready when Docker Hub finishes building it):

docker run --rm -it -v "$PWD":/home/mightybuilder/work mrchemsoft/mrchem_ubuntu-18.04:latest

This has the serial and OpenMP parallel versions and you will be prompted to choose which one to use when the container starts. Note that this is still Ubuntu 18.04, tests were not passing when building on Ubuntu 18.10

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179#issuecomment-451745588, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYt1sYMaQPB965xwmX2lEcRwPz4m4xvks5vAgeCgaJpZM4ZjBjI .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[moritz-braun]

Hi I am currently pulling the image!

Regards

Moritz

On Sun, Jan 6, 2019 at 4:26 PM Roberto Di Remigio notifications@github.com wrote:

There is now a Docker image ready (or ready when Docker Hub finishes building it):

docker run --rm -it -v "$PWD":/home/mightybuilder/work mrchemsoft/mrchem_ubuntu-18.04:latest

This has the serial and OpenMP parallel versions and you will be prompted to choose which one to use when the container starts. Note that this is still Ubuntu 18.04, tests were not passing when building on Ubuntu 18.10

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179#issuecomment-451745588, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYt1sYMaQPB965xwmX2lEcRwPz4m4xvks5vAgeCgaJpZM4ZjBjI .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[moritz-braun]

Dear Stig

Thanks a lot you and and you colleagues. Using the docker image of MRCHEM is really the way for me to go! I have also tried to access your publications that you refer to in your Ph.D. but could not find them yet!

Regards

Moritz

On Fri, Dec 28, 2018 at 12:38 AM Stig Rune Jensen notifications@github.com wrote:

Dear Moritz, thanks for your interest in our code!

From which repo did you clone libgetkw? There's an old unsupported version still around under https://github.com/juselius/libgetkw, but the proper version is located at https://github.com/dev-cafe/libgetkw. This version is supported and should compile smoothly on Ubuntu (requires boost, though).

However, it is not necessary to download MRCPP and libgetkw (and XCFun) manually as they are included as submodules of MRChem. It is also recommended that you use the CMake setup script:

git clone --recursive git@github.com:MRChemSoft/mrchem.git cd mrchem ./setup --prefix=install-dir --omp build-dir cd build-dir make

This will trigger a download of and compile both MRChem, MRCPP, libgetkw and XCFun (but not Eigen3, which must be downloaded manually, along with boost). The above setup with only shared memory parallelization --omp and GNU compiler is recommended on a Ubuntu desktop, but there's also an --mpi and Intel compiler --cxx=icpc option if you are working on a cluster.

Please let me know if you run into more problems.

regards, Stig

PS: I think you closed your own issue when you commented the second time.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179#issuecomment-450244287, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYt1gZQVOgiqVOOhQSwWbPdVZdrlRrKks5u9UvzgaJpZM4ZjBjI .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[stigrj]

I'm glad t worked out. The only problem with the current docker images is that you are limited to running on a single work station (e.i. no large scale computer clusters), and the larger calculations quickly become unfeasible.

Open access versions of the first two articles in the thesis (the third one was never actually submitted): https://munin.uit.no/handle/10037/8414 https://munin.uit.no/handle/10037/7046

I should point out, though, that these articles describe old implementation details that are no longer relevant in the latest version of the code.

Our latest two articles (not part of the thesis) are more application rather than implementation oriented: https://munin.uit.no/handle/10037/10512 https://munin.uit.no/handle/10037/13340

regards, Stig

[moritz-braun]

Dear Stig

Thanks a lot!

For the moment the 8 processor version is sufficient, since I am cocentrating on molecules like methane, for which this should be more than enough capacity.

I am also interested in how you "soften" the point-coulomb-charge of the nucleons, while still keeping your error bounds valid. The option in the input file is called nuc_prec.

Regards

Moritz Braun

On Wed, Jan 9, 2019 at 1:52 PM Stig Rune Jensen notifications@github.com wrote:

I'm glad t worked out. The only problem with the current docker images is that you are limited to running on a single work station (e.i. no large scale computer clusters), and the larger calculations quickly become unfeasible.

Open access versions of the first two articles in the thesis (the third one was never actually submitted): https://munin.uit.no/handle/10037/8414 https://munin.uit.no/handle/10037/7046

I should point out, though, that these articles describe old implementation details that are no longer relevant in the latest version of the code.

Our latest two articles (not part of the thesis) are more application rather than implementation oriented: https://munin.uit.no/handle/10037/10512 https://munin.uit.no/handle/10037/13340

regards, Stig

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179#issuecomment-452670327, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYt1jdTxUqr0PCY2zuKB6Xi0MkVOVe_ks5vBdftgaJpZM4ZjBjI .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[stigrj]

The smoothed nuclear potential was first proposed by Robert J. Harrison and coworkers in section V of J. Chem. Phys. 121, 11587 (2004). We are using the exact same form.

[moritz-braun]

Dear Stig

Thanks a lot . I see that the bracket added to the erf term comes to -17/(3*sqrt(3)) at R1 equal 0 This is kind of an odd number.

Regards

Moritz

On Wed, Jan 9, 2019 at 2:26 PM Stig Rune Jensen notifications@github.com wrote:

The smoothed nuclear potential was first proposed by Robert J. Harrison and coworkers in section V of J. Chem. Phys. 121, 11587 (2004) https://aip.scitation.org/doi/10.1063/1.1791051. We are using the exact same form.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179#issuecomment-452679241, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYt1u927qniJG_S0Uwrkw4UjNFzFbJzks5vBd_2gaJpZM4ZjBjI .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[moritz-braun]

Dear Stig

I am trying to understand the meaning of min_scale=-5. Does this mean that the domain is a cube of [-16,16]^3?

Regards

Moritz

On Wed, Jan 9, 2019 at 2:26 PM Stig Rune Jensen notifications@github.com wrote:

The smoothed nuclear potential was first proposed by Robert J. Harrison and coworkers in section V of J. Chem. Phys. 121, 11587 (2004) https://aip.scitation.org/doi/10.1063/1.1791051. We are using the exact same form.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179#issuecomment-452679241, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYt1u927qniJG_S0Uwrkw4UjNFzFbJzks5vBd_2gaJpZM4ZjBjI .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[stigrj]

Currently there's no adjustable scaling factor that allows you to custom fit the computational domain to an arbitrary size (this is coming very soon, though), so the size has to be in the form 2^n, where n is an integer (positive or negative). There are three input parameters that determines the computational domain:

1. The keyword min_scale = -5 means that each side of a "root" cube is of size 2^{5}. If you don't specify any further keywords you will get a single root cube starting from the origin, so your computational domain will be [0, 32]^3.

2. This root box can be translated by integer values at the length scale of min_scale. This is done with the corner keyword, and a root translation of e.g. corner = [1,1,1] gives the domain [32, 64]^3, while corner = [-1,-1,-1] means [-32, 0]^3.

3. Finally there's the boxes keyword which gives the number of root boxes, e.g. boxes = [2,2,2], which means that we have two root cubes in each direction, 8 in total, each of size 2^{-min_scale}.

Putting it all together we can create a domain of [-32, 32]^3 in the following way:

MRA {
  min_scale = -5
  corner = [-1,-1,-1]
  boxes = [2, 2, 2]
}

[moritz-braun]

Dear Stig

Thanks for your reply . I figured it our correctly. Regards

Moritz

On Thu, Jan 10, 2019 at 1:10 AM Stig Rune Jensen notifications@github.com wrote:

Currently there's no adjustable scaling factor that allows you to custom fit the computational domain to an arbitrary size (this is coming very soon, though), so the size has to be in the form 2^n, where n is an integer (positive or negative). There are three input parameters that determines the computational domain:

1.

The keyword min_scale = -5 means that each side of a "root" cube is of size 2^{5}. If you don't specify any further keywords you will get a single root cube starting from the origin, so your computational domain will be [0, 32]^3. 2.

This root box can be translated by integer values at the length scale of min_scale. This is done with the corner keyword, and a root translation of e.g. corner = [1,1,1] gives the domain [32, 64]^3, while corner = [-1,-1,-1] means [-32, 0]^3. 3.

Finally there's the boxes keyword which gives the number of root boxes, e.g. boxes = [2,2,2], which means that we have two root cubes in each direction, 8 in total, each of size 2^{-min_scale}.

Putting it all together we can create a domain of [-32, 32]^3 in the following way:

MRA { min_scale = -5 corner = [-1,-1,-1] boxes = [2, 2, 2] }

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179#issuecomment-452904388, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYt1rk01_fSLz0EmHPJU6il3ekXsY1-ks5vBnbngaJpZM4ZjBjI .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[moritz-braun]

Dear Stig

I wanted to ask which eigen value solver you are currently using in mrchem?

Regards

Moritz

On Thu, Jan 10, 2019 at 1:10 AM Stig Rune Jensen notifications@github.com wrote:

Currently there's no adjustable scaling factor that allows you to custom fit the computational domain to an arbitrary size (this is coming very soon, though), so the size has to be in the form 2^n, where n is an integer (positive or negative). There are three input parameters that determines the computational domain:

1.

The keyword min_scale = -5 means that each side of a "root" cube is of size 2^{5}. If you don't specify any further keywords you will get a single root cube starting from the origin, so your computational domain will be [0, 32]^3. 2.

This root box can be translated by integer values at the length scale of min_scale. This is done with the corner keyword, and a root translation of e.g. corner = [1,1,1] gives the domain [32, 64]^3, while corner = [-1,-1,-1] means [-32, 0]^3. 3.

Finally there's the boxes keyword which gives the number of root boxes, e.g. boxes = [2,2,2], which means that we have two root cubes in each direction, 8 in total, each of size 2^{-min_scale}.

Putting it all together we can create a domain of [-32, 32]^3 in the following way:

MRA { min_scale = -5 corner = [-1,-1,-1] boxes = [2, 2, 2] }

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179#issuecomment-452904388, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYt1rk01_fSLz0EmHPJU6il3ekXsY1-ks5vBnbngaJpZM4ZjBjI .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[stigrj]

We are using the Eigen3 library: http://eigen.tuxfamily.org/index.php?title=Main_Page

[moritz-braun]

Hi Stig

Thanks!

In my density functional calculations I use the Symmetric Jacobi Davidson python bindings ( jdsym from py-sparse)

Regards

Moritz

On Fri, Jan 11, 2019 at 11:04 AM Stig Rune Jensen notifications@github.com wrote:

We are using the Eigen3 library: http://eigen.tuxfamily.org/index.php?title=Main_Page

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179#issuecomment-453440363, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYt1m2lUttVZBHllsA4NvEKAMvEnTmmks5vCFOwgaJpZM4ZjBjI .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[moritz-braun]

Dear Stig

As far I can see, there is no eigensolver for sparse matrices in Eigen3. Which method do you use more specifically?

Regards

Moritz

On Fri, Jan 11, 2019 at 11:04 AM Stig Rune Jensen notifications@github.com wrote:

We are using the Eigen3 library: http://eigen.tuxfamily.org/index.php?title=Main_Page

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179#issuecomment-453440363, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYt1m2lUttVZBHllsA4NvEKAMvEnTmmks5vCFOwgaJpZM4ZjBjI .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[stigrj]

No, we don't use sparse matrices in MRChem at this point, since the eigensolver has so far not been a bottleneck in our implementation. We only compute and diagonalize the occupied part of the Fock matrix, and so far we have been limited to <100 orbitals which is sufficiently fast with the SelfAdjointEigenSolver in Eigen. We have only recently started to push for molecules with >100 orbitals, so we might have to reconsider this in the future.

[moritz-braun]

Dear Stig

I must admit, that I am quite confuse now! If I understand you combined finite element /wavelet method correctly you will have of the the order 10^4 to 10^5 coefficients, i.e. degrees of freedom. However you are only solving an eigenvalue problem of order <100.

From you Ph.D. I realize, that you are solving an eigen value problem that contains an integral operator which is equivalent to (-1/2 nabla^2+e) ^ -1.

However I still do not understand how you manage to reduce the size of your problem so radically!

Regards

Moritz

On Fri, Jan 11, 2019 at 4:07 PM Stig Rune Jensen notifications@github.com wrote:

No, we don't use sparse matrices in MRChem at this point, since the eigensolver has so far not been a bottleneck in our implementation. We only compute and diagonalize the occupied part of the Fock matrix, and so far we have been limited to <100 orbitals which is sufficiently fast with the SelfAdjointEigenSolver in Eigen. We have only recently started to push for molecules with >100 orbitals, so we might have to reconsider this in the future.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179#issuecomment-453527391, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYt1pApeDxbnM4iREuqgXukIQl7CUmSks5vCJqugaJpZM4ZjBjI .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[stigrj]

Actually, each occupied orbital is typically expanded in ~10^7 basis functions (or grid points, if you will), which is precisely why we cannot diagonalize this problem in the usual sense. What we do instead is, as you mention, to rewrite the SCF equations into integral form and we end up with one equation for each occupied orbital, coupled through the two-electron part of the Fock operator. These equations are solved iteratively, where the only need for matrix diagonalization is to obtain the orbital energies that appear in the integral operator, but this is again only the occupied part (think of it as an MO basis, not AO basis).

[moritz-braun]

Dear Stig

Thanks!

I have been reading in you thesis about the power method + KAIN and now it becomes a bit clearer.

Regards

Moritz

On Fri, Jan 11, 2019 at 4:46 PM Stig Rune Jensen notifications@github.com wrote:

Actually, each occupied orbital is typically expanded in ~10^7 basis functions (or grid points, if you will), which is precisely why we cannot diagonalize this problem in the usual sense. What we do instead is, as you mention, to rewrite the SCF equations into integral form and we end up with one equation for each occupied orbital, coupled through the two-electron part of the Fock operator. These equations are solved iteratively, where the only need for matrix diagonalization is to obtain the orbital energies that appear in the integral operator, but this is again only the occupied part (think of it as an MO basis, not AO basis).

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179#issuecomment-453539833, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYt1uxGfqGliaE3D_UQQqiK8DLXGm8Iks5vCKPAgaJpZM4ZjBjI .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[moritz-braun]

Dear Stig

I have another question:

Is the MultiResolution Waveletbasis a tensor basis, i.e. does the application of the Poisson or Helmholtzkernel factorize into a sum over products of three integrals? Otherwise the application of these operators would be equivalent to multiplication by a full matrix of order 10^7 it seems to me.

Regards

Moriz

On Fri, Jan 11, 2019 at 4:46 PM Stig Rune Jensen notifications@github.com wrote:

Actually, each occupied orbital is typically expanded in ~10^7 basis functions (or grid points, if you will), which is precisely why we cannot diagonalize this problem in the usual sense. What we do instead is, as you mention, to rewrite the SCF equations into integral form and we end up with one equation for each occupied orbital, coupled through the two-electron part of the Fock operator. These equations are solved iteratively, where the only need for matrix diagonalization is to obtain the orbital energies that appear in the integral operator, but this is again only the occupied part (think of it as an MO basis, not AO basis).

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179#issuecomment-453539833, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYt1uxGfqGliaE3D_UQQqiK8DLXGm8Iks5vCKPAgaJpZM4ZjBjI .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[stigrj]

Yes, it's a tensor basis and the operators factorize, which is essential for efficiency.

[stigrj]

Dear Moritz,

I'm going to close this issue since the original problem has been resolved. If you have further questions or technical problems, please don't hesitate to open a new issue or contact us at our new user support Slack channel.

regards, Stig

[moritz-braun]

Dear Roberto

With a number of months passed and having installed a new version of ubuntu , 19-04, installed,I again attempted to compile mrchem. The prerequisite mrcpp was compiled installed and tested, passing all tests. However, when compiling mrchem I obtained the attached error output, which seems to involve the mrcpp library, which I did install and even test!.

Any assistance will be much appreciated!

Regards

Moritz

On Sun, Jan 6, 2019 at 4:26 PM Roberto Di Remigio notifications@github.com wrote:

There is now a Docker image ready (or ready when Docker Hub finishes building it):

docker run --rm -it -v "$PWD":/home/mightybuilder/work mrchemsoft/mrchem_ubuntu-18.04:latest

This has the serial and OpenMP parallel versions and you will be prompted to choose which one to use when the container starts. Note that this is still Ubuntu 18.04, tests were not passing when building on Ubuntu 18.10

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179#issuecomment-451745588, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYt1sYMaQPB965xwmX2lEcRwPz4m4xvks5vAgeCgaJpZM4ZjBjI .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[stigrj]

Dear Moritz, I don't think your email attachment found its way to this github issue. Can you please provide the error message as plain text?

Can you also provide which git revisions of MRChem and MRCPP you are trying to compile?

I am still working on Ubuntu-18.10 so I don't know yet what problems are lurking in 19.04.

regards Stig

[moritz-braun]

Dear Stig

the output of the build process is below!

Regards

Moritz

[ 1%] Building CXX object src/CMakeFiles/mrchem.dir/mrenv.cpp.o [ 2%] Building CXX object src/CMakeFiles/mrchem.dir/chemistry/chemistry_utils.cpp.o [ 3%] Building CXX object src/CMakeFiles/mrchem.dir/chemistry/PeriodicTable.cpp.o [ 4%] Building CXX object src/CMakeFiles/mrchem.dir/chemistry/Molecule.cpp.o [ 5%] Building CXX object src/CMakeFiles/mrchem.dir/chemistry/Cavity.cpp.o [ 6%] Building CXX object src/CMakeFiles/mrchem.dir/analyticfunctions/HydrogenFunction.cpp.o [ 8%] Building CXX object src/CMakeFiles/mrchem.dir/analyticfunctions/NuclearFunction.cpp.o [ 9%] Building CXX object src/CMakeFiles/mrchem.dir/analyticfunctions/NuclearGradientFunction.cpp.o [ 10%] Building CXX object src/CMakeFiles/mrchem.dir/qmfunctions/QMFunction.cpp.o [ 11%] Building CXX object src/CMakeFiles/mrchem.dir/qmfunctions/Orbital.cpp.o [ 12%] Building CXX object src/CMakeFiles/mrchem.dir/qmfunctions/OrbitalIterator.cpp.o [ 13%] Building CXX object src/CMakeFiles/mrchem.dir/qmfunctions/Density.cpp.o [ 14%] Building CXX object src/CMakeFiles/mrchem.dir/qmfunctions/qmfunction_utils.cpp.o [ 16%] Building CXX object src/CMakeFiles/mrchem.dir/qmfunctions/orbital_utils.cpp.o /home/braunm/mrchem/src/qmfunctions/orbital_utils.cpp: In function 'int mrchem::orbital::print_size_nodes(const OrbitalVector&, const string&, bool, int)': /home/braunm/mrchem/src/qmfunctions/orbital_utils.cpp:903:60: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings] vecStats(4, mpi::orb_rank) = Printer::printMem("", true); ^ [ 17%] Building CXX object src/CMakeFiles/mrchem.dir/qmfunctions/density_utils.cpp.o [ 18%] Building CXX object src/CMakeFiles/mrchem.dir/qmoperators/RankZeroTensorOperator.cpp.o [ 19%] Building CXX object src/CMakeFiles/mrchem.dir/qmoperators/RankOneTensorOperator.cpp.o [ 20%] Building CXX object src/CMakeFiles/mrchem.dir/qmoperators/RankTwoTensorOperator.cpp.o [ 21%] Building CXX object src/CMakeFiles/mrchem.dir/qmoperators/one_electron/DeltaOperator.cpp.o [ 22%] Building CXX object src/CMakeFiles/mrchem.dir/qmoperators/one_electron/IdentityOperator.cpp.o [ 24%] Building CXX object src/CMakeFiles/mrchem.dir/qmoperators/one_electron/KineticOperator.cpp.o [ 25%] Building CXX object src/CMakeFiles/mrchem.dir/qmoperators/one_electron/NuclearOperator.cpp.o [ 26%] Building CXX object src/CMakeFiles/mrchem.dir/qmoperators/one_electron/NuclearGradientOperator.cpp.o [ 27%] Building CXX object src/CMakeFiles/mrchem.dir/qmoperators/one_electron/MomentumOperator.cpp.o [ 28%] Building CXX object src/CMakeFiles/mrchem.dir/qmoperators/one_electron/NablaOperator.cpp.o [ 29%] Building CXX object src/CMakeFiles/mrchem.dir/qmoperators/one_electron/PositionOperator.cpp.o [ 31%] Building CXX object src/CMakeFiles/mrchem.dir/qmoperators/one_electron/DistanceOperator.cpp.o [ 32%] Building CXX object src/CMakeFiles/mrchem.dir/qmoperators/one_electron/SpinOperator.cpp.o [ 33%] Building CXX object src/CMakeFiles/mrchem.dir/qmoperators/one_electron/QMPotential.cpp.o [ 34%] Building CXX object src/CMakeFiles/mrchem.dir/qmoperators/two_electron/CoulombPotential.cpp.o [ 35%] Building CXX object src/CMakeFiles/mrchem.dir/qmoperators/two_electron/CoulombPotentialD1.cpp.o [ 36%] Building CXX object src/CMakeFiles/mrchem.dir/qmoperators/two_electron/CoulombPotentialD2.cpp.o [ 37%] Building CXX object src/CMakeFiles/mrchem.dir/qmoperators/two_electron/ExchangePotential.cpp.o [ 39%] Building CXX object src/CMakeFiles/mrchem.dir/qmoperators/two_electron/FockOperator.cpp.o [ 40%] Building CXX object src/CMakeFiles/mrchem.dir/qmoperators/two_electron/XCPotential.cpp.o [ 41%] Building CXX object src/CMakeFiles/mrchem.dir/qmoperators/two_electron/XCPotentialD1.cpp.o [ 42%] Building CXX object src/CMakeFiles/mrchem.dir/qmoperators/two_electron/XCPotentialD2.cpp.o [ 43%] Building CXX object src/CMakeFiles/mrchem.dir/mrdft/XCFunctional.cpp.o [ 44%] Building CXX object src/CMakeFiles/mrchem.dir/scf_solver/Accelerator.cpp.o [ 45%] Building CXX object src/CMakeFiles/mrchem.dir/scf_solver/EnergyOptimizer.cpp.o [ 47%] Building CXX object src/CMakeFiles/mrchem.dir/scf_solver/GroundStateSolver.cpp.o [ 48%] Building CXX object src/CMakeFiles/mrchem.dir/scf_solver/HelmholtzVector.cpp.o [ 49%] Building CXX object src/CMakeFiles/mrchem.dir/scf_solver/KAIN.cpp.o [ 50%] Building CXX object src/CMakeFiles/mrchem.dir/scf_solver/LinearResponseSolver.cpp.o [ 51%] Building CXX object src/CMakeFiles/mrchem.dir/scf_solver/OrbitalOptimizer.cpp.o [ 52%] Building CXX object src/CMakeFiles/mrchem.dir/scf_solver/SCFSolver.cpp.o [ 54%] Building CXX object src/CMakeFiles/mrchem.dir/utils/math_utils.cpp.o [ 55%] Building CXX object src/CMakeFiles/mrchem.dir/utils/NonlinearMaximizer.cpp.o [ 56%] Building CXX object src/CMakeFiles/mrchem.dir/utils/RRMaximizer.cpp.o [ 57%] Building CXX object src/CMakeFiles/mrchem.dir/utils/gto_utils/AOBasis.cpp.o [ 58%] Building CXX object src/CMakeFiles/mrchem.dir/utils/gto_utils/AOContraction.cpp.o [ 59%] Building CXX object src/CMakeFiles/mrchem.dir/utils/gto_utils/Intgrl.cpp.o [ 60%] Building CXX object src/CMakeFiles/mrchem.dir/utils/gto_utils/OrbitalExp.cpp.o [ 62%] Building CXX object src/CMakeFiles/mrchem.dir/initial_guess/core.cpp.o [ 63%] Building CXX object src/CMakeFiles/mrchem.dir/initial_guess/sad.cpp.o [ 64%] Building CXX object src/CMakeFiles/mrchem.dir/initial_guess/gto.cpp.o [ 65%] Linking CXX static library ../lib/libmrchem.a [ 66%] Built target mrchem Scanning dependencies of target mrchem.x [ 67%] Building CXX object src/CMakeFiles/mrchem.x.dir/mrchem.cpp.o [ 68%] Building CXX object src/CMakeFiles/mrchem.x.dir/SCFDriver.cpp.o [ 70%] Linking CXX executable ../bin/mrchem.x /usr/bin/ld: ../lib/libmrchem.a(mrenv.cpp.o): in function mrenv::initialize(int, char**)': mrenv.cpp:(.text+0x8c3): undefined reference to mrcpp::BoundingBox<3>::BoundingBox(int, std::array<int, 3ul> const&, std::array<int, 3ul> const&, std::array<double, 3ul> const&)' /usr/bin/ld: ../lib/libmrchem.a(QMFunction.cpp.o): in function mrchem::QMFunction::crop(double)': QMFunction.cpp:(.text+0x6e3): undefined reference to mrcpp::FunctionTree<3>::crop(double, double, bool)' /usr/bin/ld: QMFunction.cpp:(.text+0x70b): undefined reference to mrcpp::FunctionTree<3>::crop(double, double, bool)' /usr/bin/ld: ../lib/libmrchem.a(orbital_utils.cpp.o): in function mrchem::orbital::print_size_nodes(std::vector<mrchem::Orbital, std::allocator > const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, bool, int)': orbital_utils.cpp:(.text+0x282e): undefined reference to mrcpp::Printer::printMem(char*, bool)' /usr/bin/ld: ../lib/libmrchem.a(XCFunctional.cpp.o): in function mrdft::XCFunctional::pruneGrid(double, bool)': XCFunctional.cpp:(.text+0xff2): undefined reference to mrcpp::FunctionTree<3>::crop(double, double, bool)' /usr/bin/ld: XCFunctional.cpp:(.text+0x1011): undefined reference to mrcpp::FunctionTree<3>::crop(double, double, bool)' /usr/bin/ld: XCFunctional.cpp:(.text+0x1073): undefined reference to `mrcpp::FunctionTree<3>::crop(double, double, bool)' collect2: error: ld returned 1 exit status make[2]: [src/CMakeFiles/mrchem.x.dir/build.make:100: bin/mrchem.x] Error 1 make[1]: [CMakeFiles/Makefile2:1012: src/CMakeFiles/mrchem.x.dir/all] Error 2 make: *** [Makefile:141: all] Error 2

On Tue, Jul 9, 2019 at 9:20 AM Stig Rune Jensen notifications@github.com wrote:

Dear Moritz, I don't think your email attachment found its way to this github issue. Can you please provide the error message as plain text?

Can you also provide which git revisions of MRChem and MRCPP you are trying to compile?

I am still working on Ubuntu-18.10 so I don't know yet what problems are lurking in 19.04.

regards Stig

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179?email_source=notifications&email_token=AADC3VT3CRAYWVCHZU2BIQTP6Q33TA5CNFSM4GMMDDEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZPLCXY#issuecomment-509522271, or mute the thread https://github.com/notifications/unsubscribe-auth/AADC3VQCFNJWUPUPOP65AVLP6Q33TANCNFSM4GMMDDEA .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[stigrj]

Hmm, looks like the linker is unable to find the MRCPP objects. Did you configure CMake using the setup script? Try the following: 1) $ cd mrchem 2) Remove any existing mrchem build directory 3) $ git checkout release/0.1.0 4) $ ./setup --omp build 5) $ cd build 6) $ make

If you did not install MRCPP globally (e.g. /usr/local/) you'll need to add $ export MRCPP_DIR=/path/to/mrcpp/install/dir/ before you run the setup script.

regards, Stig

[moritz-braun]

Hi Stig

I did install mrcpp globally assuming It would be found!

Regads

Moritz

On Wed, Jul 10, 2019 at 3:40 PM Stig Rune Jensen notifications@github.com wrote:

Hmm, looks like the linker is unable to find the MRCPP objects. Did you configure CMake using the setup script? Try the following:

1. $ cd mrchem
2. Remove any existing mrchem build directory
3. $ git checkout release/0.1.0
4. $ ./setup --omp build
5. $ cd build
6. $ make

If you did not install MRCPP globally (e.g. /usr/local/) you'll need to add $ export MRCPP_DIR=/path/to/mrcpp/install/dir/ before you run the setup script.

regards, Stig

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179?email_source=notifications&email_token=AADC3VQXRCYU4C7IJDVK45TP6XRF3A5CNFSM4GMMDDEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZTPXFY#issuecomment-510065559, or mute the thread https://github.com/notifications/unsubscribe-auth/AADC3VXVYYWSINCNRLRK2PDP6XRF3ANCNFSM4GMMDDEA .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[stigrj]

Ok, that should be fine. Did you follow the other steps, in particular $ git checkout release/0.1.0 and $ ./setup --omp build

Can you post the output from the setup command?

regards, Stig

[moritz-braun]

Dear Stig

After recompiling mrcpp, installing it in a subdirectory of my home directory making MR_CPP point to it the compilation worked !

Regards

Moritz

On Wed, Jul 10, 2019 at 5:03 PM Stig Rune Jensen notifications@github.com wrote:

Ok, that should be fine. Did you follow the other steps, in particular $ git checkout release/0.1.0 and $ ./setup --omp build

Can you post the output from the setup command?

regards, Stig

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179?email_source=notifications&email_token=AADC3VQ3DYI4HFYCYW3RQNTP6X23NA5CNFSM4GMMDDEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZTYEHI#issuecomment-510099997, or mute the thread https://github.com/notifications/unsubscribe-auth/AADC3VR65ATGWBX5IIJENH3P6X23NANCNFSM4GMMDDEA .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[stigrj]

Great! There's probably an issue with the global installation then. I haven't installed globally for ages, so it's basically untested.

best wishes, Stig

[moritz-braun]

Dear Stig

I have not started to (try) to run mrchem for other molecules. I tried CH4/ Methane and realized, that the initial guess directory used for H20 could not be used for Methane. Doing so resulted in a wrong total energy! How does one go about constructing the initial guess for Methane automically?

Regards

Moritz

On Wed, Jul 10, 2019 at 5:33 PM Stig Rune Jensen notifications@github.com wrote:

Great! There's probably an issue with the global installation then. I haven't installed globally for ages, so it's basically untested.

best wishes, Stig

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179?email_source=notifications&email_token=AADC3VRF2ZGFTANQFVOMFPDP6X6OFA5CNFSM4GMMDDEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZT3IQI#issuecomment-510112833, or mute the thread https://github.com/notifications/unsubscribe-auth/AADC3VXSFUW6QANOARASORLP6X6OFANCNFSM4GMMDDEA .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[stigrj]

Yes, unfortunately there's no simple way to generate a GTO initial guess for new molecules. However, we do have a superposition of atomic densities (SAD) initial guess that should work fine for most small to medium sized molecules, which is currently supported for all atoms up to Kr. To use this you need to switch to

SCF {
  initial_guess = SAD_DZ
}

(DZ refers to the quality of the AO basis used in the SAD guess, and double-zeta is usually the best choice)

all the best, Stig

[moritz-braun]

Dear Stig

Thanks a lot for your answer!

Regards

Moritz

On Fri, Jul 12, 2019 at 11:59 PM Stig Rune Jensen notifications@github.com wrote:

Yes, unfortunately there's no simple way to generate a GTO initial guess for new molecules. However, we do have a superposition of atomic densities (SAD) initial guess that should work fine for most small to medium sized molecules, which is currently supported for all atoms up to Kr. To use this you need to switch to

SCF { initial_guess = SAD_DZ }

(DZ refers to the quality of the AO basis used in the SAD guess, and double-zeta is usually the best choice)

all the best, Stig

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179?email_source=notifications&email_token=AADC3VSY6TZERQDLJEMUAJLP7D5ELA5CNFSM4GMMDDEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ27JPQ#issuecomment-511046846, or mute the thread https://github.com/notifications/unsubscribe-auth/AADC3VTBNBBCC5EIL3T3UIDP7D5ELANCNFSM4GMMDDEA .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[moritz-braun]

Dear Stig

Will I thus have to create an empty directory for the iintial guess?

Regards

Moritz

On Fri, Jul 12, 2019 at 11:59 PM Stig Rune Jensen notifications@github.com wrote:

Yes, unfortunately there's no simple way to generate a GTO initial guess for new molecules. However, we do have a superposition of atomic densities (SAD) initial guess that should work fine for most small to medium sized molecules, which is currently supported for all atoms up to Kr. To use this you need to switch to

SCF { initial_guess = SAD_DZ }

(DZ refers to the quality of the AO basis used in the SAD guess, and double-zeta is usually the best choice)

all the best, Stig

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179?email_source=notifications&email_token=AADC3VSY6TZERQDLJEMUAJLP7D5ELA5CNFSM4GMMDDEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ27JPQ#issuecomment-511046846, or mute the thread https://github.com/notifications/unsubscribe-auth/AADC3VTBNBBCC5EIL3T3UIDP7D5ELANCNFSM4GMMDDEA .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[stigrj]

That should not be necessary. There will be created such a folder automatically, but it will remain empty in the case of SAD.

[moritz-braun]

Thanks! Regards

Moritz

On Sat, Jul 13, 2019 at 8:41 AM Stig Rune Jensen notifications@github.com wrote:

That should not be necessary. There will be created such a folder automatically, but it will remain empty in the case of SAD.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179?email_source=notifications&email_token=AADC3VV4PDJ6VNCHL6PP63TP7F2K5A5CNFSM4GMMDDEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ3LBPI#issuecomment-511094973, or mute the thread https://github.com/notifications/unsubscribe-auth/AADC3VV3G7UMAOCQ2CMRKZTP7F2K5ANCNFSM4GMMDDEA .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[moritz-braun]

Dear Stig

I was now able to run the DFT mode for both methane and ethane. However I get a deviation from my results with another method. Therefore I would like to establish what the equivalent Exchange and Correlation functionals in xclib are to those that you are using for LDA i.e. SLATERX and PW92C

Regards

Moritz

On Sat, Jul 13, 2019 at 8:41 AM Stig Rune Jensen notifications@github.com wrote:

That should not be necessary. There will be created such a folder automatically, but it will remain empty in the case of SAD.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179?email_source=notifications&email_token=AADC3VV4PDJ6VNCHL6PP63TP7F2K5A5CNFSM4GMMDDEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ3LBPI#issuecomment-511094973, or mute the thread https://github.com/notifications/unsubscribe-auth/AADC3VV3G7UMAOCQ2CMRKZTP7F2K5ANCNFSM4GMMDDEA .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[stigrj]

If you only specify "LDA" you will get SLATERX + VWN5C, but you can get the functional you want with the following setup:

WaveFunction {
  method = DFT
} 

DFT {
$functionals
SLATERX
PW92C
$end
} 

[moritz-braun]

Dear Stig

There seems to be a misunderstanding!

The combination of SLATERX and PW92C is what I have used sofar in the hope of creating the same functional as for the combination of xc_lda_x of xc_lda_c_pw from the libXC library. However there is a difference of the order of 1 Hartree between the total energy obtained using mrchem and my finite element code.

If understand the source code of mrchem correctly it uses xcfun for the functionals.

Thus I want to run mrchem with the same functional as I have used for my finite element code.

Regards

Moritz

On Sat, Jul 13, 2019 at 2:05 PM Stig Rune Jensen notifications@github.com wrote:

If you only specify "LDA" you will get SLATERX + VWN5C, but you can get the functional you want with the following setup:

WaveFunction { method = DFT }

DFT { $functionals SLATERX PW92C $end }

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179?email_source=notifications&email_token=AADC3VX5Z74XCPFCBYPD2L3P7HAIPA5CNFSM4GMMDDEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ3QMZI#issuecomment-511116901, or mute the thread https://github.com/notifications/unsubscribe-auth/AADC3VTGOO64S53YW2TXD2DP7HAIPANCNFSM4GMMDDEA .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[stigrj]

Hmm, that's strange. Do you have coordinates in bohrs or angstrom? In case of the latter you have to use

Molecule {
  angstrom = true
}

Otherwise, can you please post the entire input fine here so I can have a look?

regards, Stig

[moritz-braun]

Dear Stig

It seems I have not explained my observation in full!

The test example h2o_energy_lda provided in the source code of mrchem used the following definition for the dft functional:

DFT { $functionals SLATERX VWN5C $end } The resulting total energy of -75.855649 au deviates from the LDA energy of my finite element code for H2O namely -75.908 au

Trying to make the density functionals used in the mrchem code and my own code agree I then changed the DFT specification to

DFT { $functionals SLATERX PW92C $end } the resulting total energy then was -75.852838 au i.e. only a change in the third digit.

Thus I wanted to clarify which library mrchem is using to specify the exchange and correlation functionals in order to , so to speak, compare apples with apples, i.e. run mrchem and my finite element code with identical density functionals!

Regards

Moritz

-

On Sun, Jul 14, 2019 at 1:42 AM Stig Rune Jensen notifications@github.com wrote:

Hmm, that's strange. Do you have coordinates in bohrs or angstrom? In case of the latter you have to use

Molecule { angstrom = true }

Otherwise, can you please post the entire input fine here so I can have a look?

regards, Stig

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179?email_source=notifications&email_token=AADC3VU344EJF2Z26B5WF53P7JR77A5CNFSM4GMMDDEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ33IJY#issuecomment-511161383, or mute the thread https://github.com/notifications/unsubscribe-auth/AADC3VSXW5VPDQROAFSDJFTP7JR77ANCNFSM4GMMDDEA .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[stigrj]

Ok, I think I understand what's happening. The H2O test example doesn't do any SCF optimization. I think you will find the keyword

SCF {
  run = false
}

in your input. This means that the total energy is computed directly using the initial guess orbitals, which is done in order to reduce the execution time for the test suite. If you just remove this keyword it should run properly.

With rel_prec = 1.0e-6 I get the following energies for H2O (errors should be within a few micro-Hartree):

SVWN5: -75.913556 au
SPW92: -75.910780 au

With run = false I get energies in the order of -75.85...

But yes, we are using the XCFun library for functionals and we do not have access to libxc. However, we have verified identical energies down to nano-Hartree on atoms for most of the usual functionals (SVWN5, PBE, BLYP, PW92 etc.).

regards, Stig

[moritz-braun]

Dear Stig

Thanks a lot for that hint with removing run=false !It was of course a bit difficult for me to see that. I have in the meantime, using the respective python interfaces, compared my choice of xcfun functionals for mrchem with the choice of libxc functionals for the other code and between 0 and 10 the vxc differ by less than 5 x 10^{-7} au!

Regards

Moritz

On Sun, Jul 14, 2019 at 9:15 PM Stig Rune Jensen notifications@github.com wrote:

Ok, I think I understand what's happening. The H2O test example doesn't do any SCF optimization. I think you will find the keyword

SCF { run = false }

in your input. This means that the total energy is computed directly using the initial guess orbitals, which is done in order to reduce the execution time for the test suite. If you just remove this keyword it should run properly.

With rel_prec = 1.0e-6 I get the following energies for H2O (errors should be within a few micro-Hartree):

SVWN5: -75.913556 au SPW92: -75.910780 au

With run = false I get energies in the order of -75.85...

But yes, we are using the XCFun library for functionals and we do not have access to xclib. However, we have verified identical energies down to nano-Hartree on atoms for most of the usual functionals (SVWN5, PBE, BLYP, PW92 etc.).

regards, Stig

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179?email_source=notifications&email_token=AADC3VUEVQJ3AMTW2W2ABNDP7N3O5A5CNFSM4GMMDDEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ4LRBQ#issuecomment-511228038, or mute the thread https://github.com/notifications/unsubscribe-auth/AADC3VUXSZPQG6O53WIYTITP7N3O5ANCNFSM4GMMDDEA .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[moritz-braun]

Dear Stig

I have now run a calculation for Ethane using mrchem and I get an agreement within 5.5 milli Hartree, mrchem giving mor binding.

Thus I am convinced that I now have comparable calculations.

It would also be interesting to compare densities between the different codes. As far as I have studied the source code of mrchem, there does not seem to be a provision for that yet!

Regards

Moritz

On Sun, Jul 14, 2019 at 9:15 PM Stig Rune Jensen notifications@github.com wrote:

Ok, I think I understand what's happening. The H2O test example doesn't do any SCF optimization. I think you will find the keyword

SCF { run = false }

in your input. This means that the total energy is computed directly using the initial guess orbitals, which is done in order to reduce the execution time for the test suite. If you just remove this keyword it should run properly.

With rel_prec = 1.0e-6 I get the following energies for H2O (errors should be within a few micro-Hartree):

SVWN5: -75.913556 au SPW92: -75.910780 au

With run = false I get energies in the order of -75.85...

But yes, we are using the XCFun library for functionals and we do not have access to xclib. However, we have verified identical energies down to nano-Hartree on atoms for most of the usual functionals (SVWN5, PBE, BLYP, PW92 etc.).

regards, Stig

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179?email_source=notifications&email_token=AADC3VUEVQJ3AMTW2W2ABNDP7N3O5A5CNFSM4GMMDDEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ4LRBQ#issuecomment-511228038, or mute the thread https://github.com/notifications/unsubscribe-auth/AADC3VUXSZPQG6O53WIYTITP7N3O5ANCNFSM4GMMDDEA .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com

[moritz-braun]

Dear Stig

is there a way to let mrchem flush the output as it is created to get an idea of the convergence etc.

Regards

Moritz

On Sun, Jul 14, 2019 at 9:15 PM Stig Rune Jensen notifications@github.com wrote:

Ok, I think I understand what's happening. The H2O test example doesn't do any SCF optimization. I think you will find the keyword

SCF { run = false }

in your input. This means that the total energy is computed directly using the initial guess orbitals, which is done in order to reduce the execution time for the test suite. If you just remove this keyword it should run properly.

With rel_prec = 1.0e-6 I get the following energies for H2O (errors should be within a few micro-Hartree):

SVWN5: -75.913556 au SPW92: -75.910780 au

With run = false I get energies in the order of -75.85...

But yes, we are using the XCFun library for functionals and we do not have access to xclib. However, we have verified identical energies down to nano-Hartree on atoms for most of the usual functionals (SVWN5, PBE, BLYP, PW92 etc.).

regards, Stig

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/MRChemSoft/mrchem/issues/179?email_source=notifications&email_token=AADC3VUEVQJ3AMTW2W2ABNDP7N3O5A5CNFSM4GMMDDEKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZ4LRBQ#issuecomment-511228038, or mute the thread https://github.com/notifications/unsubscribe-auth/AADC3VUXSZPQG6O53WIYTITP7N3O5ANCNFSM4GMMDDEA .

-- Prof M Braun Tel.:27-12-4298006/8027 Physics Department Fax.: 27-12-4293643 University of South Africa (UNISA) moritz.braun@gmail.com P.O. Box 392 0003 UNISA South Africa http://moritz-braun.blogspot.com