topic Quote:John Nichols wrote: in Intel® Fortran Compiler

Co-array error

JohnNichols — Thu, 02 Oct 2014 18:07:07 GMT

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

ZIP File

JohnNichols — Thu, 02 Oct 2014 18:08:17 GMT

ZIP File

I just added the interface

JohnNichols — Thu, 02 Oct 2014 18:15:33 GMT

I just added the interface and that did not help

It seems clear to me - SPIPES

Steven_L_Intel1 — Thu, 02 Oct 2014 18:23:16 GMT

It seems clear to me - SPIPES is not a coarray. In that routine, it's declared as:

type(SPIPE) spipes(100)

No cobounds are specified. It's not a coarray in the caller either.

So I passed the array through

JohnNichols — Thu, 02 Oct 2014 18:47:31 GMT

So I passed the array through the subroutine call -

does that mean I can read the elements of the array - but I cannot write to them,

I want to set spipes(I).a0 = 1,

but it gives me an error - 6383

I am really lost here

JMN

for array = type sorry

JohnNichols — Thu, 02 Oct 2014 18:48:09 GMT

for array = type sorry

Steve:

JohnNichols — Thu, 02 Oct 2014 18:57:42 GMT

Steve:

I copied the code over from C# and thought I had fixed it .

the spipes should be spipes(I)

missed the brackets

True or false?

[] indicates a co-array - whatever that is

JMN

Yes, that would be the

Steven_L_Intel1 — Thu, 02 Oct 2014 19:15:05 GMT

Yes, that would be the problem. In Fortran, [] indicates a coarray (or an array constructor).

I'll also comment that if

Steven_L_Intel1 — Thu, 02 Oct 2014 19:16:38 GMT

I'll also comment that if this is newly created code, you should be using a TYPE declaration and not the DEC STRUCTURE extension.

Steve:

JohnNichols — Thu, 02 Oct 2014 19:44:33 GMT

Steve:

I have the Microsoft Reference Manual 1991 for MSDOS Version 5.1 - it does not mention TYPES

JMN

Module Network

JohnNichols — Thu, 02 Oct 2014 19:50:56 GMT

Module Network

    Type SNODE
        integer ID
        integer Tank
        double precision X
        double precision Y
        double precision E
        double precision C0
        double precision Qbase
        double precision Cs
        double precision H
        double precision C
        double precision indDemand
        double precision parkDemand
        double precision leakDemand
        double precision resDemand
        double precision dumC
    end type

Like that you mean

That's better, but you should

Steven_L_Intel1 — Thu, 02 Oct 2014 20:41:42 GMT

That's better, but you should consider replacing "double precision" with something like "real(DP)" where DP is a PARAMETER constant defined using SELECTED_REAL_KIND. I'd add a kind for the integer components too.

Does your MS-DOS Fortran manual also include "module"?

Use % instead of . for component separators.

That's better, but you

JohnNichols — Fri, 03 Oct 2014 01:21:59 GMT

That's better, but you should consider replacing "double precision" with something like "real(DP)" where DP is a PARAMETER constant defined using SELECTED_REAL_ KIND. I'd add a kind for the integer components too.

OK - I can handle that one, I have done that before

Does your MS-DOS Fortran manual also include "module"?

No - it has structure and MAP in the blue colours they used to indicate cutting edge - what is really interesting is that it contains a lot of examples that one still finds in the Intel Help Files.

Use % instead of . for component separators.

I think whoever decided to use the % made a major error. (. ) works so I will use it.

This started out as a NIST proposal that included infrastructure work, I was looking at the EPANET program with a view to exchanging data between different models for disaster planning purposes. A not insignificant problem. I stumbled across a 1991 program in C that the EPA guy had first published. It did not have examples, merely the code, for the Gradient Method. I have the Hardy Cross already coded in Fortran, but with Australian WATSYS data format on the ASCII output files. Hardy Cross is a problem because of the topological issues. I also wanted to compare the results from the two model solvers.

I really hate C, once you have Lisped you would never C, it is just to crude.

But I thought I would take the program and code it, to see if I could solve the NIST problem, the problem of course is which of the matrix inversion routines to use, there are a multitude. The one in the C program was a straight Gaussian Elimination - aka Conte and de Boor. I also have very large models in AutoCAD format and I wanted to see if I could work with them directly so either C# or VB.

I stopped using BASIC when GWBasic died, never took to VB. So it was C#. But I wanted to use the MKL library routines. You sent my enquiry to the MKL forum and I had two suggestions from that one - one from Intel and one from mecej4. In hindsight I should have travelled with the mecej4 recommendation. He is really good.

I got the C program running in DEV CPP and could work out the algorithms, I coded it in C# and borrowed a inversion routine from Conte and de Boor, it is very old school but was cutting edge in 1979.

Then at INTEL's suggestion I tried PARDISO - I had problems with the interfaces, and could not get the ia, ja and A matrix to work, it was my fault in not understanding the need for the Fortran arrays to start with a zero index coded in. mecej4 solved that problem as he has solved several along the way (as you have to ). I was concerned that I had the algorithms correctly coded, so I used the MathNet inversion routines to check the code. (Those routines are not fast, but the interfaces are great).

The PARDISO routine is 100 times faster than the next fastest inversion routine I have tested. So it is worth using.

