Magni, Students and an interesting FORTRAN feature.

[JohnNichols]

write(st,250)ntanks, nid, nid1,iflag1
250         Format("Tank Number B :: ", i5, "  Node Number :: ",i5,"  Actual Tank model number :: ",i5,"    Model and Actual are not the same. FLAG set to ::  ",i5)

By mistake I left out the last i5 and the write statement is duplicated up until the end of the first i5, should this not be an error in FORTRAN.

@mecej4 I now have a class I am teaching about water supply modelling - in a simple fashion to show them how to manage facilities.  I gave the class a simple model and they are changing the pipe diameters to get acceptable residual pressures.   The things they have not been taught is interesting.  

So I could see the problems they are having I downloaded the Richmond Water Supply Model from Exeter and translated the EPANET to MAGNI.  

But the significant problem I am now solving is that the tank numbers need to match the assigned model numbers, we renumbered the model from 1 to n but in the the real world people use 1 : n, n+ 100 etc and this causes interesting problems with the tanks. 

I am working through it to add more checking and to fix these interesting errors.  

The real problem is protecting the Fortran code from the users. 

[mecej4]

"By mistake I left out the last i5 and the write statement is duplicated up until the end of the first i5, should this not be an error in FORTRAN?"

Not at all.

By design, in Fortran I/O lists and format strings interact in such a way that large tables of data can be read in easily. The rules for (1) the match-up between format specifiers and elements of the I/O list, as well as (2) what happens if the string is used up when there are still items remaining to be processed in the I/O list, or (3) the I/O list is finished but the format string still contains some not-yet-used edit descriptors -- these are covered in Fortran books and manuals.

Regarding the other question -- using arbitrary names of numbers rather than packed sequence numbers to label items in collections such as node names, line names, etc.: it is often better for the computational program to use simple and strict ordinal numbering, and to provide a short preprocessing program to read a user-prepared data file with "convenience labels", and to output a file with those replaced by sequence numbers, and this intermediate file can be used as input to the computational program.

[JohnNichols]

In regards to the last question, the excellent changes you made to MAGNI a few years ago follow that procedure. 

However I had always used tanks on very low numbered nodes and always consecutive but the Richmond Model has up to 990 node number but the small variant I am using has only 142 real nodes.  A high numbered node for a tank is causing some interesting output issues and so I am trying to prove the final answer is correct for this little section and also adding a deal of further checking to make it easier for students. and myself to understand the output. 

The interesting element is if there is a branch line that terminates with out a flow -- then the program starts giving infinities, so I am doing what is normally observed and putting a constant low leakage at all nodes, Kuczera developed a similar technique for a linear programming water analysis program that has very small pipes to duplicate the larger pipes - it worked a treat.   I enclose his work by a master student from '94  -- I made a few minor changes as I tried to understand the method. 

I should be able to upload MAGNI by late tomorrow -- I would like it to be working before we look at pumps.  

[andrew_4619]

Point of order Mr Chairman, Fortran not FORTRAN

[mecej4]

Mr. Chairman, here is evidence to support my point:

[jimdempseyatthecove]

I believe there was a misprint on the cover of that manual..

IBM should have read as Ibm

To keep things consistent.

Jim Dempsey

[andrew_4619]

But Jim, IBM is an abbreviation, ForTran would be a contraction ...... Fortran would be a noun. 

[jimdempseyatthecove]

And, I've seen manuals titled as FORTRAN.  (FORTRAN D, and FORTRAN II)

According to the rules of the language, it is case insensitive (as well as white space)

f OR t rAN

would be acceptable

Jim Dempsey

[JohnNichols]

Dear Chairperson:

I would note Ms Chairperson that the company has adopted a gender neutral policy for all communications. 

I accept the points made by my august company friends, however I am unaware of the Style guide adopted by the company. For instance the book title in the picture is all caps. 

If you could let me know the Style Guide I can then determine the company accepted standard. 

I well remember our recent discussion on the Chicago Style Guide, but I still personally prefer Fowler's and as I noted Fowler's is one of the 6 references in the CSG. 

JMN

[Steve_Lionel]

