“This is not a valid initialization expression” while using NULL() to initialize pointer

[Anas_E_]

Hello everybody,

In the module i'm writing, I'm using a module called FluidProp that uses DWINTY. I have seen on a help page that there are conflicts with the null statement, and that it could be resolved by writing 'USE DFWINTY, NULL0=>NULL' so that NULL and NULL0 can be used throughout the program. 

I am still getting the aforementioned error (This is not a valid initialization expression) when I write the suggested correction.

Here is what I'm typing to get the error:

TYPE :: steam_perfor_type
    CHARACTER(8):: name
    DOUBLE PRECISION    ::  TC, HRSG, BC, CC, Pdiff, error, Q, P_TC, P_CC
END TYPE steam_perfor_type 
TYPE(steam_perfor_type),TARGET :: steam_perform
TYPE(steam_perfor_type),POINTER :: perf=>NULL( )

Any help would be greatly appreciated.

[Anas_E_]

Sorry about that, I don't know how to edit my post:


Hello everybody,

In the module i'm writing, I'm using a module called FluidProp that uses DWINTY. I have seen on a help page that there are conflicts with the null statement, and that it could be resolved by writing 'USE DFWINTY, NULL0=>NULL' so that NULL and NULL0 can be used throughout the program. 

[Lorri_M_Intel]

What version of Intel Fortran are you using?  I tried the following program using both 14.0 and 15.0, and it compiled fine.

module lorri
use ifwinty, null0=>null
TYPE :: steam_perfor_type
    CHARACTER(8):: name
    DOUBLE PRECISION    ::  TC, HRSG, BC, CC, Pdiff, error, Q, P_TC, P_CC
END TYPE steam_perfor_type 
TYPE(steam_perfor_type),TARGET :: steam_perform
TYPE(steam_perfor_type),POINTER :: perf=>NULL( )
end module lorri

[Anas_E_]

I'm using the 13.1 version, and i'm having the same issue on the 11.1 version. I really don't understand what the problem is.

[Steven_L_Intel1]

I tried Lorri's code in 13.1 and had no problem. Please show us a complete (but small) source that demonstrates the problem.

[Anas_E_]

Alright, I actually managed to compile the module. I just created another module that would declare all of the derived types as well as my targets and the pointers, and that part runs smoothly. I think this issue snowballed into another one though, as I'm getting an error #6405 "The same named entity from different modules and/or program units cannot be referenced".

I'll just shorten the code from the actual project to show you what is going on:

MODULE membranedeclarations


TYPE :: steam_perfor_type
    CHARACTER(8):: name
    DOUBLE PRECISION    ::  TC, HRSG, BC, CC, Pdiff, error, Q, P_TC, P_CC
END TYPE steam_perfor_type  

TYPE(steam_perfor_type),TARGET :: steam_perform
TYPE(steam_perfor_type),POINTER :: perf=>NULL( )

END MODULE membrane declarations


MODULE cycle
USE membranedeclarations
USE components ! where values are stored
CONTAINS

SUBROUTINE call_design_point()

perf=> steam_perform
steam_perform%P_TC = P_GT*1e3_dp ! (kW)
steam_perform%TC = eta_GT

END SUBROUTINE call_design_point

Again I don't understand why it's not compiling. I'm really new to IVF and Fortran in general so I have issues resolving this kind of stuff by myself...

[mecej4]

The compiler usually gives specific information (error number, text of error, line number) regarding errors.

In the code snippet that you included in #6, there are three problems:

1. You have not told us anything about Module components; you should have included the source code for it.
2. The module name is not spelled consistently
3. Module cycle is missing an end module statement.

[jimdempseyatthecove]

The compiler is likely complaining that you have something like a subroutine with

USE A

USE B

where B (or something nested inside B) contains a

USE A

Fortran modules do not have a similar feature to C++'s #pragma use once, or the equivalent thing you do with #if !defined(A_H)

I would also suggest you have INCLUDE NONE in your subroutines and functions to weed out undefined variables. Your code snips did not have this, though your actual may have the INCLUDE NONEs.

Jim Dempsey

[Steven_L_Intel1]

Jim means IMPLICIT NONE, but I don't think that will help.

You didn't show us the complete error message, including the name of the symbol and the line where it complained. Just giving the message text is not sufficient.

Your attempt to work around the problem just created more issues. Can we go back to the original and you show us a complete source that illustrates the problem?

[Anas_E_]

Thank you everybody, I managed to solve this issue by  taking my time and simply cleaning up my code, as you guys pointed it out it was messy to say the least.