Instructions on compiling swatplus with gfortran dynamic library (`libgfortran.so`)

[Atreyagaurav]

Hi,

Would it be possible to add instructions on how to compile swatplus with dynamic link to libgfortran.so instead of just the static option (libgfortran.a)?

I made it compile by removing the link_libraries("-static") lines in the CMakeLists.txt. But I don't know if that is the correct approach, or if it will break other things later.

Adding this information to the documentation on building SWAT, or adding a configuration options for people to choose dynamic/static linkage, would probably be useful.

When I ran the ctest command, I got an error with the following message in the log:

..... 
  Original Simulation            5   5  1990 Yr   16 of   46 Time  16:33:17
  Original Simulation            5   6  1990 Yr   16 of   46 Time  16:33:17
  Original Simulation            5   7  1990 Yr   16 of   46 Time  16:33:17
  Original Simulation            5   8  1990 Yr   16 of   46 Time  16:33:17
  Original Simulation            5   9  1990 Yr   16 of   46 Time  16:33:17

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:
#0  0x7f6529c3e4cf in ???
#1  0x7f6529f7383d in ???
#2  0x562a6fe5636f in ???
#3  0x562a6fb901a5 in ???
#4  0x562a6f820b58 in ???
#5  0x562a703e1ad9 in ???
#6  0x562a6fda08c1 in ???
#7  0x562a6fda0f37 in ???
#8  0x7f6529c27634 in ???
#9  0x7f6529c276e8 in ???
#10  0x562a6f4cd424 in ???
#11  0xffffffffffffffff in ???

SWAT+ exited with code: -8
Processing 'mgt_out.txt' in 
  (1) /home/user/git-packages/swatplus/data/Ames_sub1 and 
  (2) /home/user/git-packages/swatplus/build/data/Ames_sub1

Full log: LastTest.log

So I don't know if it is related to the compilation process, or if the test is broken due to other problems.

Context:

I was trying to compile swatplus in Arch Linux, and looks like it does not ship with libgfortran.a anymore, and to get the libgfortran.a file, I need to recompile the gcc tools, which takes hours. So I wanted to see if I could compile swatplus to use the dynamic library that is already available instead of the static one, and I did not find any documentation.

[Atreyagaurav]

Note: I thought there were no issues mentioning this problem before. But #123 seems to have gone through the same problem on Debian, although that is not the main topic of the issue.

[Atreyagaurav]

More info: I compiled it with debug information to see if the backtrace would be useful, this is the result I get from running the same trace.

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:
#0  0x7fe57fc3e4cf in ???
#1  0x7fe57ff7383d in ???
#2  0x55c6fcdc436f in nut_solp_
	at /home/gaurav/git-packages/swatplus/src/nut_solp.f90:69
#3  0x55c6fcafe1a5 in hru_control_
	at /home/gaurav/git-packages/swatplus/src/hru_control.f90:563
#4  0x55c6fc78eb58 in command_
	at /home/gaurav/git-packages/swatplus/src/command.f90:278
#5  0x55c6fd34fad9 in time_control_
	at /home/gaurav/git-packages/swatplus/src/time_control.f90:252
#6  0x55c6fcd0e8c1 in MAIN__
	at /home/gaurav/git-packages/swatplus/src/main.f90:142
#7  0x55c6fcd0ef37 in main
	at /home/gaurav/git-packages/swatplus/src/main.f90:3

The line in nut_solp.f90:69 is this:

plch = .001 * soil1(j)%mp(ly)%lab * (1. - Exp(vap))

I checked what the values are during evaluation. It fails in the Exp(vap) expression. But the value of vap at that time is -102.501633 and Exp(-102.501633) should evaluate to 2.80259693E-45 (tested this in an independent fortran program).

The minimum value real :: vap can have is 1.17549435E-38, so it is an underflow problem, I am guessing if ifx compiled version doesn't have it, it is caused by real being a different type there. We could probably fix it by changing the type real to a more explicit one that will be the same in both ifx and gfortran. Or a conditional check when vap is too negative (like this case).

With this change, the code no longer gives the floating point error (but there is a type problem here, I just did this to test the hypothesis above), but the test still fails with high amount of errors (rel and abs), so I don't know if something else is off.

modified   src/nut_solp.f90
@@ -30,7 +30,7 @@
       integer :: jj = 0      !none          |counter
       real :: xx = 0.        !none          |variable to hold intermediate calculation
                              !              |result
-      real :: vap = 0.       !kg P/ha       |exponential coefficient for P leached and tile flow
+      real(8) :: vap = 0.       !kg P/ha    |exponential coefficient for P leached and tile flow
       real :: plch = 0.      !kg P/ha       |amount of P leached from soil layer
       
       integer :: ly = 0      !none