I spent a good deal of time getting a minimal set of error codes to work in the C# module to get one of the big models running, but when I moved to 24 hours analysis I hit a wall, mecej4 pointed out the basic error - which I should have spotted. He also commented it would be faster in Fortran.

So I bit the bullet and am coding it in Fortran, I am trying to stay as close as possible to the original so I can compare the timings etc, and because sticking with the single data format at the ASCII stage is important. I am about half way through the process, I had not used types before as most of my code dates from the 1980s and early 1990s. I left it alone for a long time when doing my PhD and getting tenure. But now I ma getting used to it.

It is interesting to code in Fortran again, and certainly Intel Fortran is a bonzer.

So that is why I have the odd question.

JMN

Quote:John Nichols wrote:I

IanH — Fri, 03 Oct 2014 01:46:44 GMT

John Nichols wrote:
I think whoever decided to use the % made a major error. (. ) works so I will use it.

You should instead blame the person that decided to use a period in things like .EQ. .

I really wouldn't use `.`.

JMN: Here is a fixed up

mecej4 — Fri, 03 Oct 2014 02:56:00 GMT

JMN: Here is a fixed up version that reads the input file with no error messages. The main changes:

Changed file unit numbers from your (1,2) to (11,12) to save you trouble later, possibly with other compilers.
Read input line into character array, which can then be read with different I/O lists depending on the first four characters. No need for backspacing if that approach is used.
Some READ statements had too many items in the list, causing more lines to be consumed on input than is correct.
Replaced double quote characters with single quote characters throughout
Replaced calls to nonstandard GETTIM and GETDAT routines by calls to standard intrinsic DATE_AND_TIME

I recommend that you replace the non-standard structures by Fortran 90 "derived types".

Otherwise, the code is ready for you to put in the routines that assemble the matrix.

character*4 AF

JohnNichols — Fri, 03 Oct 2014 15:20:27 GMT

        character*4 AF
  character*80 iline
  equivalence(AF,iline)

Dear Mecej4:

It took me a minute to find the connection, I have never used the equivalence statement.

So this is saying : the substring AF of four characters aligns with the first four characters in iline. neat.

I will fix the code. Thanks

JMN

If you wish to avoid

mecej4 — Fri, 03 Oct 2014 18:21:58 GMT

If you wish to avoid EQUIVALENCE, one way would be to declare

        character*4, pointer :: AF
        character*200, target :: iline

and pointer-assign AF:

         AF => iline(1:4)

at the beginning of the main program.

I do not wish to avoid it - I

JohnNichols — Fri, 03 Oct 2014 21:07:01 GMT

I do not wish to avoid it - I was commenting more on the aspect that I was unaware of the equivalence statement and should have searched a bit harder.

Pointers are not a great idea. equivalence is better, it is merely a shorthand for substring.

It is definitely a whole lot faster.

Thanks

JMN

Dear Steve:

JohnNichols — Mon, 06 Oct 2014 15:17:40 GMT

Dear Steve:

Ecclesiastes 3 tells us a lot about timing. It was an interesting weekend - I got to spend two days running gopher at a conference, toilet paper etc. I also spent my spare time playing with the Water Supply Analysis program. You had suggested last week that I needed to change the double precision and integer declarations to a more modern standard. So I did, but can I ask the following questions?

1. What is the default integer value in the Fortran compiler? I am assuming it is Integer*4?

2. Is it preferred to say Integer*4 or Integer (kind = 4) ?

I changed all of the integers to Integer(kind = 8), mecej4 commented that kind = 4 would be enough unless I had billions of nodes, no-one has billions of nodes in a water supply system, there is no way to check the data. I am not going to change back now.

I declared a dp parameter as a unit in the Network Module. I can then use the Network Module and use the dp as shown below: is this acceptable practice. But it appears that I have to use the network in every subroutine it is not enough to call it once in the main unit. Is this correct?

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

        integer(kind = 8) ID
        integer(kind = 8) :: Tank = -1
        real(kind=dp) X

Should I use the :: every time I declare variable or only if I want to set it to a value?

Does not the selected selected_real_kind(15, 307) really just default to 8 at this size? the local view page shows them as Real*8.

If I want all the arrays to be a consistent size, can I also declare a dimension in the Network Module and then use it where the arrays is called or do I pass the size of the array in the call to the subroutine? Both should work.

Finally, I was looking for a book that I had once read on the Isle of Skye (off the west coast of Scotland). I requested the book on Interlibrary loan and a different book than expected arrived at our library. I borrowed it, the book is an interesting history of the Island written in 1929, fair amount of geography and human culture included. But some rather blood thirsty stories as well. Would have been a heck of a place to live.

JMN

The default integer kind in

Steven_L_Intel1 — Mon, 06 Oct 2014 16:14:49 GMT

The default integer kind in Intel Fortran is 4. "integer*4" is non-standard syntax. "integer(4)" is standard, but good practice would avoid hard-coding kind numbers. Instead, define PARAMETER constants with a value from SELECTED_INT_KIND (or SELECTED_REAL_KIND as appropriate.) The reason to use these is for portability. Specific kind numbers are implementation-dependent.

The :: is optional if you don't have initialization or attributes.

If all your arrays are to be the same size, it would make sense to define a PARAMETER constant with this value in the module and use it in declarations.