Rebuilding a Compaq Visual Fortran project in IVF 2022 with only original executable and source File

[Mason6]

I am trying to rebuild the executable for a program (RT3D) that runs groundwater modeling software (runs chemical transformation equations given a hydraulic flow file input) through a GUI program known as GMS 10.4 from Aquaveo, and am running into issues replicating the solution that was originally written in Compaq Visual Fortran back in 2003. While support for the program, at least regarding its compilation, is defunct at this point and practically non-existent, I have been able to acquire the source files that were originally used, as well as a makefile that was used for CVF to build the solution and the finished executable that currently works as expected. My plan was to do the following:

1. Use the makefile to see what files are needed for the executable, and how they are linked into the project.

2. Use dependency walker on the .exe I create and compare it to the .exe that I have that currently works.

I have been able to use both the command line and a modified makefile as well as the solution window in IVF to build executables that appear to be working, but executables have different reference libraries in Dependency Walker and neither actually works properly when run through the GUI that runs both the hydraulic and chemical reaction calculations. 

Before you ask, I have reached out to Aquaveo and they assure me that the RT3D executable used in GMS 10.4 is the same executable distributed and intended to be run through the command line, so I can rule out any sort of proprietary changes as the cause for my issues with getting the program to work. Therefore, it must be some sort of dependency or standard that I am not inputting correctly causing failure of the program to compile. I am very new to Fortran, but have been trying for over a month to get the program to work correctly to use for my research project (I am a civil engineering master's student). 

The program can be run as a ".dll version" (this is what I want) that after compiling only requires alteration to the two included .dll files to use special "user defined chemical reactions" in place of the stock reactions.  I have been able to recompile my own .dll files in the place of the two default ones and have been able to get these to work using a (IFACE:CVF) calling convention. Furthermore, I have the makefile for the original executable.

I am hoping with the .f files included below and the original makefile, someone can give me some sort of recommendations for how to recompile the program. I have tried running the makefile in the Intel 32-bit command line, replacing the "df" commands with "ifort" but otherwise leaving the file the same, and while it runs to completion the exectuable still does not run properly. I have also tried generating a solution in Visual Studio that uses all the files but rxns.f and jacrxns.f in a console application project, and then have added two more projects to the solution, one for rxns.f that builds a static library rxns.lib, and one for jacrxns.f that builds another static library jacrxns.lib. This way does not compile, and I get LNK2019 errors from the lines in rteqnv25.f that import the rxns and jacrxns .dlls. I am not entirely sure why the makefile only uses .f files and .lib files, but requires the use of .dll files to run properly. 

As far as I can tell, it seems like RT3D begins running in GMS but fails to locate the main run file, and I feel this is more a consequence of how I have built the solution then a problem with the code.

I apologize in advance for my naivete on the subject, but I am hoping that someone can help point me in the right direction. 

As for the reason I want to recompile the executable, it is because I am trying to institute changes in the program that are not possible in just the two .dll files, and if I can actually modify the source code I am confident I can get these changes to work properly.

I have included a ZIP of the makefile originally built for CVF and the fortran source files below, as well as the executable that DOES work in GMS.

[Steve_Lionel]

I took a look at what you provided, but with no information as to what "does not run properly" means, exactly, and what this GMS application does, I've reached the end of what I can do.

I'll comment that one does not link to .dll files - rather, you link to the .lib created when a DLL is built. That is why there is no reference to the DLL in the makefile. 

[Mason6]

Thanks for the quick reply Steve,

My apologies for the vague nature of "does not work." My guess is that the .dll is not referenced properly and therefore causes the program to not execute as it should. I noticed when running Dependency Walker on the original .exe file that RXNS.DLL is one of the dependencies, but this is not the case in the executable I have created, perhaps indicating that it is incorrectly set up/linked. 

Thank you for the clarity on the .lib versus .dll linking. At this time, I have a solution that references all 12 .f files excluding the rxns.f and jacrxns.f files and have then added two DLL projects to the solution (one called rxns that has rxns.f in it, one called jacrxns that has jacrxns.f in it). Am I correct in thinking that making these DLL projects build dependencies for the executable project, I am achieiving the correct link to the .lib files? Or would I need to make these two projects static libraries so that they export .lib files? I have just made another visual studio file with the two projects as DLL projects rather than static libraries and I do not receive the same LNK2019 errors as when the two projects were static libraries. 

I think I am pretty close to the "correct" solution, I am just linking the files improperly. I appreciate all your help.

[Steve_Lionel]

You build the DLL as a DLL project. Because the source contains a DLLEXPORT directive, the linker will create both the .dll and the .lib "export library" (also called an import library!) That's the .lib your main project should link to. Make sure you build everything as a Release configuration, not Debug.

[Mason6]

Thanks again Steve. 

Is this linking process between my main project and the .lib an automatic process when I list the .dll projects as build dependencies for the main project, or do I also need to state them as additional dependencies? 

Thank you very much for your help. 

[Steve_Lionel]

The .lib will be linked automatically if it is from a dependent Fortran project.

[mecej4]

What is missing from the discussion so far is a description of how the two DLLs and the EXE, after having been built, are going to be invoked from GMS application, batch files, etc. If the communication between GMS and RT3D is through text files for data and batch files for starting processes, as I suspect based on what you have written, the steps below should suffice.

Building the two DLLs and the EXE is almost trivial. The following commands will build two 64-bit DLLs and a 64-bit EXE using the current version of Intel Fortran, after opening a 64-bit Intel OneAPI command window from the Start menu. In the third command, "rt3dv25.f" should come before the others since it defines a module that is used by some of the others. Other than that, the order of the Fortran source file names is arbitrary.

ifort /LD rxns.f
ifort /LD jacrxns.f
ifort rt3dv25.f adv30d.f btnrtv25.f dsp30d.f fmi30d.f gcg30d.f rteqnv25.f rtrctv25.f solv*.f ssmrtv25.f utlrtv25.f rxns.lib jacrxns.lib /Fert3d

Similarly, from a 32-bit Intel OneAPI command window, the same commands will produce 32-bit DLLs and a 32-bit EXE.

The EXE (32- or 64-bit) seems to start running properly:

 RT3D -- Reactive Transport in Three Dimensions
  [Release 2.5  ::  Build 2003-Feb-03]

  Developed by:  RT3D Development Team
   Lead Author:  Dr. Prabhakar Clement

  Enter the name of the RT3D super file

Your makefile will not work because it contains 8 spaces instead of a single tab character at BOL (beginning of line)s.

The EXE that you have in your Zip, rt3d25.exe, was built in 2019 using CVF, and contains the following string.

@(#)Compaq Fortran RTL Message Catalog  V1.1-24 13-Oct-2000

[cean]

This is the right one.

Enter the name of the RT3D super file

Need a rts file. Like this: https://www.pnnl.gov/sites/default/files/media/file/RT3D_Examples.zip

Example 1:

RT3DSUP
BTN "Ex_1.btn"
FLO "flow_88.hff"
ADV "Ex_1.adv"
DSP "Ex_1.dsp"
SSM "Ex_1.ssm"
RCT "Ex_1.rct"
CHK Y
OUT "Ex_1.out"
CON "Ex_1.con"
MAS "Ex_1.mas"
SPC "BTEX" 1 1
SPC "Oxygen" 2 1

 But flow-88.hff is not provided. It seems you need to use GMS to generate. 

[Mason6]

Thank you for the thorough response. I was also able to recompile both a 32- and 64-bit version of the program and they both load as in your example, but I always get stuck at the load screen.  

However, it seems that the issue is not within the compiler, but within GMS. I reached out to the company responsible for distributing that program, and they assure me that they build using the same version of RT3Dv2.5 that has been around for the last 20+ years, but it seems likely that some change has occurred in the source code since its original publication. The fact that the executable in the folders and that I originally included in the zip file was compiled in 2019 rather than in 2003 at the date of RT3Dv2.5 publication suggests that there has been some alteration to the code, potentially to allow it to play nicer with GMS.

As for what Aquaveo tech support was able to provide, it seems that the RT3D "super file" is built when I run my version of RT3D, which indicates that the original processes in the source files (encoded in adv30d.f, btnrtv25.f, dsp30d.f, etc) are occurring, even when run through GMS, but what is failing is the ability for GMS to then read this data into the GUI. As far as I know, the files are created properly, but I don't know enough about GMS to make the RT3D files interact properly with GMS.

As a side note, I reached out to Aquaveo and also asked if they could furnish me with original source files, but they directed me to just redownload the GMS program, which will just yield an executable. I also consulted the publishing website of RT3D (it is out of PNNL in Washington State) and only an executable is available there as well. It seems that the interest in recompiling the program is practically non-existent, and as a result it is very difficult to obtain current versions of the source. 

I appreciate everyone's help, but it seems to me this has gotten to be less of an Intel programming question and more of an archived software issue. 

[mecej4]

Let us simplify things a bit. I do not have GMS or know anything about it. I do not yet know how it uses the EXE and the DLLs that we have discussed earlier.

One possibility is that GMS does not use the two DLLs at all, and that they are a convenient way of using different versions of the user defined subroutines rxns.f jacrxns.f from the EXE without rebuilding the EXE whenever the user defined subroutines are changed.

I attach a monolithic EXE that I built with CVF6.6 using all the sources that you provided, after disabling the DLLEXPORT/DLLIMPORT directives. See if it works (using your definition of "works"; make allowance for the fact that using your user defined subroutines will probably give numerical results that differ from those that the EXE built in 2019 produces) from GMS. If it does, we can try similar EXEs built using Ifort/Ifx, 32 and 64-bit, and we will know more of how GMS uses the EXE and DLLs.

To use my attached version, save the Zip file, backup/move your working copy of  rt3d25.exe to a safe location, then unzip and rename the extracted EXE as rt3d25.exe in the directory where GMS expects to find it. Now run GMS as you did before.

Since this is an EXE from someone that you may not trust, take precautions before using the EXE.

[Mason6]

I went ahead and ran the executable prior to placing in the GMS directory and got the error message attached. It seems I am missing on the resource .dlls used in executing the file. When run from GMS, the executable also aborts immediately. 

As per your suggestion, I went ahead and commented out the DFLIB and DFPORT comments used in rt3dv25.f, as well as commented out the DLLIMPORT and DLLEXPORT directives used in rteqn25.f, rxns.f, and jacrxns.f. It seems that these are necessary for the executable to run however, as I get the second error attached when running this executable. My understanding is that when not referencing the reactions in rxns.f and jacrxns.f, RT3D (and therefore GMS) still need them as dummy arrays/variables to run properly.

As a note just in case it is helpful, I have attached a screenshot of the RT3Dv2.5 update manual that was supposed to give directions on how to convert the source code from non-.dll using to .dll using. These are the changes I rolled back in the second of the above tested configurations (the one you did not provide). Perhaps it gives some guidance on how RT3D is using the executables. With these changes made, RT3D is supposed to be able to use just the newly recompiled DLLs instead of requiring its own recompile. As a reminder, I have been able to recompile these DLLs and use them in GMS, it is just when I recompile the entire executable that the program no longer works as expected. 

[mecej4]

The error in CVF-Configuration.png is a result of not having the CVF runtime DLLs installed and accessible through PATH. The second, "Non Dll....png", is usually the result of a 32-bit/64-bit DLL mismatch.

We may expect reasonably that a commercial vendor of a current software product would provide DLLs and EXEs that were produced using a Fortran compiler more recent than the two-decades old CVF.

[JohnNichols]

What about if the Fortran coder has died and the vendor keeps selling it. 

I have one of those at the moment, I am just praying it continues to work till I die.  

The old Fortran programmers are getting older.