Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!
26748 Discussions

Compatibility of Intel with the classe destroyer and with pointers

Maïté_G_
Beginner
170 Views

I am currently using an open-source code called bspline and available here : https://github.com/jacobwilliams/bspline-fortran.

This code is compiled with GFortran. When I try to compile it with Intel Fortran (2015 version) I got some troubles with the compatibility of the destroyer class.

Is it available in the 2017 version or will it be available soon ?

 

Moreover, the use of pointer in Intel Fortran does not seem to work, for example with the "source":

   type typHOSSurf2Vol

        !!- HOS NWT surf2Vol Type
        type(typHOSNWT)             :: hosNWTSurf2Vol_

        !!- HOS Ocean surf2Vol Type
        type(typHOSOcean)           :: hosOceanSurf2Vol_

        !!- HOS Mesh Pointer
        class(typHOSMesh),allocatable :: ptrHOSMesh_

    end type

      if (this%HOSSolver_.eq."NWT") then
                allocate(this%ptrHOSMesh_, source =this%hosNWTSurf2Vol_%hosMesh_)
            else if (this%HOSSolver_.eq."Ocean") then
                allocate(this%ptrHOSMesh_, source =this%hosOceanSurf2Vol_%hosMesh_)
            endif

where "this" is a class defined elsewhere.

 

Will it be available in a future version ?

Thanks a lot,

 

Maïté

0 Kudos
10 Replies
Steve_Lionel
Black Belt Retired Employee
170 Views

Please define "does not seem to work" and "some troubles". Also, attach a small but complete source that demonstrates the problem.

I note that your allocate statements have invalid syntax with a spurious right parenthesis after the item to be allocated.

Maïté_G_
Beginner
170 Views

Thanks for your response, and sorry about the invalid syntax, I corrected it in the previous post.
 

In the bspline_oo_module begins as:

    module bspline_oo_module

    use bspline_sub_module

    implicit none

    private

    integer,parameter :: wp = kind(1.0d0)       
    integer,parameter :: error_unit = 6

    integer,parameter :: int_size     = kind(1)       !! size of a default integer [bits]
    integer,parameter :: logical_size = kind(.true.)  !! size of a default logical [bits]
    integer,parameter :: real_size    = kind(real(1.0,wp))  !! size of a `real(wp)` [bits]

    type,public,abstract :: bspline_class
        !! Base class for the b-spline types
        private
        integer :: inbvx = 1  !! internal variable used by [[dbvalu]] for efficient processing
        integer :: iflag = 1  !! saved `iflag` from the list routine call.
        logical :: initialized = .false. !! true if the class is initialized and ready to use
        logical :: extrap = .false. !! if true, then extrapolation is allowed during evaluation
    contains
        private
        procedure,non_overridable :: destroy_base  !! destructor for the abstract type
        procedure,non_overridable :: set_extrap_flag !! internal routine to set the `extrap` flag
        procedure(destroy_func),deferred,public :: destroy  !! destructor
        procedure(size_func),deferred,public :: size_of !! size of the structure in bits
        procedure,public,non_overridable :: status_ok  !! returns true if the last `iflag` status code was `=0`.
        procedure,public,non_overridable :: status_message => get_bspline_status_message  !! retrieve the last status message
        procedure,public,non_overridable :: clear_flag => clear_bspline_flag  !! to reset the `iflag` saved in the class.
    end type bspline_class

    abstract interface

        pure subroutine destroy_func(me)
        !! interface for bspline destructor routines
        import :: bspline_class
        implicit none
        class(bspline_class),intent(inout) :: me
        end subroutine destroy_func

        pure function size_func(me) result(s)
        !! interface for size routines
        import :: bspline_class
        implicit none
        class(bspline_class),intent(in) :: me
        integer :: s !! size of the structure in bits
        end function size_func

    end interface

etc ...

the error is : "

        procedure(destroy_func),deferred,public :: destroy  !! destructor
                  1
Error: PROCEDURE(interface) at (1) is not yet implemented

 "

Do you have an idea how to fix it ?

Thanks,

 

Maïté

 

Steve_Lionel
Black Belt Retired Employee
170 Views

As you didn't include bspline_sub_module I cannot tell for sure, but I believe this code should compile in the 2017 version.

Maïté_G_
Beginner
170 Views

Thanks.

Please find the bspline_sub_module attached.

Steve_Lionel
Black Belt Retired Employee
170 Views

The original source needs the whole source, not an excerpt to compile, but from what you provided, I am confident that the 2017 version will compile it.

Johannes_Rieke
New Contributor III
170 Views

Hi  Maïté G., PSXE2017 update 4 compiles without any errors and test_oo.f90 runs fine. I recently tested at home with gfortran 7.1 successfully, too.

Nevertheless, you can avoid the OO interface and compile only 'bspline_sub_module.f90' and your desired program (e.g. 'test.f90'). This should work also with the older Intel compilers by loosing the nice OO approach.

Just change in 'test.f90' line 7 from

use bspline_module

to

use bspline_sub_module

Hopefully this helps. If not, Jacob Williams is very responsive I experienced.

Good luck, Johannes

Johannes_Rieke
New Contributor III
170 Views

Hi  Maïté G., I've seen that you had a second question hided into the other, which is not related to bspline but to HOS-ocean, HOS-NWT (https://github.com/LHEEA/HOS-ocean and https://github.com/LHEEA/HOS-NWT). If you like to get an answer to this 'class pointer' allocation related question I suggest you should detail this question. E.g. provide a minimum working example, which explains the issue, you encountered.

Maïté_G_
Beginner
170 Views

Hi Johannes, Thanks a lot for your answers.

Regarding the pointers, when using the "source=" in this code :

 type typHOSSurf2Vol

        !!- HOS NWT surf2Vol Type
        type(typHOSNWT)             :: hosNWTSurf2Vol_

        !!- HOS Ocean surf2Vol Type
        type(typHOSOcean)           :: hosOceanSurf2Vol_

        !!- HOS Mesh Pointer
        class(typHOSMesh),allocatable :: ptrHOSMesh_

    end type

      if (this%HOSSolver_.eq."NWT") then
                allocate(this%ptrHOSMesh_, source =this%hosNWTSurf2Vol_%hosMesh_)
            else if (this%HOSSolver_.eq."Ocean") then
                allocate(this%ptrHOSMesh_, source =this%hosOceanSurf2Vol_%hosMesh_)
      endif

with the hosMesh_ being either:

        type(typHOSNWTMesh),public :: hosMesh_

or 

       type(typHOSOceanMesh),public :: hosMesh_

we obtain this error:

Error 1 error #8152: Neither the ERRMSG= variable nor any part of the source expression in SOURCE= or MOLD= specifiers may be allocated in the ALLOCATE statement in which it appears.   [THIS] C:\Grid2Grid\src\modSurf2Vol.f90 148

As if we can not point on the Ocean or NWT version...?

Jacob_Williams
New Contributor I
170 Views

FYI: bspline-fortran compiles fine with the latest Intel compiler (2017). I don't know about 2015, I don't think I have that one installed anymore. And yes, if you don't care about the object-oriented interface, you can just compile it with only the subroutine interface. If you have any further difficulties, please submit a ticket at the GitHub site.

Maïté_G_
Beginner
170 Views

Thanks for all your answers.

Reply