compilation problem etsf

Asked by sylvian

I got this stuff

gfortran -I. -I../includes -I./wavelib -I../libABINIT/src -I/usr/include -I/usr/include -I/usr/include/mpich -g -O2 -c -o plotting-etsf.o `test -f 'wavelib/plotting-etsf.f90' || echo './'`wavelib/plotting-etsf.f90
wavelib/plotting-etsf.f90:146.12:

  spnames = f_malloc(at%astruct%ntypes,id='spnames')
            1
Error: Can't convert TYPE(malloc_information_all) to CHARACTER(1) at (1)
wavelib/plotting-etsf.f90:164.22:

  call f_free(spnames)
                      1
Error: There is no specific subroutine for the generic 'f_free' at (1)
make[3]: *** [plotting-etsf.o] Error 1

bigdft 1.7.7; etsf-1.0.4; ubuntu 14; gfortran 4.8

Question information

Language:
English Edit question
Status:
Solved
For:
BigDFT Edit question
Assignee:
No assignee Edit question
Solved by:
Luigi Genovese
Solved:
Last query:
Last reply:
Revision history for this message
Luigi Genovese (luigi-genovese) said :
#1

Dear Sylvian,

it is possible that the ETSF support was broken during the migration to 1.8 version. there are two solutions:

1) You correct the indicated lines into

 spnames = f_malloc_str(len(spnames),at%astruct%ntypes,id='spnames')

call f_free_str(len(spnames),spnames)

2) you try to compile with the latest version and see if you encounter the same problem.

Do not hesitate

Many thanks

Luigi

Revision history for this message
sylvian (sylviankahane) said :
#2

Hi

Thanks. I corrected and thus routine compiled. But it seams that there are
additional problems in all the etsf routine that appear one by one. (I had
problems that I dont remember with v. 1.8 and prefer to stick with 1.7.7).
The new problems are here:

gfortran -I. -I../includes -I./wavelib -I../libABINIT/src -I/usr/include
-I/usr/include -I/usr/include/mpich -g -O2 -c -o i-o-etsf.o `test -f
'wavelib/i-o-etsf.f90' || echo './'`wavelib/i-o-etsf.f90
wavelib/i-o-etsf.f90:208.34:

      logrid_c = f_malloc((/ 0.to.n1, 0.to.n2, 0.to.n3 /),id='logrid_c')
                                  1
Error: Unknown operator 'to' at (1)
wavelib/i-o-etsf.f90:208.43:

      logrid_c = f_malloc((/ 0.to.n1, 0.to.n2, 0.to.n3 /),id='logrid_c')
                                           1
Error: Unknown operator 'to' at (1)
wavelib/i-o-etsf.f90:208.52:

      logrid_c = f_malloc((/ 0.to.n1, 0.to.n2, 0.to.n3 /),id='logrid_c')
                                                    1
Error: Unknown operator 'to' at (1)
wavelib/i-o-etsf.f90:209.34:

      logrid_f = f_malloc((/ 0.to.n1, 0.to.n2, 0.to.n3 /),id='logrid_f')
                                  1
Error: Unknown operator 'to' at (1)
wavelib/i-o-etsf.f90:209.43:

      logrid_f = f_malloc((/ 0.to.n1, 0.to.n2, 0.to.n3 /),id='logrid_f')
                                           1
Error: Unknown operator 'to' at (1)
wavelib/i-o-etsf.f90:209.52:

      logrid_f = f_malloc((/ 0.to.n1, 0.to.n2, 0.to.n3 /),id='logrid_f')
                                                    1
Error: Unknown operator 'to' at (1)
wavelib/i-o-etsf.f90:293.7:

   use internal_etsf
       1
Fatal Error: Can't open module file 'internal_etsf.mod' for reading at (1):
No such file or directory
make[3]: *** [i-o-etsf.o] Error 1
m

On Tue, Nov 8, 2016 at 12:37 AM, Luigi Genovese <
<email address hidden>> wrote:

> Your question #403866 on BigDFT changed:
> https://answers.launchpad.net/bigdft/+question/403866
>
> Status: Open => Answered
>
> Luigi Genovese proposed the following answer:
> Dear Sylvian,
>
> it is possible that the ETSF support was broken during the migration to
> 1.8 version. there are two solutions:
>
> 1) You correct the indicated lines into
>
> spnames = f_malloc_str(len(spnames),at%astruct%ntypes,id='spnames')
>
> call f_free_str(len(spnames),spnames)
>
> 2) you try to compile with the latest version and see if you encounter
> the same problem.
>
> Do not hesitate
>
> Many thanks
>
> Luigi
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/bigdft/+question/403866/+confirm?answer_id=0
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/bigdft/+question/403866
>
> You received this question notification because you asked the question.
>

--
Sylvian (gmail: <email address hidden>)

Revision history for this message
Luigi Genovese (luigi-genovese) said :
#3

THe operator .to. comes from use association of the "dynamic_memory" module.
Try by putting the line

use dynamic_memory

where appropriate.
Another possiblity is to switch off etsf support in the configure line.

I advise you to rather post here the problem you may have with version 1.8.
Older version are no longer maintained and new features are developing.

Many thanks

Luigi

Revision history for this message
sylvian (sylviankahane) said :
#4

Hi Luigi

I want the wavefunctions (actually I want them in the momentum space) so I
dont think I can dispense with etsf.

I put in the
        use dynamic_memory
and also
        use locregs, only : deallocate_wfd

all the routines compiled OK but there is a problem at the link stage:

libbigdft-1.a(i-o-etsf.o): In function `deallocate_local':
/mnt/d/WUBUNTU/APPS/bigdft-1.7.7/src/wavelib/i-o-etsf.f90:705: undefined
reference to `deallocate_bounds_'
collect2: error: ld returned 1 exit status

actually there is a deallocate_bounds routine in the locregs module but it
is commented out fully. Can I decomment it with no harm ?

On Tue, Nov 8, 2016 at 9:58 AM, Luigi Genovese <
<email address hidden>> wrote:

> Your question #403866 on BigDFT changed:
> https://answers.launchpad.net/bigdft/+question/403866
>
> Status: Open => Answered
>
> Luigi Genovese proposed the following answer:
> THe operator .to. comes from use association of the "dynamic_memory"
> module.
> Try by putting the line
>
> use dynamic_memory
>
> where appropriate.
> Another possiblity is to switch off etsf support in the configure line.
>
> I advise you to rather post here the problem you may have with version 1.8.
> Older version are no longer maintained and new features are developing.
>
> Many thanks
>
> Luigi
>
> --
> If this answers your question, please go to the following page to let us
> know that it is solved:
> https://answers.launchpad.net/bigdft/+question/403866/+confirm?answer_id=2
>
> If you still need help, you can reply to this email or go to the
> following page to enter your feedback:
> https://answers.launchpad.net/bigdft/+question/403866
>
> You received this question notification because you asked the question.
>

--
Sylvian (gmail: <email address hidden>)

Revision history for this message
Best Luigi Genovese (luigi-genovese) said :
#5

If it is commented there should (have) be(en) a reason.
Grep the sources to see which is the module which should be loaded instead. It should be easy.
THe wavefunctions could have been obtained in binary form and then converted in cube format by using BigDFT-tool, but as soon as you use ETSF procedure there should be no problem.

Best

Luigi

Revision history for this message
sylvian (sylviankahane) said :
#6

There is no other place where deallocate_bouns is defined. Only in locregs where is commented out. On the other hand there is a call to deallocate_bouns in other place in the program and it is commented out. So I will try to comment it out also in i-o-etsf.