From: Ira Baxter on

"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
> 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
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
>> 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
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