Issue wih cmake sources

[Crivella]

I was trying to compile d3q via the QE cmake, first problem for which i will open an issue on the QE repo is that they are pointing to a very old commit where function definitions were different.

After manually updating the commit to pull the latest one I encountered a second problem:

I had to manually edit the CMakeLists.txt file by adding minpack/ in front of the sources at lapackified/chkder.c

Not sure if there is a better way/flag that will already resolve this or if this should be fixed

[paulatz]

Thank you Davide, this library is a bit of a pain to compile, however but you do not need it unless you want to use the TDPH code (fitting for constants to molecular dynamics). I'll try to fix it in a permanent way cheers

[ye-luo]

@paulatz it seems that the current issue is only missing files or incorrect path in CMakeLists.txt. Could you fix that?

[paulatz]

Thank you Ye Luo, there is problem is deep in the minpack code, which requires some "fortran passing function pointer to c back to fortran" which I have only managed to make it work with intel fortran. Note that it is a good reason to keep cmakelist ou of date, but I have been dragging my feet trying to decide how to ship a code that compiles reliably. cheers

[ye-luo]

Thank you Ye Luo, there is problem is deep in the minpack code, which requires some "fortran passing function pointer to c back to fortran" which I have only managed to make it work with intel fortran. Note that it is a good reason to keep cmakelist ou of date, but I have been dragging my feet trying to decide how to ship a code that compiles reliably. cheers

Is this a linking issue or failure at run? So far I have no issue compiling with GNU but I assume d3q/minpack/distributed is not activated in CMake.

[paulatz]

It's only activated if you compile with scalapack support, it used to not compile at all with my version of gfortran. Apart from that, the d3q version which I have uploaded a few minutes ago seems to compile with both make and cmake

[ye-luo]

It's only activated if you compile with scalapack support, it used to not compile at all with my version of gfortran. Apart from that, the d3q version which I have uploaded a few minutes ago seems to compile with both make and cmake

I see. We don't activate scalapack in D3Q when building inside QE. Due to the removal of a function in upstream QE, need a last minute change https://github.com/anharmonic/d3q/pull/16

[ye-luo]

Curious, what version of gfortran were you using?

[paulatz]

I'm not sure, the one that came with Ubuntu 20.04 I guess, which is 11. There is no need to do last minute changes, as the specific parallel features are only use in a very specific code which not even completely documented yet. I'm adding an if() in CmakeList to use the correct library depending on the scalapack activation, but I get some error about plmdif_c0 not being available (both the subroutine and its USE are included in ifdef __SCALAPACK, should be ok)

[ye-luo]

I'm not sure, the one that came with Ubuntu 20.04 I guess, which is 11. There is no need to do last minute changes, as the specific parallel features are only use in a very specific code which not even completely documented yet. I'm adding an if() in CmakeList to use the correct library depending on the scalapack activation, but I get some error about plmdif_c0 not being available (both the subroutine and its USE are included in ifdef __SCALAPACK, should be ok)

I see. The distributed case can be dealt with later. I was referring to the removal of remove_stack_limit calls in #16 as the last minute change.

[paulatz]

Ok, no problem than. As long as SCALAPACK is not used it should be fine, and I have removed TDPH from default compilation, which should prevent these errors