Regarding the FORMAT issue, I covered this in Doctor Fortran in "Revert! Revert! The End (of the format) is Nigh!" - Doctor Fortran (stevelionel.com)

[JohnNichols]

Dear Chairperson:

We must again ask the simple question Nigh or nigh?

Although the article is excellent, unlike the article I am currently reviewing for a journal. 

I mean if the end is nigh, and we are looking at multiple ICBM's on the horizon then Meryl Streep could exclaim to Tom Hanks "Nigh" and make it believable, otherwise?

I listened to an interesting BBC4 radio show on the first man in space - the guy who invented the ICBM rockets really wanted space rockets he just used another budget to achieve his purpose - the instructions to the first man in space == do not touch anything.  And based on previous results his chance of survival was 25%. 

JMN

[JohnNichols]

@mecej4 I am just trying to get through MAGNI and make sure I trap all the errors so they do not cause weird output.  One never finds them all, but it has been a fun three days. 

do i = 1,5
        if(spipes(npipes)%n1 .eq. 0) then
            Write(*,160)npipes, spipes(npipes)%n1
160         format('   Undefined node in pipe : ',I6,' Number given is ',I6)
            stop
        endif
        if(spipes(npipes)%n2 .eq. 0) then
            Write(*,160)npipes, spipes(npipes)%n2
            stop
        endif
        if(adjc(spipes(npipes)%n1, 5) .ne. 0)then

        endif
        if(adjc(spipes(npipes)%n1, i) .eq. 0) then
            if(flag .eq. 0) then
                adjc(npipes,i) = spipes(npipes)%n2
            endif
            flag = 1
        endif
    end do

In magni - you introduced this code, which appears to check that there are not more than 5 nodes connected to another node, which is more than adequate, but am I reading it correctly. 

The input file Foster - I gave the students I am now finding errors as I run the new checks with stops.  I am trying to put in a pump. 

The input file RICH04 is a short version of the Richmond Water Supply  model from Exeter Uni -- it appears to run nicely. 

The main constraints relate to the topological model, it does have some limitations on entry, otherwise it gives ***** with some output. 

So if you have nodes

112

114

113

in that input order 113 has a fit at the output and will not give you the heads. 

This is not a problem as it is now trapped.  Trying to read the original Richmond Model is a nightmare the numbers go all over the place and the tanks are numbered O,A,B,C,D,E

Thanks -- it is nice to using the model now and seeing some interesting stuff. 

[jimdempseyatthecove]

Your first three error test in the DO I loop are not dependent upon i? Why are they inside the loop>

Jim Dempsey

[JohnNichols]

Interesting question.  I did a bit of reading to look at the whole history of that segment of code. 

In 1988 I had two large water supply models of Tamworth and Armidale. We used a program called WATSYS to run the analysis - this program is still around in Australia and Max Old wrote it. 

I had to travel to Sydney ( whole day lost) for a single run - we had to get access to a mainframe and pay a lot for the day. 

The program I suspect used a variation on the Hardy Cross Method. 

BO    32     1
IN    10     2     8
IN    17     8    15
IN    24    15    22
IN    31    22    29
IN    37    29    36
IN    45    36    44
IN    52    44    51
IN    60    51    58
IN    68    58    66
IN    78    66    76
IN    90    76    87
IN   103    87    99
IN   116    99   111
IN   133   111   128
IN   156   128   151
IN   186   151   179
IN   221   179   213
IN   263   213   254
IN   316   254   305
IN   379   305   366
IN   454   366   438
IN   523   438   502
IN   600   502   571
IN   673   571   633
IN   739   633   693
IN   821   693   767
IN   914   767   850
IN  -922   850   776
IN  -830   776   701
IN  -747   701   646
IN    -9   646     1
IN     1     1     2

I got tired of running to Sydney and the limit on one run per day for a 2000 node model.  I was being charged out as a consultant at the time for 120 per hour so that added to the clients bills. 

