• Re: converting a 700,000+ line Fortran 77 plus 50,000+ line C++ program

    From Jeff Ryman@21:1/5 to Lynn McGuire on Wed Oct 26 09:38:37 2022
    On Sunday, October 23, 2022 at 3:16:48 PM UTC-7, Lynn McGuire wrote:
    We are converting a 700,000+ Fortran 77 lines of code plus 50,000+ C++
    lines of code engineering software product to C++. With all that code,
    we produce four Win32 EXEs and three Win32 DLLs. My goal is to add four
    Win64 EXEs and three Win64 DLLs to the product with the same
    capabilities as the Win32 versions (console, windowed, Excel callable,
    Excel embeddable). Plus support for Unicode named files and Unicode
    file paths.

    I am using a customized version of f2c at the moment to automate 60% to
    80% of the conversion from F77 to C++. I have added support for
    logical*8, changed the output file from *.c to *.cpp, added an include
    for the Fable fem.hpp template library, removed the trailing underscores
    from the subroutine and common block names, removed the ftnlen arguments
    from the character arguments, converted all F77 comments to the //
    instead of the /* */, and a few other items. If desired, I am willing
    to post a copy of my modified f2c on my website with the source code. https://netlib.org/f2c/
    https://en.wikipedia.org/wiki/F2c

    f2c does not get me totally there. The Fortran character strings were
    poorly handled so they will probably needed fixing for proper sizing and alignment. The i/o code is crap so I take the original F77 i/o code and translate it by hand. The arrays in the argument list are still based
    at an index of one so I convert those to base index of zero by hand.
    All of the local and common block arrays were converted to a base index
    of zero by f2c. I add the new *.cpp file to my Visual Studio project.
    I then add the new function prototypes to my prototypes.h file and I add
    any new common block structures to my commons.h file. I then compile
    and fix until I get a clean compile.

    I have converted over 8,000 lines of F77 code to C++ now. Several dozen subroutines and several dozen common blocks. Most are compiling cleanly
    in Visual C++ 2015. My limited testing is working well and I will
    expand my testing when I hit 15,000 or 20,000 lines of F77 code
    converted. I hoping to get a complete build of the smaller of the Win32
    DLLs by the end of the year and a full build by next June. One of my programmers thinks that we will be lucky to get a complete build by late 2024.

    Lynn

    I'm not trying to be a smart ass or a troll and I'm not trying to change your mind.
    I'm wondering why you want to convert all of the F77 to C++ rather than to modern Fortran that can call or be called from the existing C++ routines.

    As a side note, I used to work for a group at Oak Ridge National Laboratory (ORNL) that developed the SCALE code system that is used for nuclear analysis. A lot of effort was spent many years ago converting it from F77 to Fortran 9x. Now, after addition of a number of computer science trained staff to that group over the years from the late 1990s to the present, everything is slowly being converted to C++. A number of the SCALE codes are being changed to run on massively parallel machines, but there are libraries for both Fortran and C++ available for such machines. I have my suspicions why they are converting but that is irrelevant here.

    Is there a reason such as availability of certain libraries or code efficiency that
    you want to convert all your F77 code to C++?

    The reason I am interested is that I have some old F77 code that ran on IBM mainframes, Unix workstations, and DOS PCs which I want to document and
    revive to run on Windows and Linux now that I am retired and have the time.

    I had a C/C++ class in the late 1990s but never used any of it at work. I am taking some online self study classes in C/C++ so that I can at least read a little of existing codes and use it in my project if I find it useful.

    Thanks for your consideration.

    Jeff

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to rym...@outlook.com on Wed Oct 26 12:55:31 2022
    On Wednesday, October 26, 2022 at 9:38:40 AM UTC-7, rym...@outlook.com wrote:
    On Sunday, October 23, 2022 at 3:16:48 PM UTC-7, Lynn McGuire wrote:
    We are converting a 700,000+ Fortran 77 lines of code plus 50,000+ C++ lines of code engineering software product to C++.
    (snip)

    I'm not trying to be a smart ass or a troll and I'm not trying to change your mind.
    I'm wondering why you want to convert all of the F77 to C++ rather than to modern Fortran that can call or be called from the existing C++ routines.

    I suspect that there are many different reasons, so no easy answer.

    As a side note, I used to work for a group at Oak Ridge National Laboratory (ORNL) that developed the SCALE code system that is used for nuclear analysis.
    A lot of effort was spent many years ago converting it from F77 to Fortran 9x.

    So, converting Fortran 66 style DO loops to DO/ENDDO, and IF to
    IF/THEN/ELSE? Or to array expressions instead of loops?

    That can make it a lot more readable, but not so much more.

    Does it also now use dynamically allocated memory?

    Now, after addition of a number of computer science trained staff to that group
    over the years from the late 1990s to the present, everything is slowly being converted to C++. A number of the SCALE codes are being changed to run on massively parallel machines, but there are libraries for both Fortran and C++ available for such machines. I have my suspicions why they are converting but that is irrelevant here.

    Well, one reason might be that there are more people interested in
    working on the C++ version. That is pretty much independent of the
    features and abilities of the languages.

    Is there a reason such as availability of certain libraries or code efficiency that
    you want to convert all your F77 code to C++?

    Some of the C++ libraries are likely already translation from Fortran.

    The reason I am interested is that I have some old F77 code that ran on IBM mainframes, Unix workstations, and DOS PCs which I want to document and revive to run on Windows and Linux now that I am retired and have the time.

    gfortran can easily run F77 code on any of those systems.

    Last year I had IBM's ECAP running on gfortran. That goes back to
    Fortran II days, though was translated to Fortran IV pretty far back.,

    There were a few complications in doing it, but not much.

    I also had Spice 2g6 running, the last of the Fortran Spice versions.

    I had a C/C++ class in the late 1990s but never used any of it at work. I am taking some online self study classes in C/C++ so that I can at least read a little of existing codes and use it in my project if I find it useful.

    If you aren't already into C or C++, not much reason to do it.
    Well, maybe as a reason to learn/improve your C++ skills.

    Otherwise, you can slowly convert to newer forms as you feel
    like it, and keep the old ones running as they are.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Lynn McGuire on Wed Oct 26 17:59:00 2022
    On Wednesday, October 26, 2022 at 1:56:09 PM UTC-7, Lynn McGuire wrote:

    (snip)

    We used three features in our F66 / F77 code which are turning out to be problematic in porting to a new Fortran compiler that supports 64 bit software. The first is the carriage control option in printing to
    stdout or a file. This was never a Fortran standard feature but
    everyone used it back in the 1960s, 1970s, and 1980s.

    It is in the Fortran 66 standard with "when formatted records are
    prepared for printing". For one, you could argue that not all are
    being prepared for printing, at least not in the Fortran 66 sense.

    For IBM OS/360 and successors, it is not part of Fortran but of
    the OS. If the DCB has RECFM=FBA you get them, if FB you don't.

    But the is reminding me of a Fortran to C port in about 1987.

    The C code had a tendency to write the '\n' at the beginning
    of a printf() call, instead of at the end. Sometime later, those
    all got fixed, but it was related to the way that Fortran I/O
    always starts on a new line, and C doesn't do that.

    This killed our
    port to gfortran several years ago but it is now supported there
    reputedly. We are ripping it out of our formats as a part of our
    conversion to C++.

    Well, the C/Unix tradition was to write '\f' (form feed characters)
    to the file. I always thought that seemed less standardized
    than ASA characters. Also, there is a Unix program to convert
    from ASA characters.

    In any case, yes, I always found ASA control characters funny
    when using interactive terminals for output devices. They are
    fine for line printers, though.

    (snip)
    Almost all of the Fortran compilers are now free. This is a bad sign, especially since Intel Fortran, the premier Fortran compiler, just
    jumped to free. To me, this says that future of Fortran is cloudy at best.

    Seems to me like web browsers are now always free. Pay ones can't
    compete with free ones.

    Nothing in this world is perfect but moving to a single programming
    language should help us in the long run. Our software is embeddable in
    Excel or can embed Excel in itself, all my glue code is in C++ which
    really points the direction to me.

    I think if I was in the mood for doing it, it would be Java and not C++,
    but then that is just me.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Lynn McGuire on Thu Oct 27 00:56:24 2022
    On Thursday, October 27, 2022 at 3:47:19 PM UTC+11, Lynn McGuire wrote:
    On 10/26/2022 7:59 PM, gah4 wrote:
    .
    I think if I was in the mood for doing it, it would be Java and not C++, but then that is just me.
    .
    Would you really write a 750,000 line calculation engine in Java ?
    .
    I think the question that you should be asking yourself is
    "would you really write a 750,000 line calculation engine in C++ ?"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to All on Thu Oct 27 00:53:06 2022
    On Thursday, October 27, 2022 at 11:59:02 AM UTC+11, gah4 wrote:
    On Wednesday, October 26, 2022 at 1:56:09 PM UTC-7, Lynn McGuire wrote:

    (snip)
    We used three features in our F66 / F77 code which are turning out to be problematic in porting to a new Fortran compiler that supports 64 bit software. The first is the carriage control option in printing to
    stdout or a file. This was never a Fortran standard feature but
    everyone used it back in the 1960s, 1970s, and 1980s.
    .
    That was never anything of significance in any version of Fortran.
    .
    It is in the Fortran 66 standard with "when formatted records are
    prepared for printing". For one, you could argue that not all are
    being prepared for printing, at least not in the Fortran 66 sense.

    For IBM OS/360 and successors, it is not part of Fortran but of
    the OS. If the DCB has RECFM=FBA you get them, if FB you don't.

    But the is reminding me of a Fortran to C port in about 1987.

    The C code had a tendency to write the '\n' at the beginning
    of a printf() call, instead of at the end. Sometime later, those
    all got fixed, but it was related to the way that Fortran I/O
    always starts on a new line, and C doesn't do that.
    .
    That was true for FORTRAN 77, but it is not true from Fortran 90.
    .
    This killed our
    port to gfortran several years ago
    .
    There was nothing in that that would have been cause for "killing"
    a port to gfortran.
    .
    but it is now supported there
    reputedly. We are ripping it out of our formats as a part of our
    conversion to C++.
    .
    Well, the C/Unix tradition was to write '\f' (form feed characters)
    to the file. I always thought that seemed less standardized
    than ASA characters. Also, there is a Unix program to convert
    from ASA characters.

    In any case, yes, I always found ASA control characters funny
    when using interactive terminals for output devices. They are
    fine for line printers, though.

    Almost all of the Fortran compilers are now free. This is a bad sign, especially since Intel Fortran, the premier Fortran compiler, just
    jumped to free. To me, this says that future of Fortran is cloudy at best.
    .
    An inappropriate conclusion.
    .
    Seems to me like web browsers are now always free. Pay ones can't
    compete with free ones.
    .
    Nothing in this world is perfect but moving to a single programming language should help us in the long run. Our software is embeddable in Excel or can embed Excel in itself, all my glue code is in C++ which
    really points the direction to me.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Lynn McGuire on Thu Oct 27 01:51:27 2022
    On Sunday, October 23, 2022 at 3:16:48 PM UTC-7, Lynn McGuire wrote:
    We are converting a 700,000+ Fortran 77 lines of code plus 50,000+ C++
    lines of code engineering software product to C++.

    As some other comments make me wonder, is this really C++,
    or is it more like C.

    That is, how many C++ features that are not in C are used.

    Many C++ programs do a lot of allocate/deallocate for a very
    short term. That is one reason people complain about the speed
    of C++ code. Not that it is necessary to do that, but some do.

    Now, since Fortran 77 doesn't do that, I suspect that your program
    doesn't, but just to be sure.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Thomas Koenig on Thu Oct 27 14:00:35 2022
    On 10/27/2022 1:21 PM, Thomas Koenig wrote:
    Lynn McGuire <lynnmcguire5@gmail.com> schrieb:

    We used three features in our F66 / F77 code which are turning out to be
    problematic in porting to a new Fortran compiler that supports 64 bit
    software. The first is the carriage control option in printing to
    stdout or a file. This was never a Fortran standard feature but
    everyone used it back in the 1960s, 1970s, and 1980s. This killed our
    port to gfortran several years ago but it is now supported there
    reputedly.

    I am not sure how compiler support of ASA carriage control
    by a compiler is supposed to look like (apart from the
    mandated leading space in free-form output).

    The traditional UNIX way is to pipe it through asa(1), which
    emulates the traditional carriage control with overstrike
    characters etc. This is reasonably easy to write, I once
    wrote such a utility myself (and lost the source) but Debian
    has it. Source at https://sources.debian.org/src/asa/1.2-1.1/ .

    We are ripping it out of our formats as a part of our
    conversion to C++.

    Good riddance.

    We use zero initialization of all global and local variables. This
    killed our first port to Intel Fortran in 2005 ??? when it uncovered a
    linker bug / crash. We have removed the need for this from a portion of
    our Fortran code but will be a problem in the C++ conversion.

    That is a bigger problem.

    Not sure if your code runs under Linux. If it does, you might want
    to run it under valgrind, which will generate tons of errors if
    undefined variables are used.

    We use Fortran structures, popularized by DEC back in the 1970s and
    1980s, but they never became part of the Fortran standard. We are
    converting our structure code to integer*8 and logical*8 as a part of
    the C++ port.

    Huh?

    Almost all of the Fortran compilers are now free. This is a bad sign,
    especially since Intel Fortran, the premier Fortran compiler, just
    jumped to free. To me, this says that future of Fortran is cloudy at best.

    Why should this be a bad thing? Intel uses the compiler to sell chips,
    and so does IBM for POWER.

    Nothing in this world is perfect but moving to a single programming
    language should help us in the long run. Our software is embeddable in
    Excel or can embed Excel in itself, all my glue code is in C++ which
    really points the direction to me.

    In the immortal words of a J3 member...

    " Hiring someone else to write your C++ code is probably a good
    idea for preserving sanity. Although having to read the code
    later will undo any of the previously mentioned benefits."

    Yeah, I ripped out the overstrike characters years ago. But when one
    has over 10,000 format statements, removing the carriage control
    character is a lot of work.

    My code ran fine using the old F77 compiler on Unix. So it should run
    fine if that compiler is available.

    Thanks,
    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Beliavsky@21:1/5 to Lynn McGuire on Thu Oct 27 12:52:43 2022
    On Wednesday, October 26, 2022 at 4:56:09 PM UTC-4, Lynn McGuire wrote:

    Almost all of the Fortran compilers are now free. This is a bad sign, especially since Intel Fortran, the premier Fortran compiler, just
    jumped to free. To me, this says that future of Fortran is cloudy at best.

    I disagree. The absence of free Fortran 90+ compilers until g95/gfortran
    slowed the adoption of modern Fortran and caused Fortran to lose market
    share, since Fortran 77, supported by the free g77, was not an appealing language.

    It's my impression that the commonly used C++ compilers are free ones --
    clang, g++, and Microsoft Visual C++, yet C++ is a very popular language.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Thomas Koenig on Fri Oct 28 02:24:03 2022
    On Thursday, October 27, 2022 at 11:21:05 AM UTC-7, Thomas Koenig wrote:

    (snip)

    I am not sure how compiler support of ASA carriage control
    by a compiler is supposed to look like (apart from the
    mandated leading space in free-form output).

    The Fortran 66 standard has space, 0, 1, +, for skip to the next line,
    next next line, next page, and stay on the same line.

    I don't know how they work in earlier IBM systems.

    For OS/360, you can have "machine carriage control", RECFM=FBM,
    where the first column is the actual channel command code.

    Unlike ASA, machine codes are print and then move, instead of
    move and then print. If you use ASA characters, the OS converts
    them at some point, before printing. Otherwise, any characters
    not on the print train print as blanks, including backspace, new
    line, carriage return, and line feed.

    As for Fortran programs, mostly it means 1X, at the beginning
    of most FORMAT strings.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Robin Vowels on Sat Oct 29 00:05:50 2022
    On 10/27/2022 2:56 AM, Robin Vowels wrote:
    On Thursday, October 27, 2022 at 3:47:19 PM UTC+11, Lynn McGuire wrote:
    On 10/26/2022 7:59 PM, gah4 wrote:
    .
    I think if I was in the mood for doing it, it would be Java and not C++, >>> but then that is just me.
    .
    Would you really write a 750,000 line calculation engine in Java ?
    .
    I think the question that you should be asking yourself is
    "would you really write a 750,000 line calculation engine in C++ ?"

    Since I am doing that, yes, in a heartbeat.

    BTW, this is actually the third software program that I have converted
    to C or C++. This is the biggest by far. My first was:
    https://www.winsim.com/steam/steam.html

    Thanks,
    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Lynn McGuire on Sat Oct 29 14:08:53 2022
    Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
    On 10/27/2022 2:56 AM, Robin Vowels wrote:
    On Thursday, October 27, 2022 at 3:47:19 PM UTC+11, Lynn McGuire wrote:
    On 10/26/2022 7:59 PM, gah4 wrote:
    .
    I think if I was in the mood for doing it, it would be Java and not C++, >>>> but then that is just me.
    .
    Would you really write a 750,000 line calculation engine in Java ?
    .
    I think the question that you should be asking yourself is
    "would you really write a 750,000 line calculation engine in C++ ?"

    Since I am doing that, yes, in a heartbeat.

    BTW, this is actually the third software program that I have converted
    to C or C++. This is the biggest by far. My first was:
    https://www.winsim.com/steam/steam.html

    That looks nice, steam properties are something that you sometimes
    need...

    One of the first applied programs I ever wrote was the simulation
    for a steam turbine. For his job, my father had a MS-DOS program
    which calculated steam properties (you could add the usual values,
    and it would calculate the rest). Via a MS-DOS batch file, I
    then wrote a program to calculate steam turbine expansion if an
    isentropic efficiency was given.

    Another story along these lines... quite some years ago, we
    were sitting in a conference room, and the question came up what
    temperature corresponded to a certain steam pressure in one of
    our plants. A colleague from Thailand then took a steam table
    out of his shirt pocket and supplied the answer. Never leave
    home without it :-)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Thomas Koenig on Sat Oct 29 13:59:08 2022
    On 10/29/2022 9:08 AM, Thomas Koenig wrote:
    Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
    On 10/27/2022 2:56 AM, Robin Vowels wrote:
    On Thursday, October 27, 2022 at 3:47:19 PM UTC+11, Lynn McGuire wrote: >>>> On 10/26/2022 7:59 PM, gah4 wrote:
    .
    I think if I was in the mood for doing it, it would be Java and not C++, >>>>> but then that is just me.
    .
    Would you really write a 750,000 line calculation engine in Java ?
    .
    I think the question that you should be asking yourself is
    "would you really write a 750,000 line calculation engine in C++ ?"

    Since I am doing that, yes, in a heartbeat.

    BTW, this is actually the third software program that I have converted
    to C or C++. This is the biggest by far. My first was:
    https://www.winsim.com/steam/steam.html

    That looks nice, steam properties are something that you sometimes
    need...

    One of the first applied programs I ever wrote was the simulation
    for a steam turbine. For his job, my father had a MS-DOS program
    which calculated steam properties (you could add the usual values,
    and it would calculate the rest). Via a MS-DOS batch file, I
    then wrote a program to calculate steam turbine expansion if an
    isentropic efficiency was given.

    Another story along these lines... quite some years ago, we
    were sitting in a conference room, and the question came up what
    temperature corresponded to a certain steam pressure in one of
    our plants. A colleague from Thailand then took a steam table
    out of his shirt pocket and supplied the answer. Never leave
    home without it :-)

    Yup, the old Combustion Engineering Steam Table pamphlets. A CE boiler
    guy would stop by and hand them out like candy. I have 2 or 3 of them
    still. They are the 1967 ASME steam table which my software is. I have
    a program that calculates steam turbine efficiency called Isencalc
    available on that page. Someday I am going to convert it from DOS to Win32.

    https://www.amazon.com/Steam-Tables-Properties-Saturated-Superheated/dp/B003O5S3ZW/

    My process simulation software has the 1991 Steam Tables in it along
    with 60 other equations of state.
    https://www.winsim.com/index.html

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gary Scott@21:1/5 to Lynn McGuire on Sat Oct 29 14:13:20 2022
    On 10/29/2022 1:59 PM, Lynn McGuire wrote:
    On 10/29/2022 9:08 AM, Thomas Koenig wrote:
    Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
    On 10/27/2022 2:56 AM, Robin Vowels wrote:
    On Thursday, October 27, 2022 at 3:47:19 PM UTC+11, Lynn McGuire wrote: >>>>> On 10/26/2022 7:59 PM, gah4 wrote:
    .
    I think if I was in the mood for doing it, it would be Java and
    not C++,
    but then that is just me.
    .
    Would you really write a 750,000 line calculation engine in Java ?
    .
    I think the question that you should be asking yourself is
    "would you really write a 750,000 line calculation engine in C++ ?"

    Since I am doing that, yes, in a heartbeat.

    BTW, this is actually the third software program that I have converted
    to C or C++.  This is the biggest by far.  My first was:
         https://www.winsim.com/steam/steam.html

    That looks nice, steam properties are something that you sometimes
    need...

    One of the first applied programs I ever wrote was the simulation
    for a steam turbine.  For his job, my father had a MS-DOS program
    which calculated steam properties (you could add the usual values,
    and it would calculate the rest).  Via a MS-DOS batch file, I
    then wrote a program to calculate steam turbine expansion if an
    isentropic efficiency was given.

    Another story along these lines... quite some years ago, we
    were sitting in a conference room, and the question came up what
    temperature corresponded to a certain steam pressure in one of
    our plants.  A colleague from Thailand then took a steam table
    out of his shirt pocket and supplied the answer.  Never leave
    home without it :-)

    Yup, the old Combustion Engineering Steam Table pamphlets.  A CE boiler
    guy would stop by and hand them out like candy.  I have 2 or 3 of them still.  They are the 1967 ASME steam table which my software is.  I have
    a program that calculates steam turbine efficiency called Isencalc
    available on that page.  Someday I am going to convert it from DOS to
    Win32.

    https://www.amazon.com/Steam-Tables-Properties-Saturated-Superheated/dp/B003O5S3ZW/

    My process simulation software has the 1991 Steam Tables in it along
    with 60 other equations of state.
       https://www.winsim.com/index.html

    Lynn

    CO2 is the wave of the future, any adaptations?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Thomas Koenig on Sat Oct 29 14:40:13 2022
    On 10/27/2022 1:21 PM, Thomas Koenig wrote:
    Lynn McGuire <lynnmcguire5@gmail.com> schrieb:

    We used three features in our F66 / F77 code which are turning out to be
    problematic in porting to a new Fortran compiler that supports 64 bit
    software. The first is the carriage control option in printing to
    stdout or a file. This was never a Fortran standard feature but
    everyone used it back in the 1960s, 1970s, and 1980s. This killed our
    port to gfortran several years ago but it is now supported there
    reputedly.

    I am not sure how compiler support of ASA carriage control
    by a compiler is supposed to look like (apart from the
    mandated leading space in free-form output).

    The traditional UNIX way is to pipe it through asa(1), which
    emulates the traditional carriage control with overstrike
    characters etc. This is reasonably easy to write, I once
    wrote such a utility myself (and lost the source) but Debian
    has it. Source at https://sources.debian.org/src/asa/1.2-1.1/ .

    We are ripping it out of our formats as a part of our
    conversion to C++.

    Good riddance.

    We use zero initialization of all global and local variables. This
    killed our first port to Intel Fortran in 2005 ??? when it uncovered a
    linker bug / crash. We have removed the need for this from a portion of
    our Fortran code but will be a problem in the C++ conversion.

    That is a bigger problem.

    Not sure if your code runs under Linux. If it does, you might want
    to run it under valgrind, which will generate tons of errors if
    undefined variables are used.

    We use Fortran structures, popularized by DEC back in the 1970s and
    1980s, but they never became part of the Fortran standard. We are
    converting our structure code to integer*8 and logical*8 as a part of
    the C++ port.

    Huh?

    Almost all of the Fortran compilers are now free. This is a bad sign,
    especially since Intel Fortran, the premier Fortran compiler, just
    jumped to free. To me, this says that future of Fortran is cloudy at best.

    Why should this be a bad thing? Intel uses the compiler to sell chips,
    and so does IBM for POWER.

    Nothing in this world is perfect but moving to a single programming
    language should help us in the long run. Our software is embeddable in
    Excel or can embed Excel in itself, all my glue code is in C++ which
    really points the direction to me.

    In the immortal words of a J3 member...

    " Hiring someone else to write your C++ code is probably a good
    idea for preserving sanity. Although having to read the code
    later will undo any of the previously mentioned benefits."

    We have had almost a hundred programmers over the years, mostly chemical
    and mechanical engineers from a dozen countries. The code reads like a
    very diverse document. The subroutine names are very ... interesting.

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Gary Scott on Sun Oct 30 15:05:04 2022
    On 10/29/2022 2:13 PM, Gary Scott wrote:
    On 10/29/2022 1:59 PM, Lynn McGuire wrote:
    On 10/29/2022 9:08 AM, Thomas Koenig wrote:
    Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
    On 10/27/2022 2:56 AM, Robin Vowels wrote:
    On Thursday, October 27, 2022 at 3:47:19 PM UTC+11, Lynn McGuire
    wrote:
    On 10/26/2022 7:59 PM, gah4 wrote:
    .
    I think if I was in the mood for doing it, it would be Java and
    not C++,
    but then that is just me.
    .
    Would you really write a 750,000 line calculation engine in Java ?
    .
    I think the question that you should be asking yourself is
    "would you really write a 750,000 line calculation engine in C++ ?"

    Since I am doing that, yes, in a heartbeat.

    BTW, this is actually the third software program that I have converted >>>> to C or C++.  This is the biggest by far.  My first was:
         https://www.winsim.com/steam/steam.html

    That looks nice, steam properties are something that you sometimes
    need...

    One of the first applied programs I ever wrote was the simulation
    for a steam turbine.  For his job, my father had a MS-DOS program
    which calculated steam properties (you could add the usual values,
    and it would calculate the rest).  Via a MS-DOS batch file, I
    then wrote a program to calculate steam turbine expansion if an
    isentropic efficiency was given.

    Another story along these lines... quite some years ago, we
    were sitting in a conference room, and the question came up what
    temperature corresponded to a certain steam pressure in one of
    our plants.  A colleague from Thailand then took a steam table
    out of his shirt pocket and supplied the answer.  Never leave
    home without it :-)

    Yup, the old Combustion Engineering Steam Table pamphlets.  A CE
    boiler guy would stop by and hand them out like candy.  I have 2 or 3
    of them still.  They are the 1967 ASME steam table which my software
    is.  I have a program that calculates steam turbine efficiency called
    Isencalc available on that page.  Someday I am going to convert it
    from DOS to Win32.

    https://www.amazon.com/Steam-Tables-Properties-Saturated-Superheated/dp/B003O5S3ZW/

    My process simulation software has the 1991 Steam Tables in it along
    with 60 other equations of state.
        https://www.winsim.com/index.html

    Lynn

    CO2 is the wave of the future, any adaptations?

    Of course, we are general purpose process simulator. CO2 was part of
    the original package in 1969. It is component #49 out of the original
    62. There are almost 1,300 components now.

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tran Quoc Viet@21:1/5 to Lynn McGuire on Wed Nov 23 15:36:25 2022
    On Saturday, November 19, 2022 at 1:01:25 PM UTC+7, Lynn McGuire wrote:
    We are converting a 700,000+ Fortran 77 lines of code plus 50,000+ C++
    lines of code engineering software product to C++. With all that code,
    we produce four Win32 EXEs and three Win32 DLLs. My goal is to add four
    Win64 EXEs and three Win64 DLLs to the product with the same
    capabilities as the Win32 versions (console, windowed, Excel callable,
    Excel embeddable). Plus support for Unicode named files and Unicode
    file paths.

    I am using a customized version of f2c at the moment to automate 80% of
    the conversion from F77 to C++. I have added support for logical*8,
    changed the output file from *.c to *.cpp, added an include for the
    Fable fem.hpp template library, removed the trailing underscores from
    the subroutine and common block names, removed the ftnlen arguments from
    the character arguments, converted all F77 comments to the // instead of
    the /* */, and a few other items. If desired, I am willing to post a
    copy of my modified f2c on my website with the source code. https://netlib.org/f2c/
    https://en.wikipedia.org/wiki/F2c

    f2c does not get me totally there. The Fortran character strings were
    poorly handled so they will probably needed fixing for proper sizing and alignment. The f2c i/o code is crap so I take the original F77 i/o code
    and translate it by hand. The arrays in the argument list are still
    based at an index of one so I convert those to base index of zero by
    hand. All of the local and common block arrays were converted to a base
    index of zero by f2c. I add the new *.cpp file to my Visual Studio
    project. I then add the new function prototypes to my prototypes.h file
    and I add any new common block structures to my commons.h file. I then compile and fix until I get a clean compile.

    I have converted over 29,000 lines of F77 code to C++ now. Almost a
    hundred subroutines and several dozen common blocks. Most are compiling cleanly in Visual C++ 2015. My testing is working well with the
    problems being in the character string area. I am still aiming for
    Christmas for completing the small data analysis program in my
    calculation engine. It is somewhere around 150,000 lines of F77 code.
    Tough to tell since it shares so much code with my big calculation
    engine which is around 600,000 lines of F77 code and 50,000 lines of
    C++. They share about 75,000 lines of F77 and C++ code.

    Thanks,
    Lynn
    Thank you for sharing your experience on that tough work. For years I had also paid lots of effort to convert all F77 codes to modern Fortran and I stopped that job because I found its nonsense. Is that how we are removing Fortran from its world?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Tran Quoc Viet on Thu Nov 24 01:37:24 2022
    On 11/23/2022 5:36 PM, Tran Quoc Viet wrote:
    On Saturday, November 19, 2022 at 1:01:25 PM UTC+7, Lynn McGuire wrote:
    We are converting a 700,000+ Fortran 77 lines of code plus 50,000+ C++
    lines of code engineering software product to C++. With all that code,
    we produce four Win32 EXEs and three Win32 DLLs. My goal is to add four
    Win64 EXEs and three Win64 DLLs to the product with the same
    capabilities as the Win32 versions (console, windowed, Excel callable,
    Excel embeddable). Plus support for Unicode named files and Unicode
    file paths.

    I am using a customized version of f2c at the moment to automate 80% of
    the conversion from F77 to C++. I have added support for logical*8,
    changed the output file from *.c to *.cpp, added an include for the
    Fable fem.hpp template library, removed the trailing underscores from
    the subroutine and common block names, removed the ftnlen arguments from
    the character arguments, converted all F77 comments to the // instead of
    the /* */, and a few other items. If desired, I am willing to post a
    copy of my modified f2c on my website with the source code.
    https://netlib.org/f2c/
    https://en.wikipedia.org/wiki/F2c

    f2c does not get me totally there. The Fortran character strings were
    poorly handled so they will probably needed fixing for proper sizing and
    alignment. The f2c i/o code is crap so I take the original F77 i/o code
    and translate it by hand. The arrays in the argument list are still
    based at an index of one so I convert those to base index of zero by
    hand. All of the local and common block arrays were converted to a base
    index of zero by f2c. I add the new *.cpp file to my Visual Studio
    project. I then add the new function prototypes to my prototypes.h file
    and I add any new common block structures to my commons.h file. I then
    compile and fix until I get a clean compile.

    I have converted over 29,000 lines of F77 code to C++ now. Almost a
    hundred subroutines and several dozen common blocks. Most are compiling
    cleanly in Visual C++ 2015. My testing is working well with the
    problems being in the character string area. I am still aiming for
    Christmas for completing the small data analysis program in my
    calculation engine. It is somewhere around 150,000 lines of F77 code.
    Tough to tell since it shares so much code with my big calculation
    engine which is around 600,000 lines of F77 code and 50,000 lines of
    C++. They share about 75,000 lines of F77 and C++ code.

    Thanks,
    Lynn
    Thank you for sharing your experience on that tough work. For years I had also paid lots of effort to convert all F77 codes to modern Fortran and I stopped that job because I found its nonsense. Is that how we are removing Fortran from its world?

    I am having problems mixing C++ and Fortran code in Visual Studio so I
    am trying to move to all C++. I suspect if I was all Fortran then my
    life would be easier.

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to vie...@gmail.com on Thu Nov 24 10:05:46 2022
    On Wednesday, November 23, 2022 at 6:36:28 PM UTC-5, vie...@gmail.com wrote:

    ..
    Thank you for sharing your experience on that tough work. For years I had also paid lots of effort to convert all F77 codes to modern Fortran and I stopped that job because I found its nonsense. Is that how we are removing Fortran from its world?


    @vie...@gmail.com,

    Can you please elaborate on "I stopped that job because I found its nonsense"?

    Our experience suggests what OP's pursuit - "converting a 700,000+ line Fortran 77 plus 50,000+ line C++ program to C++" - to be UTTER NONSENSE.

    Please note OP is the President and CEO of a commercial software company, WinSim Inc. https://www.winsim.com/staff.html

    And the software in question is primarily the *calculation engine* in the area of chemical process simulation in steady-state conditions (d/dt - where t is time - terms in the physical relations starting with the laws of conservation of mass and then
    energy applied to simulate the chemical processes are not applicable at steady-state). The simulator may have dynamic modes where the PDEs and the ODEs in terms of time become relevant. Anyways, what is stake is heavy-duty number-crunching using arrays
    of floating-point variables for which Fortran is extremely strong. Moreover there is an extremely rich, powerful, performant, and validated legacy and set of Fortran libraries.

    Also, note >80% of the computation time is expended in the libraries toward chemical process thermodynamics, particularly in the procedures toward the so-called equation-of-state and activity coefficient (Gexcess) models for fluids involved in the
    chemical processes. Toward these, there is again a rich legacy and history of codes and libraries in Fortran.

    OP - MICHAEL LYNN MCGUIRE, P.E. - is absolutely on a wrong path to convert the existing code to basically C but which OP wrongly calls as C++ which is primarily due to Microsoft lumping C and C++ together with its Microsoft C/C++ compiler product.

    Those who like to bet can place any odds and bets that OP shall make use of very little C++ should this conversion effort proceed to its fullest. If at all anything, the C++ will be a few features here and there from the days prior to C++ 98 standard
    which was over 25 years ago. Note C++ only became competitive with Fortran in the compute domain applicable to OP - as explained above - starting with its C++14 standard revision, but it appears unlikely any of the C++14 standard features will be picked
    up by OP in this "conversion" pursuit.

    OP needs HELP, SERIOUS HELP. OP, as President and CEO of a company, should focus first on hiring and contracting top-quality professionals for the task.

    OP should CEASE the non-sensical "conversion" to C using F2C.

    Instead OP should FIRST contract and consult with top talents such as Archaeologic Codes and complete a through review of the existing "landscape" around the legacy nonstandard FORTRAN codes in the WinSim commercial software. That is, the so-called 700,
    000 LOC routinely mentioned by OP - and have Archaeologic Codes deliver feedback and possibly a proposal for a true modernization effort using modern Fortran. Here is the website for Archaeologic Codes for OP's benefit:
    https://www.archaeologic.codes/about

    Please know OP has been pursuing this conversion exercise at least since the 2008-2010 timeline, one can find posts at comp.lang.fortran stating the same as the original post going that far back.

    In the meantime, modern Fortran has advanced tremendously and Intel now offers FREE compilers in IFORT and IFX that integrate reasonably well with Microsoft Visual Studio. In addition there are other powerful and free Fortran compilers such as gfortran.
    Compared to the workflows OP likely employs currently with WATFOR, etc., the modern Fortran processors can serve WInSim's developer staff very well. Moreover IFORT supports all of Fortran 2018 including the enhanced operability with C facilities,
    meaning the calculation engine of WinSim can work highly efficiently with the rest of C/"C++" code, often in the graphical user interface and other data preprocessing and post-processing sections of the chemical process simulator.

    In addition, there is a fast advancing ecosystem around modern Fortran with free REPL environments in Lfortran (https://lfortran.org/), Fortran stdlib efforts that will produce rich Fortran libraries including numerical ones that WinSim can make use of,
    also various other tooling including Microsoft Visual Studio Code, and so forth that will serve the future WinSim staff extremely well, should OP steer toward modernization with modern Fortran now with the help of folks such as Archaeologic Codes.

    OP would do well to STOP the conversion of legacy nonstandard FORTRAN codes in WinSim now and instead get in touch with modern Fortran experts - PRONTO!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to Thomas Koenig on Thu Nov 24 10:29:52 2022
    On Thursday, November 24, 2022 at 10:00:12 AM UTC-5, Thomas Koenig wrote:

    ..
    Which begs the question - why not introduce the OO featues that
    modern Fortran can do, without first converting to the common
    subset of C and C++?

    OP, as the President and CEO of a commercial software company, should be in the "business" of hiring and contracting top talent and coordinating and directing and managing and executing projects with them rather than trying out a discontinued tool like
    F2C and converting code.

    https://www.archaeologic.codes/services
    Archaeologic Codes can provide services to OP and WinSim Inc. that can help modernize the WinSim's legacy nonstandard FORTRAN code base to IEC ISO standard modern Fortran and then introduce all the relevant programming paradigms starting structured and
    modular programming accompanied by, as applicable OO, and functional programming along with parallel programming also, all in standard Fortran which can integrate most efficiently with the rest of the code for GUI, data processing, etc. which, for
    various other reasons, tends to be not in Fortran.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to JRR on Thu Nov 24 10:18:51 2022
    On Thursday, November 24, 2022 at 8:29:03 AM UTC-5, JRR wrote:

    ..
    From the experience in my field of physics, for all the codes that have
    not been written from scratch, but translated from Fortran77 to C(++)
    the main struggle started _after_ the codes had been translated. That is because after the translation many codes are in state of pure C, not C++ code, and basically are not using any of the nice features of C++. Then
    using things like OO, polymorphism and features of the C++ stdlib took
    the authors much more time than the simple translation from Fortran77 to C(++). ..

    @JRR is exactly right. This link on 1967 ASME Steam Tables code with "steam.c" file is the "best" that can come out from OP's exercise:
    https://www.winsim.com/steam/steam.html

    It will be far better for modern codes, especially commercial ones, to avoid working with "raw pointers" which are highly likely from OP's "translation" effort. OP would do well to reconsider as indicated here:
    https://groups.google.com/g/comp.lang.fortran/c/NmQkbtALkyo/m/xWYvXlx0CAAJ

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to Lynn McGuire on Fri Nov 25 06:54:16 2022
    On Friday, November 25, 2022 at 12:38:27 AM UTC-5, Lynn McGuire wrote:

    ..
    The problem that I have run into in modern Fortran is that there is not
    a good IDE (interactive development environment) on Windows. Since we
    do not have any current customers on Unix / Linux, I do not know about
    those platforms.

    I tried Simply Fortran using GCC and GFortran and was very unsatisfied
    with the debugger, we need to be able to stop at the 459th call to a
    certain method. I tried Visual Studio 2019 with Intel Fortran and
    Visual C++ and was very unhappy with the poor integration of Intel
    Fortran into the IDE. ..

    Re: "The problem that I have run into in modern Fortran is that there is not a good IDE (interactive development environment) on Windows,"

    - that's a fair criticism that is consistently felt in the Enterprise domain (e.g., large companies such as Bayer, BASF, DuPont, Dow, Exxon, Shell, Linde, etc. and the vendors such as WinSim, Inc. who sell products and services to them) where Windows OS
    is the primary or the sole OS platform for computations even.

    Re: ".. very unhappy with the poor integration of Intel Fortran into the (Visual Studio) IDE .."
    - that too is a fair criticism that many a manager in the Enterprise domain have expressed and I have been feeding that back to Intel software team for quite a while now, but Intel team faces many challenges.

    In spite of the above challenges, OP and others would do well to look at other recent developments e.g., those getting discussed and planned and extended at the Fortran Discourse site and know things are starting to move faster now with in the modern
    Fortran space and it is worth giving modern Fortran a strong consideration, especially if you have a code base in legacy nonstandard FORTRAN (77 and its prior/later dialects).

    The benefits of investing in modern Fortran in the chemical process simulation domain of interest to OP specifically and scientific and technical computing generally are significantly better than going with generic C++. With C++, one would have to make
    major strides in complete redesign and refactoring to modern C++ e.g., C++17 and perhaps some of C++20 and later features. But that's a massive task, adding big layers of computational complexity. Methinks modern Fortran will be better.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to Lynn McGuire on Sat Nov 26 06:44:29 2022
    On Friday, November 25, 2022 at 12:38:27 AM UTC-5, Lynn McGuire wrote:

    @Lynn McGuire,

    ..
    I tried Simply Fortran using GCC and GFortran and was very unsatisfied
    with the debugger, we need to be able to stop at the 459th call to a
    certain method.

    Separately, note with Intel Fortran and Visual Studio, one can do this i.e., "be able to stop at the 459th call to a certain method" Note there are quite a few users at the Intel Fortran forum as well as the Fortran Discourse now who are able to perform
    graphically debugging with Intel Fortran in Visual Studio and who are ever willing to help other users, say if WinSim Inc. had a dozen developers doing this, or only Lynn McGuire even, they could post online and get top-notch real-time help and
    assistance to get going with their Fortran debugging. Here's a comment from a reader at the Fortran Discourse site:

    "I find visual studio with intel one api fortran a very good IDE for debugging in modern fortran on a Windows machine. It used to be very expensive but now it’s free. What I like the most about it is that you can set breakpoints and step through the
    code very easily. You can also inspect variables in smth called immediate window in the bottom right of the screen."
    https://fortran-lang.discourse.group/t/the-problem-with-modern-fortran-is-that-there-is-not-a-good-ide-on-windows/4808/6?u=fortranfan

    I tried Visual Studio 2019 with Intel Fortran and
    Visual C++ and was very unhappy with the poor integration of Intel
    Fortran into the IDE.

    Sure there are some installation challenges and if one were to get into a compare mode with other languages such as Microsoft's own C# in Visual Studio, Fortran will look poor.

    But the larger picture I suggest keeping in mind are the benefits of modern Fortran for scientific and technical computing. There is great movement to improve the ecosystem around Fortran. There is already feedback that modern Fortran works very well
    with Visual Studio Code, the other editor product from Microsoft. There will more editor and IDE support forthcoming with modern Fortran.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to Lynn McGuire on Sat Nov 26 06:31:51 2022
    On Friday, November 25, 2022 at 2:58:25 PM UTC-5, Lynn McGuire wrote:


    @Lynn McGuire,

    The only thing that I know to do at this time is to move my Fortran code
    to a Microsoft supported language. ..

    Please try to follow this discussion also at the Fortran Discourse site and perhaps provide comments there:
    https://fortran-lang.discourse.group/t/the-problem-with-modern-fortran-is-that-there-is-not-a-good-ide-on-windows/4808?u=fortranfan

    After all, there is some evidence
    floating about that Microsoft is getting ready to follow Apple, once
    more, and jump to the ARM cpus and leave Intel behind.

    Are not the higher-end Apple macOS laptops still using Intel CPUs, as opposed to ARM? In an Enterprise domain like at the influential customers of WinSim Inc., the users - mostly process/chemical/petroleum/mechanical engineers, etc. - who have to run
    software such as WinSim are still likely to be on higher-end laptops i.e., Intel CPUs for the foreseeable future.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to All on Sun Nov 27 10:25:27 2022
    On 11/26/22 8:31 AM, FortranFan wrote:
    [...]> Are not the higher-end Apple macOS laptops still using Intel
    CPUs, as opposed to ARM? In an Enterprise domain like at the
    influential customers of WinSim Inc., the users - mostly process/chemical/petroleum/mechanical engineers, etc. - who have to run software such as WinSim are still likely to be on higher-end laptops
    i.e., Intel CPUs for the foreseeable future.

    Apple has been switching to arm64 processors since 2020. During this
    switchover period, one could buy new models (meaning fully supported
    both software and hardware) with either intel or arm64 CPUs.
    Specifically for the high-end MacBook Pros, the last intel model
    revision was in the spring of 2021, and since the fall of 2021 all new
    models have been based on arm64 hardware. The older intel machines are
    still fully supported with software (OS and security updates), old intel software is fully supported through emulation on the new arm64 hardware,
    and they also support "fat binaries" where both sets of instructions
    exist within a single program and the correct instruction set is
    selected at run time. Apple has made this kind of transition before,
    from Motorola 68xxx to PowerPC, and then from PowerPC to intel, and it
    all works surprisingly well. This current transition from intel to arm64
    is the same. New MacBook Pros are expected to be announced early in 2023
    that are based on the latest revision of the arm64 CPUs (M2). Based on
    the past history of hardware transitions, Apple is expected to continue
    to support the existing intel hardware base for another three to six
    years, but there will be no new intel-based Apple hardware manufactured
    in the foreseeable future. I still have 20-25 year old PowerPC based
    Macintosh computers that run (including IBM fortran compilers), although
    Apple support ended for them about 10 years ago.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to FortranFan on Mon Nov 28 11:50:42 2022
    On 11/24/2022 12:05 PM, FortranFan wrote:
    On Wednesday, November 23, 2022 at 6:36:28 PM UTC-5, vie...@gmail.com wrote:

    ..
    Thank you for sharing your experience on that tough work. For years I had also paid lots of effort to convert all F77 codes to modern Fortran and I stopped that job because I found its nonsense. Is that how we are removing Fortran from its world?


    @vie...@gmail.com,

    Can you please elaborate on "I stopped that job because I found its nonsense"?

    Our experience suggests what OP's pursuit - "converting a 700,000+ line Fortran 77 plus 50,000+ line C++ program to C++" - to be UTTER NONSENSE.

    Please note OP is the President and CEO of a commercial software company, WinSim Inc. https://www.winsim.com/staff.html

    And the software in question is primarily the *calculation engine* in the area of chemical process simulation in steady-state conditions (d/dt - where t is time - terms in the physical relations starting with the laws of conservation of mass and then
    energy applied to simulate the chemical processes are not applicable at steady-state). The simulator may have dynamic modes where the PDEs and the ODEs in terms of time become relevant. Anyways, what is stake is heavy-duty number-crunching using arrays
    of floating-point variables for which Fortran is extremely strong. Moreover there is an extremely rich, powerful, performant, and validated legacy and set of Fortran libraries.

    I note that you outed me all over the place. That is very uncool, even
    for a guy living in his mother's basement. You have zero credibility in
    my opinion when you start up personal attacks like this. What are you, 15 ?

    And my software already has dynamic memory usage in it all over the
    place for when we converted to sparse matrixes back in 1977 using the
    dynosor ( https://dl.acm.org/doi/10.1145/954654.954661 ) technology.
    It enabled us to live on the 2 megaword Univac 1108 until 1982. And
    then on the 6 megaword IBM 370 until their replacements in the late
    1980s. Here is a sample of our code:

    IFLBLO = VDY(KPDSP+5) + 0.1
    C EQUIPMENT IS ADD/FTN BLOCK IF NECALL BETWEEN 18 AND 35
    if (necall .lt. 18 .or. necall .gt. 35 .or. iflblo .ne. 2) then
    call amoco (jeqno, nin, nout, ncp, neqp, ndsp, vdy (ivpfr + 1),
    * vdy (itemp + 1), vdy (ipres + 1), vdy (ienth + 1),
    * vdy (ientr + 1),
    * vdy (imole + 1), vdy (icomp + 1), vdy (isikv + 1),
    * vdy (ovpfr + 1),
    * vdy (otemp + 1), vdy (opres + 1), vdy (oenth + 1),
    * vdy (oentr + 1),
    * vdy (omole + 1), vdy (ocomp + 1), vdy (osokv + 1),
    * vdy (kpeqp+1), vdy (kpdsp+1), vdy (kpscp+2),
    * ivdy (kpin + 1).i, ivdy (kpout + 1).i)
    else
    NBLOCK = NECALL - 17
    CALL LINECK(2)
    WRITE (OUFILE,61) NBLOCK
    61 FORMAT ('0IN-LINE FORTRAN - SIMULATE BLOCK ',I6)
    CALL LCBK ('DRCT',NDRCTO,LDRCTO)
    call adinlf (jeqno, nblock, ivdy(ndrcto+1).i ,
    * nin ,nout ,neqp ,ndsp ,
    * ivpfr ,itemp ,ipres ,ienth ,imole ,
    * icomp ,isikv ,ovpfr ,otemp ,opres ,
    * oenth ,omole ,ocomp ,osokv ,kpeqp ,
    * kpdsp,
    * ieqp, extnum, eqnam, max_streams_per_equipment,
    * equipment_connections, immsav)
    end if

    No thanks to your advice,
    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to Lynn McGuire on Mon Nov 28 16:04:13 2022
    On Monday, November 28, 2022 at 12:50:48 PM UTC-5, Lynn McGuire wrote:

    ..You have zero credibility in
    my opinion when you start up personal attacks like this. What are you, 15 ?

    ..
    No thanks to your advice,

    @Lynn McGuire,

    You've been on this forum and comp.lang.c++, etc. for ages stating you are going to refactor your XXXK lines of "F77" code to something else, usually C++. You are still trying. In the mean time, you have made many posts about "zero initialization" in
    your "F77" code and what-not, none of which make any sense whatsoever that they should persist so long.

    I have a lot of stake in the industry you sell into and it is likely that several of my important vendors/suppliers are your unknowing customers. Going by your posts, I really worry what kind of product they might be relying upon. I also wonder of the
    kind of staff and consultants you hire as the President and CEO of your company that low-level code issues persist like so and that your colleagues let you make such posts online! Your posts would make anyone in the know about chemical process
    simulations really wonder and worry about the quality of code behind WinSim.

    What in the hell you think the code snippet you post with 'call amoco' and 'CALL LCBK' will illustrate, huh? That somehow you managed to use the memory management techniques back in 1977 when there was no Fortran, only nonstandard FORTRAN in actual use
    and that the `ALLOCATE` statement was yet unavailable, but somehow you have remained stuck there ever since?

    Re: "No thanks to your advice" - that much was long clear. Well before I started on this forum around mid-2010s, you received plenty of good advice from many others regarding the use of modern programming techniques in your codes including those from
    modern Fortran and C++. You seem to have ignored all of it. Put me aside, it appears you have a massive problem generally with accepting any advice. So what are you then, a toddler?

    Why are you continuing as the President and CEO if you can't accept advice and delegate tasks that should be delegated to those who can do a far better job at it than you? Look up your job description, that will be first on the list.

    Instead of worrying about who's living in whose basement and insinuating any mothers, you should ask yourself which gutter of a mindset are you in. You represent an important and crucial industry, especially in the US, but your posts really make WinSim
    and its code look highly suspect and it casts a long shadow of incompetence on chemical process simulation and the chemical industry also.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Objexx Engineering@21:1/5 to FortranFan on Mon Nov 28 18:05:54 2022
    On Monday, November 28, 2022 at 7:04:16 PM UTC-5, FortranFan wrote:

    You've been on this forum and comp.lang.c++, etc. for ages stating you are going to refactor your XXXK lines of "F77" code to something else, usually C++. You are still trying. In the mean time, you have made many posts about "zero initialization" in
    your "F77" code and what-not, none of which make any sense whatsoever that they should persist so long.
    ...
    Why are you continuing as the President and CEO if you can't accept advice and delegate tasks that should be delegated to those who can do a far better job at it than you? Look up your job description, that will be first on the list.
    ...

    A number of years ago I explained our system for Fortran-to-C++ conversion to this person that would have provided them with clear, validated C++ (instead of the mess that F2C produces) and got a lot of (to me nonsensical) "reasons" why that wouldn't
    meet his needs. I am probably with most of the folks here in thinking that converting this code to C++ is a questionable choice for this company, but the "process" they have chosen is beyond absurd. Trying to get through to some people is not worth the
    oxygen expended!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Objexx Engineering on Mon Nov 28 21:20:36 2022
    On 11/28/2022 8:05 PM, Objexx Engineering wrote:
    On Monday, November 28, 2022 at 7:04:16 PM UTC-5, FortranFan wrote:

    You've been on this forum and comp.lang.c++, etc. for ages stating you are going to refactor your XXXK lines of "F77" code to something else, usually C++. You are still trying. In the mean time, you have made many posts about "zero initialization" in
    your "F77" code and what-not, none of which make any sense whatsoever that they should persist so long.
    ...
    Why are you continuing as the President and CEO if you can't accept advice and delegate tasks that should be delegated to those who can do a far better job at it than you? Look up your job description, that will be first on the list.
    ...

    A number of years ago I explained our system for Fortran-to-C++ conversion to this person that would have provided them with clear, validated C++ (instead of the mess that F2C produces) and got a lot of (to me nonsensical) "reasons" why that wouldn't
    meet his needs. I am probably with most of the folks here in thinking that converting this code to C++ is a questionable choice for this company, but the "process" they have chosen is beyond absurd. Trying to get through to some people is not worth the
    oxygen expended!

    Are you the guy who wanted $75,000 up front plus 5% of my future sales
    in perpetuity ?

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Objexx Engineering@21:1/5 to Lynn McGuire on Mon Nov 28 21:35:08 2022
    On Monday, November 28, 2022 at 10:20:41 PM UTC-5, Lynn McGuire wrote:
    Are you the guy who wanted $75,000 up front plus 5% of my future sales
    in perpetuity ?

    Very classy! No, we never take a cut of client sales or any ongoing license costs. I suspect the real issue is that WinSim is not profitable enough for you to afford any outside expertise, ergo the years of floundering and endless posts in multiple
    forums.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stuart Mentzer@21:1/5 to Lynn McGuire on Mon Nov 28 21:29:22 2022
    On Monday, November 28, 2022 at 10:20:41 PM UTC-5, Lynn McGuire wrote:
    On 11/28/2022 8:05 PM, Objexx Engineering wrote:
    On Monday, November 28, 2022 at 7:04:16 PM UTC-5, FortranFan wrote:

    You've been on this forum and comp.lang.c++, etc. for ages stating you are going to refactor your XXXK lines of "F77" code to something else, usually C++. You are still trying. In the mean time, you have made many posts about "zero initialization"
    in your "F77" code and what-not, none of which make any sense whatsoever that they should persist so long.
    ...
    Why are you continuing as the President and CEO if you can't accept advice and delegate tasks that should be delegated to those who can do a far better job at it than you? Look up your job description, that will be first on the list.
    ...

    A number of years ago I explained our system for Fortran-to-C++ conversion to this person that would have provided them with clear, validated C++ (instead of the mess that F2C produces) and got a lot of (to me nonsensical) "reasons" why that wouldn't
    meet his needs. I am probably with most of the folks here in thinking that converting this code to C++ is a questionable choice for this company, but the "process" they have chosen is beyond absurd. Trying to get through to some people is not worth the
    oxygen expended!
    Are you the guy who wanted $75,000 up front plus 5% of my future sales
    in perpetuity ?

    Lynn

    Certainly not! We never take a cut of client sales or have any ongoing licensing fees. But we do run a business and charge an appropriate fee for our expertise and amortizing our development costs. Perhaps WinSim is not profitable enough for you to
    afford any outside costs at all, ergo the years of pointless floundering and endless posts ;-).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Objexx Engineering on Tue Nov 29 06:18:49 2022
    Objexx Engineering <objexx@objexx.com> schrieb:
    On Monday, November 28, 2022 at 7:04:16 PM UTC-5, FortranFan wrote:

    You've been on this forum and comp.lang.c++, etc. for ages stating you are going to refactor your XXXK lines of "F77" code to something else, usually C++. You are still trying. In the mean time, you have made many posts about "zero initialization" in
    your "F77" code and what-not, none of which make any sense whatsoever that they should persist so long.
    ...
    Why are you continuing as the President and CEO if you can't accept advice and delegate tasks that should be delegated to those who can do a far better job at it than you? Look up your job description, that will be first on the list.
    ...

    A number of years ago I explained our system for Fortran-to-C++
    conversion to this person that would have provided them with clear,
    validated C++ (instead of the mess that F2C produces) and got a lot
    of (to me nonsensical) "reasons" why that wouldn't meet his needs.

    Insulting potential customers is a great way to earn business,
    and bad-mouthing people who have consulted and decided not to use
    your services is even better.

    That will let _anybody_ feel confident about talking to you in
    the future. Professional behavior at its finest!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Objexx Engineering@21:1/5 to All on Mon Nov 28 23:28:50 2022
    I have provided facts about the futility of trying to help with this "project" so that the great forum members who offer their expertise can move on. I consider that a service to the community. If you choose to keep trying to help them and expect to get
    through, well, that's on you. This is nobody's potential customer, just a time and energy vampire. But if you enjoy frustration, keep at it!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Objexx Engineering on Tue Nov 29 13:26:27 2022
    On 11/29/2022 1:28 AM, Objexx Engineering wrote:
    I have provided facts about the futility of trying to help with this "project" so that the great forum members who offer their expertise can move on. I consider that a service to the community. If you choose to keep trying to help them and expect to
    get through, well, that's on you. This is nobody's potential customer, just a time and energy vampire. But if you enjoy frustration, keep at it!

    I am sorry that you disagree with me about my methods of getting things
    done. I would urge you to killfile me.

    I guess about 10 or so years ago I talked to 4 or 5 vendors of F77 to C
    / C++ translation tools. I ended up buying Cobalt Blue's FOR_C tool for
    $4,000 and thought that I had tested it fairly well. When I started the translation project about six months or a year later (I live in the
    tyranny of the now), I got burned in that it did not handle Fortran data structures which are extensively used in my F77 source code. In the
    meantime, the guy closed his business down. I offered to add the
    support myself if he would forward the source code to me but he would
    not. So here I am down the road, rolling my own solution since I have
    serious trust issues now and very non standard F77 / F66 code.

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pehache@21:1/5 to All on Wed Nov 30 08:41:12 2022
    Le 26/11/2022 à 15:31, FortranFan a écrit :

    After all, there is some evidence
    floating about that Microsoft is getting ready to follow Apple, once
    more, and jump to the ARM cpus and leave Intel behind.

    Are not the higher-end Apple macOS laptops still using Intel CPUs, as opposed to ARM? In an Enterprise domain like at the influential customers of WinSim Inc., the users - mostly process/chemical/petroleum/mechanical engineers, etc. - who have to run
    software such as WinSim are still likely to be on higher-end laptops i.e., Intel CPUs for the foreseeable future.

    There are no more intel-based laptop in the Apple catalogue, all of them
    have been converted to ARM. There are still 2 desktop models that are
    Intel based, including their high end machine, the Mac Pro. But it's
    just because they don't have yet the appropriate ARM CPU to put in, and
    it's planned for early 2023. At that moment thre wil be no Mac with an
    Intel CPU.

    The experience show that major software vendors quickly propose a ARM
    version to follow the clients, and that it's not a big deal.

    As for the Windows world, I don't think ARM CPUs will replace Intel ones
    soon. It may happen in some future, but at the very least there will be
    a very long period where both architectures will cohabit. The ARM
    Windows version has been around for years now, and there are still very
    few PCs with an ARM CPU (and almost all of them are on the
    ultra-portable segment)

    --
    "...sois ouvert aux idées des autres pour peu qu'elles aillent dans le
    même sens que les tiennes.", ST sur fr.bio.medecine
    ST passe le mur du çon : <j3nn2hFmqj7U1@mid.individual.net>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Lynn McGuire on Wed Nov 30 00:51:59 2022
    On Wednesday, November 30, 2022 at 6:26:32 AM UTC+11, Lynn McGuire wrote:
    On 11/29/2022 1:28 AM, Objexx Engineering wrote:
    I have provided facts about the futility of trying to help with this "project" so that the great forum members who offer their expertise can move on. I consider that a service to the community. If you choose to keep trying to help them and expect to
    get through, well, that's on you. This is nobody's potential customer, just a time and energy vampire. But if you enjoy frustration, keep at it!
    I am sorry that you disagree with me about my methods of getting things done. I would urge you to killfile me.

    I guess about 10 or so years ago I talked to 4 or 5 vendors of F77 to C
    / C++ translation tools. I ended up buying Cobalt Blue's FOR_C tool for $4,000 and thought that I had tested it fairly well. When I started the translation project about six months or a year later (I live in the
    tyranny of the now), I got burned in that it did not handle Fortran data structures which are extensively used in my F77 source code.

    F77 didn't have data strctures. That was your mistake. You didn't
    really have F77 source.

    In the
    meantime, the guy closed his business down. I offered to add the
    support myself if he would forward the source code to me but he would
    not. So here I am down the road, rolling my own solution since I have serious trust issues now and very non standard F77 / F66 code.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Robin Vowels on Wed Nov 30 15:12:51 2022
    On 11/30/2022 2:51 AM, Robin Vowels wrote:
    On Wednesday, November 30, 2022 at 6:26:32 AM UTC+11, Lynn McGuire wrote:
    On 11/29/2022 1:28 AM, Objexx Engineering wrote:
    I have provided facts about the futility of trying to help with this "project" so that the great forum members who offer their expertise can move on. I consider that a service to the community. If you choose to keep trying to help them and expect to
    get through, well, that's on you. This is nobody's potential customer, just a time and energy vampire. But if you enjoy frustration, keep at it!
    I am sorry that you disagree with me about my methods of getting things
    done. I would urge you to killfile me.

    I guess about 10 or so years ago I talked to 4 or 5 vendors of F77 to C
    / C++ translation tools. I ended up buying Cobalt Blue's FOR_C tool for
    $4,000 and thought that I had tested it fairly well. When I started the
    translation project about six months or a year later (I live in the
    tyranny of the now), I got burned in that it did not handle Fortran data
    structures which are extensively used in my F77 source code.

    F77 didn't have data strctures. That was your mistake. You didn't
    really have F77 source.

    In the
    meantime, the guy closed his business down. I offered to add the
    support myself if he would forward the source code to me but he would
    not. So here I am down the road, rolling my own solution since I have
    serious trust issues now and very non standard F77 / F66 code.

    Yup, such is life. I am getting rid of the Fortran data structures in
    my C++ port, even though C and C++ natively support structures. F2C
    does not handle Fortran data structures in its conversion to C/C++
    either. I am also getting rid of my automatic zero initialization and
    not converting all local variables to globals.

    I am converting all of my integers and logicals to integer*8 as we store
    C pointers in them so that is getting us ready for the Win64 port. All
    of our data is stored in sparse memory banks which will be kept as I do
    have some customer files that are hitting 1 GB in size at runtime. The
    sparse arrays and matrices are still needed.

    We got rid of the Hollerith characters several years ago. And we added "implicit none" to our code several years ago. Both of those are
    helping significantly in the C++ port.

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Lynn McGuire on Wed Nov 30 22:10:28 2022
    Lynn McGuire <lynnmcguire5@gmail.com> schrieb:

    I am converting all of my integers and logicals to integer*8 as we store
    C pointers in them so that is getting us ready for the Win64 port.

    That sounds very dangerous. This violates the C standard, and
    another revision of the optimizers might just break your code.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Lynn McGuire on Wed Nov 30 22:50:56 2022
    Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
    On 11/30/2022 4:10 PM, Thomas Koenig wrote:
    Lynn McGuire <lynnmcguire5@gmail.com> schrieb:

    I am converting all of my integers and logicals to integer*8 as we store >>> C pointers in them so that is getting us ready for the Win64 port.

    That sounds very dangerous. This violates the C standard, and
    another revision of the optimizers might just break your code.

    Can you educate me a little bit more please ? How does this violate the
    C standard ? The C pointers are currently returned from calls to malloc
    and realloc.

    Hm, I think I oversimplified.

    In the latest draft of the C standard, 6.2.3.2 states

    # An integer may be converted to any pointer type. Except as
    # previously specified, the result is implementation-defined,
    # might not be correctly aligned, might not point to an entity of
    # the referenced type, and might be a trap representation.
    #
    # Any pointer type may be converted to an integer type. Except as
    # previously specified, the result is implementation-defined. If the
    # result cannot be represented in the integer type, the behavior is
    # undefined. The result need not be in the range of values of any
    # integer type.

    So, if the documentation of yor C compiler tells you that you can
    freely convert between some ints and some pointer, you're likely
    to get the results you want. You'll be locked to that compiler,
    though, but it might just work, unless it doesn't.

    But of course, C++ isn't C, and I don't know C++ well enough
    to tell you what is dangerous there and what isn't.

    As for logicals, that's a can of worms. Old Fortran did not specify
    the values for logicals, and different compilers supplied different interpretations - reading true or false written by one compiler did
    not necessarily represent a true or false value in another compiler.

    There are at least three conventions: Some compilers use C's
    "nonzero is true" convention. Others just test for the least
    significant bit. And there is a faction which just allows
    for (in representation) 0 and 1, and anything else is undefined,
    and liable to break if you test for a .eqv. b where a has the
    numerical value of 1 and b of 2.

    Soo... not sure what your code actually looks like, but intermixing
    logicals with is asking for interesting effects.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Thomas Koenig on Wed Nov 30 16:22:54 2022
    On 11/30/2022 4:10 PM, Thomas Koenig wrote:
    Lynn McGuire <lynnmcguire5@gmail.com> schrieb:

    I am converting all of my integers and logicals to integer*8 as we store
    C pointers in them so that is getting us ready for the Win64 port.

    That sounds very dangerous. This violates the C standard, and
    another revision of the optimizers might just break your code.

    Can you educate me a little bit more please ? How does this violate the
    C standard ? The C pointers are currently returned from calls to malloc
    and realloc.

    Thanks,
    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Thomas Koenig on Wed Nov 30 17:56:58 2022
    On 11/30/2022 4:50 PM, Thomas Koenig wrote:
    Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
    On 11/30/2022 4:10 PM, Thomas Koenig wrote:
    Lynn McGuire <lynnmcguire5@gmail.com> schrieb:

    I am converting all of my integers and logicals to integer*8 as we store >>>> C pointers in them so that is getting us ready for the Win64 port.

    That sounds very dangerous. This violates the C standard, and
    another revision of the optimizers might just break your code.

    Can you educate me a little bit more please ? How does this violate the
    C standard ? The C pointers are currently returned from calls to malloc
    and realloc.

    Hm, I think I oversimplified.

    In the latest draft of the C standard, 6.2.3.2 states

    # An integer may be converted to any pointer type. Except as
    # previously specified, the result is implementation-defined,
    # might not be correctly aligned, might not point to an entity of
    # the referenced type, and might be a trap representation.
    #
    # Any pointer type may be converted to an integer type. Except as
    # previously specified, the result is implementation-defined. If the
    # result cannot be represented in the integer type, the behavior is
    # undefined. The result need not be in the range of values of any
    # integer type.

    So, if the documentation of yor C compiler tells you that you can
    freely convert between some ints and some pointer, you're likely
    to get the results you want. You'll be locked to that compiler,
    though, but it might just work, unless it doesn't.

    But of course, C++ isn't C, and I don't know C++ well enough
    to tell you what is dangerous there and what isn't.

    As for logicals, that's a can of worms. Old Fortran did not specify
    the values for logicals, and different compilers supplied different interpretations - reading true or false written by one compiler did
    not necessarily represent a true or false value in another compiler.

    There are at least three conventions: Some compilers use C's
    "nonzero is true" convention. Others just test for the least
    significant bit. And there is a faction which just allows
    for (in representation) 0 and 1, and anything else is undefined,
    and liable to break if you test for a .eqv. b where a has the
    numerical value of 1 and b of 2.

    Soo... not sure what your code actually looks like, but intermixing
    logicals with is asking for interesting effects.

    F2C is converting my logical and logical*8 types to a "long long" in C++
    for me. I made some changes to F2C to make this happen. I can easily
    change the "long long" to int64_t but I have yet to decide what is best.

    In Win64 programs, an int is 4 bytes, a long is 4 bytes, and a long long
    is 8 bytes, all signed.

    Thanks,
    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Ron Shepard on Thu Dec 1 00:50:26 2022
    On Wednesday, November 30, 2022 at 11:45:26 PM UTC-8, Ron Shepard wrote:

    (snip)

    I feel your pain regarding your extensive use of those nonstandard
    features, which include structures and automatic zero initialization, as
    you have told us about many times here. I have used those features
    myself on a much smaller scale back in the 1970s, so I know their
    appeal. As I understand your situation now, your code only works with a single fortran compiler and a single operating system. I certainly do
    not claim to know what you should do now to dig out of that hole, but I
    do hope you succeed with whatever path you choose.

    For problems this size, there is never an easy answer.

    It seems that some answers are less helpful, and seem not
    to hope for success. Presumably more than one person has
    worked on this over the years. Even decisions based on the best
    choice at the time, might turn out later to have been wrong.

    So, yes, good luck!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to All on Thu Dec 1 14:58:41 2022
    On 12/1/2022 2:50 AM, gah4 wrote:
    On Wednesday, November 30, 2022 at 11:45:26 PM UTC-8, Ron Shepard wrote:

    (snip)

    I feel your pain regarding your extensive use of those nonstandard
    features, which include structures and automatic zero initialization, as
    you have told us about many times here. I have used those features
    myself on a much smaller scale back in the 1970s, so I know their
    appeal. As I understand your situation now, your code only works with a
    single fortran compiler and a single operating system. I certainly do
    not claim to know what you should do now to dig out of that hole, but I
    do hope you succeed with whatever path you choose.

    For problems this size, there is never an easy answer.

    It seems that some answers are less helpful, and seem not
    to hope for success. Presumably more than one person has
    worked on this over the years. Even decisions based on the best
    choice at the time, might turn out later to have been wrong.

    So, yes, good luck!

    Around a hundred chemical and mechanical engineers, half of them were
    PhD or PhD candidates, were the main programmers since 1965. I have
    been meaning to make a list of them some day. I have been working on it
    since 1975 to 1982, and 1992 to now.

    Over the years it has been ported to a dozen+ platforms: Univac 1108,
    CDC 7600, IBM 370 CMS and MVS, Prime OS, IBM AT 370, Vax VMS, Sun OS,
    Apollo Domain, IBM 3090, IBM RS 6000, PC DOS 32, Windows Win32s, Windows
    Win32. The goal of this port is Windows Win64.

    About seven or eight actual software engineers who had actually read the
    Dragon book (Principles of Compiler Design). The guy who wrote our
    built in Fortran interpreter was a real software engineer, he wrote his
    own lex and yacc in Fortran 66 code in 1980-1981. It is not pretty but
    it works.

    Thanks,
    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)