From: Ira Baxter on 18 Jun 2010 12:08 "Lynn McGuire" <lmc(a)winsim.com> wrote in message news:ANKdnaz_stuFo4TRnZ2dnUVZ_jidnZ2d(a)supernews.com... >>> Uh yes, sure. All 300,000 of them. While differentiating >>> the ones that need to maintain their values between subroutine >>> calls. >> >> I do wonder how hard it would be to write a program to read >> the source, and then insert the appropriate DATA statements >> to zero and SAVE all such variables. Somewhat easier for >> variables that already have a declaration. > > I have no idea which are the 100 of the 300,000 variables that > we need to save between the subroutine calls. That is the > tough part. Otherwise the init to zero data statements are a > simple perl script. > > The determination of the 100 (or 1000, I really have no idea) > will require removal of the global save command and then massive > testing ... and then determination of what went wrong in some > weird part of one of our nonlinear solvers. Some very tough > work ! > > Thanks, > Lynn This requires whole-program analysis and transformation. There are tools that can do this. The DMS Software Reengineering Toolkit (see http://www.semanticdesigns.com/Products/DMS/DMSToolkit.html) is one of them. It is general purpose program transformation machinery, parameterized by explicit langauge definitions. We have defined langauges such as C, C++, COBOL, PLSQL, Java, C#, for DMS... and have a definition for F77 and F95. (See http://www.semanticdesigns.com/Products/FrontEnds/FortranFrontEnd.html). We have done mass analysis on C applications of some 25 million lines, 250,000+ functions. These anlaysis include data flow analysis; what is needed here is data flow analysis from variables to points of consumption where it is clear the variables are uninitialized. The transformation is to then insert initialization code for such variables (in this case, zeroing). Fortran is easier than C :-} Don't get me wrong, this isn't an afternoon's exercise. But at this kind of scale, doing it by hand is painful and errorprone. -- IDB
From: Lynn McGuire on 24 Jun 2010 12:37 > Does anyone have experience with moving a large code set from > a f77 compiler (open watcom f77) to a modern day fortran 2003 > compiler such as IVF ? I am interested in speeding up the code > execution. This is double precision floating point bound code > (from our testing in the past). For those who are interested, we approached this another way. I had one of my guys add an isothermal flash cache to our general flash. The result was that our benchmark execution time went from 3:15 hours to 1:35 hours. I was amazed ! Thanks for the input, Lynn
From: dpb on 25 Jun 2010 09:16 Lynn McGuire wrote: .... > had one of my guys add an isothermal flash cache to our general > flash. ... In a quick moment before heading to fields... I have no clue what you just said??? --
From: Lynn McGuire on 25 Jun 2010 11:54 >> had one of my guys add an isothermal flash cache to our general >> flash. ... > > In a quick moment before heading to fields... > > I have no clue what you just said??? Our software has a large thermodynamic calculation engine built into it. An isothermal flash is performed at a given temperature and a given pressure. Given a certain amount of components in a mixture (water, methane, ethane, propane, butane, pentane, carbon dioxide, hydrogen sulfide, etc - up to 1,000 components), we will calculate how much of each component is in the vapor phase, the hydrocarbon liquid phase and the aqueous liquid phase. So anyway, we save the results of the calculations now. If the flowsheet wants to make the same exact calculation again, we already have it saved. Apparently saves a lot of time ! Thanks, Lynn
From: Colin Paul Gloster on 25 Jun 2010 12:45
On Thu, 24 Jun 2010, Lynn sent: |----------------------------------------------------------------| |"> Does anyone have experience with moving a large code set from| |> a f77 compiler (open watcom f77) to a modern day fortran 2003 | |> compiler such as IVF ? I am interested in speeding up the code| |> execution. This is double precision floating point bound code | |> (from our testing in the past). | | | |For those who are interested, we approached this another way." | |----------------------------------------------------------------| Dear Lynn, Just to clarify: are you staying with Open Watcom F77 and not trying to port to Fortran 2003? I was awaiting reports of differences in speed with the Fortran 2003 version. Ah , well. |----------------------------------------------------------------| |" I | |had one of my guys add an isothermal flash cache to our general | |flash. The result was that our benchmark execution time went | |from 3:15 hours to 1:35 hours. I was amazed ! | | | |Thanks for the input, | |Lynn" | |----------------------------------------------------------------| An old technique, but if it works it works! Yours sincerely, Colin Paul Gloster |