Streeter and Wylie is a famous textbook from the 1960s and 70's for hydraulics and it included a simple HC solver written in Fortran.  So using my Compaq pc and MS Fortran I entered the code and then heavily modified it.  The problem with the HC solver is you need to establish the loops and the base model was in AutoCAD and I changed it with Auto LISP Programs.  So it was easy to write a LISP routine to generate the loops - example above.  So I have a large set of Auto LISP program for building and maintaining models -- you can do a lot with Auto LISP to find and fix errors that you cannot see on models built with simple drawing modules - aka EPANET.  

Rossman at the EPA wrote EPANET in the 90's in C and the drawing package in Delphi.  By this stage I was in academe and had put the modelling aside.   

I have no idea in 2014 why I suddenly got the old programs out and started to play with them, curiosity I suppose.  I dislike C and I do not like playing with other people's code.  By 2014 I was heavily into C# as it is the sole language of our main sensor and adding Fortran is a pain.  So for some reason, I cannot remember why I took Rossman's Algorithm and coded it in C# adding the interesting features from my other program.  I really dislike the EPANET Text files, they are not easily understood,  and you want a text format that can be created using an AutoLISP analysis of a drawing.  You permanently fix errors on the drawings and then you recreate the data files.  AutoLISP is much better at checking modelling errors with simple code,  whilst it is slow - you can run it overnight.  

So I got the new program called WSA running with MATHNET Solver, but it was slow and I looked around and the MKL Pardiso solver looked good.  In looking at the Forum posts it took a while to get it running, but it eventually worked, with INTEL's help on the mkl forum.   

@mecej4 opined that Fortran would be much faster than C#, I remember reading that late in the week and I set out to prove in him wrong.  WSA was only 2000 lines of C# code and it is really easy to translate from C# to Fortran.  Put the C# code into a Fortran module and then just fix the errors. 

By Monday it was running and it was twice as fast.  @mecej4 helped make it a lot better and wrote a lot of code for checking the model and he also kindly showed me how to write sparse to dense matrix routines for Pardiso.  So the code went from 2000 lines to 4000 lines with a lot of checking. 

I would often go and look at Rossman's code to see how they handled these errors, he has a simple error check, model will not handle this data file or words to that effect.  

I called the Fortran program Magni -- In Norse mythology, Móði (anglicized Módi or Mothi) and Magni are the sons of Thor. Their names translate to "Wrath" and "Mighty," respectively. Rudolf Simek states that, along with Thor's daughter Þrúðr ("Strength"), they embody their father's features.

The program is really good because of @mecej4  help.   But I got really busy with the European Project and put MAGNI to one side.  

I am now teaching a Facilities Management Class and decided to use a water supply model as one of the assignment.  It is easier to use MAGNI than try and teach them EPANET etc.. 

In getting the students to use MAGNI I had to teach them a lot of interesting stuff they should have learnt in high school and their first programming class.  They all learn Python and so text files etc are a mystery to them. 

When I handed out the assignment, I thought I had better do a simple but a bit harder problem so I could answer the questions and see what were the likely errors.  I can also go back to EPANET and see how they handled those errors.  

I downloaded the Richmond Water Supply model and started to play with the data.  It is not hard using EXCEL to translate EPANET models into MAGNI models, and it easy to draw the output into DXF.  

The RWS crashed the code a lot.  So I spent last weekend using a small set of the RWS model and working line by line through the magni code to see what needed to be fixed to pick up the errors.  Almost all are topological issues in graph theory. 

There is no way I have them all, but the program will now stop and tell you things it objects to. 

The other interesting challenge was tanks.  You might have a tank at node 1, 2 and 444 as the RWS model does. The original code was not handling the 444 node correctly in the output.  It took a while to find what was causing the problem and then solving it , it was interesting.  

it is reasonably easy when working through the code to determine who was the likely author and about when it entered the program. @mecej4 added a section of connectivity checks in 2014. I am sure that is part of that code.  I knew I did not write it - not my style and so I was intrigued with what it did, I think it checks that there are not more than 5 pipes connected at any node.  It was another interesting element in the connectivity check that failed to trap a really obscure modelling condition related to node number order that had let 444 through the system.  That actually took a few hours to work out the graph logic and then code it.  

So the answer is -- it is an oversight and I will correct it.  

But MAGNI is just for fun. 

JMN