- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Point of order Mr Chairman, Fortran not FORTRAN
- Tags:
- Pont of Order
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mr. Chairman, here is evidence to support my point:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I believe there was a misprint on the cover of that manual..
IBM should have read as Ibm
To keep things consistent.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
But Jim, IBM is an abbreviation, ForTran would be a contraction ...... Fortran would be a noun.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Regarding the FORMAT issue, I covered this in Doctor Fortran in "Revert! Revert! The End (of the format) is Nigh!" - Doctor Fortran (stevelionel.com)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Your first three error test in the DO I loop are not dependent upon i? Why are they inside the loop>
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page