SWAT Bug in Reading CHM file

SWAT Bug in Reading CHM fileIf you are dealing with more than 6 soil layers, be cautious on the water quality outputs. A bug in SWAT would have impact on the initial N/P in soil and in turn would have impact on water quality in the main channel.

Description

Initial soil N/P could be set in CHM files for up to 10 soil layers. By default, NO3, organic N and organic P is set as 0 mg/kg, which means SWAT would calculate the initial concentration based on organic carbon and depth. Soluble P is set as 5 mg/kg by default.

 Soil Layer               :           1           2           3           4           5           6           7           8           9          10

 Soil NO3 [mg/kg]         :        0.00        0.00        0.00        0.00        0.00        0.00        0.00        0.00        0.00        0.00

 Soil organic N [mg/kg]   :        0.00        0.00        0.00        0.00        0.00        0.00        0.00        0.00        0.00        0.00

 Soil labile P [mg/kg]    :        5.00        5.00        5.00        5.00        5.00        5.00        5.00        5.00        5.00        5.00

 Soil organic P [mg/kg]   :        0.00        0.00        0.00        0.00        0.00        0.00        0.00        0.00        0.00        0.00

 Phosphorus perc coef     :       10.00       10.00       10.00       10.00       10.00       10.00       10.00       10.00       10.00       10.00 

Following codes are used to read above values in readchm.f, where mlyr is the maximum number of soil layers.

      read (106,5100,iostat=eof) (sol_no3(j,ihru), j = 1, mlyr)

      read (106,5100,iostat=eof) (sol_orgn(j,ihru), j = 1, mlyr)

      read (106,5100,iostat=eof) (sol_solp(j,ihru), j = 1, mlyr)

      read (106,5100,iostat=eof) (sol_orgp(j,ihru), j = 1, mlyr)

      read (106,5100,iostat=eof) (pperco_sub(j,ihru), j = 1, mlyr)

      ………………………

      5100 format (27x,10f12.2) 

The problem is on mlyr. It’s not the actual number of soil layers, which is sol_nly. It’s value could exceed 10 since SWAT adds 4 on top of it in getallo.f shown below.

!!    septic change 1-28-09 gsm

      mlyr = mlyr + 4

!!    septic change 1-28-09 gsm

For my case, the mlyr is 14 and SWAT would try to read 14 values from CHM file for initial soil N/P. As there are only 10 values in each record, SWAT would go to next record to get additional 4 values. Thus, one read function would read 2 data records in CHM file. The values it’s reading are not the values they are set. Organic N would be 5 mg/kg rather than 0 mg/kg. This will cause much less organic N compared to the one calculated from organic carbon.

Solution

The solution would be simple: replace mlyr with sol_nly. sol_nly is the actual number of soil layers and has been used in read soil parameters from SOL files (readsol.f). It never exceeds 10.

Advertisements