cp2k results info

[Tobias Burnus]

Hi,

Jerry DeLisle wrote:
> This is the first time I have got this going.  The failed tests appear
> to be related to :
>   *** The memory deallocation for the data object       ***
>  *** <particle_set(iparticle)%list_exclude_vdw> failed ***
I checked the values in particle_types's allocate_particle_set:
         IF (ASSOCIATED(particle_set(iparticle)%list_exclude_vdw, &
                        particle_set(iparticle)%list_exclude_ei)) THEN
            print *, 'DEBUG: in if1 '
            print *, 'DEBUG:
assoc(particle_set(iparticle=',iparticle,')%list_exclude_vdw): ', &
                          
associated(particle_set(iparticle)%list_exclude_vdw)
            print *, 'DEBUG:
assoc(particle_set(iparticle=',iparticle,')%list_exclude_ei): ', &
                          
associated(particle_set(iparticle)%list_exclude_ei)
            flush(6)
            DEALLOCATE(particle_set(iparticle)%list_exclude_vdw,STAT=istat)

Result:

ASSOCIATED(particle_set(iparticle)%list_exclude_vdw, &
                        particle_set(iparticle)%list_exclude_ei)

is .TRUE. (otherwise one couldn't end up in the loop) and
associated(particle_set(iparticle)%list_exclude_*) is .FALSE.
That then deallocate returns istat == 1, which triggers the abort error
condition in CP2k, shouldn't be a surprise.

The following patch works for me:

Index: libgfortran/intrinsics/associated.c
===================================================================
--- libgfortran/intrinsics/associated.c (Revision 119960)
+++ libgfortran/intrinsics/associated.c (Arbeitskopie)
@@ -39,6 +39,8 @@
 {
   int n, rank;

+  if (GFC_DESCRIPTOR_DATA (pointer) == NULL)
+    return 0;
   if (GFC_DESCRIPTOR_DATA (pointer) != GFC_DESCRIPTOR_DATA (target))
     return 0;
   if (GFC_DESCRIPTOR_DTYPE (pointer) != GFC_DESCRIPTOR_DTYPE (target))


>  *** ERROR in libint_interface:initialize_libint processor      0 ***
>  ***  libint required, but CP2K not linked against libint ***
Joost has written that this is because libint needs ISO_C_BINDING and
can thus be ignored.

  * * *

By the way, does anyone know the status of the ISO_C_BINDING project?

FX has created the fortran-experiments branch in GCC for this project on
the first December, but no news since then. I know that he and Chris
wanted to coordinated the merge into that branch, but I don't know
whether Christ has finished updating his version to the trunk nor how
they plan to proceed.

I personally, would not mind to have first a working module (i.e. having
access to all the constants) and having only later the full support; but
this might break some configure checks which only check whether using
module works.

Tobias