Co-array error

[JohnNichols]

Steve:

I am using some structures and I keep getting this 8363 error and I cannot see why.

Code enclosed in zip file.

Looks legal to me.

JMN

[IanH]

FortranFan wrote:

REAL64 from ISO_FORTRAN_ENV is as identifiable as (or as vague as!) REAL*8, but  the latter style is now NON_STANDARD, so unless someone can make it part of the standard again, it is better not to bring REAL*8, INTEGER*4, etc. into discussions other than for legacy purposes.

Note that it never was standard - it has always been an extension.

(A similar sort of syntax for specifying the length of character variables was standard and it has been made obsolescent.  Good riddance to it.  Why some want to bring it back is beyond me - they've had 25 years to sort that nonsense in their code out.)

Some definitions of the syntax TYPE*dd make it a synonym for the F90 kind specification (and then, like ifort specify that the value of the kind relates to the number of bytes).  Some compilers then allow remapping of kind values to different underlying kinds, so is the dd a byte specification or not?  Others specify that the thing after the * is the number of bytes directly (ifort goes a bit each way depending on the type - see complex), so presumably that's not affected by options changing how kinds map to the sort of real in use.  Others specify that the thing after the * is the number of equivalent storage units used by a character*1 variable.  The latter isn't quite the same as the number of bytes - perhaps it isn't common in the Fortran world but those who have migrated Windows code bases from "ansi" to "unicode" will appreciate how the assumption that a single character occupies a byte can go wrong very badly.

So the meaning of that specification is not perhaps as clear cut as it may seem.

The numbers in that form of specification also look very much like embedded magic numbers in code.  As a guideline (not a rule) embedded magic numbers should probably be avoided. 

(That's particularly the case for something like the non-unity length specification of a character variable - which is something that often changes over the life of a code - hence I find the obsolescent character length specification particularly odious.)

[JohnNichols]

Thank you for the last three posts.

So this is legal

integer(kind = selected_real_kind(15, 307)), parameter :: dp = selected_real_kind(15, 307)

Weird but legal. I understand the different points, the main issue is of course that PARDISO asks for specific kinds, so it is necessary to make sure they align, which can be done with selected real kind as long as you actually know the matches. In trying to satisfy the comment by Steve about selected_real_kind and selecting 15,307 I created a small firestorm.  Pure ignorance, but now I know.

k1 is the concentration of chemicals in the pipes, Rossman developed code for the EPA to estimate the growth and or death rate of contaminants and used k1 as the starting concentration.  I am still sorting out the hydraulic part, the best hydraulic method is Darcy Weisbach, but the original code used Hazen Williams and so I wanted to stick to the one where I had an answer set until I had confidence in the results. I am now confident of the result. DW is next.

So k1 was not used in the analysis, it is a place holder for future parts of the program. But it is fixed.

JMN

Finally - the speed difference - in speed terms C# is managed code with all the speed problems this brings, in this case mecej4 is right - Fortran is faster. It is worth the port.

JMN

[Steven_L_Intel1]

John Nichols wrote:

So this is legal

integer(kind = selected_real_kind(15, 307)), parameter :: dp = selected_real_kind(15, 307)

Well, "legal" in the syntactic sense, but wrong. You're declaring an INTEGER using a kind intended for use in a REAL declaration. That it happens to work is a coincidence in that 8 is a valid kind in our implementation for both integer and real.

Typically you would not change the kind of a parameter constant declared like this, leaving it as default integer.