tillf / wasa-sed Goto Github PK

check routing

read maxsoter, maxterrain, maxsoil, maxhori, ntrans from structure of inputfile rather than from maxdim, nveg, nsoil

Currently, each optional output file requires the respective variable and a corresponding flag variable.
This could be generalized by a single array holding the flag, its name (name of outout file) and potentially a pointe to the respective variable. This would also facilitate adding new vars and simplify the output routines.

Reservoir output for a specific subbasin is written even when for this subbasin values in subbasin_out.dat are given. This could lead to confusion. Check for computationally relevant side-effects.

idem

Describe the bug
sediment_subbasin (in daily_sediment_production.out) affected by river routing mode

To Reproduce
e.g. in "Test-Sedrouting" from Anne

When running WASA in debug mode (compiled with make DEBUG=1 all), a floating point exception occurs:

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

Backtrace for this error:
#0  0x7FAE52938E08
#1  0x7FAE52937F90
#2  0x7FAE520694AF
#3  0x7FAE52646CD4
#4  0x7FAE5264BC04
#5  0x5C938F in reservoir_ at reservoir.f90:535 (discriminator 16)
#6  0x65D819 in routing_ at routing.f90:199
#7  0x678467 in MAIN__ at wasa.f90:31 (discriminator 1)

This is caused by a problem in file reservoir.f90 when trying to estimate parameters for the spillway rating curve. When using the old default parameters from file reservoir.dat, parameter 'damb' is always greater zero which causes 'alpha_over' being a negative fractional number causing a fpe during calculation of 'k_over'. This problem only becomes obvious when compiling with DEBUG flags but yet it is always present, potentially causing erroneous calculation of spillway outflow from reservoirs.

One would have to check when this rating curve was introduced and whether this is a problem of parameterisation or wrong implementation of a formula.

(allows access to already opened files, done for climo-files)

control files (do.dat, erosion.dat) are still mainly parsed by specific line order. Some kind of key-value-pairing would be more flexible and less error prone.
Likewise, they could be structure better (Hill,river, reservoir;hydro, ero).

Consider flow times within hillslope elements.
Variable interconnection between SVCs, e.g. by parameterizing aggregation of SVCs or interconnection matrix.

...to account for convergent hillslopes and better representation of areal coverage.

When providing intake_*.dat files (in directory Reservoir/ according to the documentation), the model should use the values given therein as bottom outlet from the specified strategic reservoirs. However, when examining the reservoir output res_*_watbal.out, the generated values for bottom outlet do not correspond to values given in intake_*.dat but rather to the parameterisation given in reservoir.dat. It seems the model is not using the given intake_*.dat files.

remove suspected redundancy of redundanz deepgw_r, gw_recharge

...using the IDs. Implemented for soil_particles.dat, rainy_seasons.dat, c_seasons, climo-files (except rain_hourly)

Currently, only the river variables for Muskingum routing are saved

Currently, total sediment is being routed without consideration of its constitution

eliminate redundancies, strict relational database scheme akin to LUMP structure

some output files still use fixed format and/or spaces for delimiters. Using Tab is more robust when using field descriptors with spaces and for easy drag-and-drop to spreadsheet applications.

Hi,
I really didn't want to post this but after quite some time trying to fix this problem i am writing here to see whether you'd have the solution... im not that familiar with compiling but anyhow:

I use cygwin on a windows machine and try to compile the source code... but there seems to be an issue with the paths of the update_revision_no.bat file- i tried to get my head around it without success so far...

Replace the *.var files in the source code (containing allocations of allocatable variables) by proper fortran files.

multiple Subbasins could use the same climate series

currently only achieved via workarounds

It is created, though.

(relates to #40)

literature:
- Project "Hydraulic Characteristic and Discharge Estimation for Flooding River" http://redac.eng.usm.my/html/projects/ESG/ESG.html
- M.F. Lambert, R.H.J. Sellin: DISCHARGE PREDICTION IN STRAIGHT COMPOUND CHANNELS USING THE MIXING LENGTH CONCEPT
- Christodolou G.C. and W.R.C. Myers. (1999). Apparent Friction Factor on the Flood Plain-Main Channel Interface of Compound Channel Sections, Proceedings of 28th Congress of the International Association for Hydraulic Research, Craz, Austria, SE3, A379.
- Fredrik Huthoff et al 2008 (http://scitation.aip.org/getabs/servlet/GetabsServlet?prog=normal&id=JHEND8000134000008001158000001&idtype=cvips&gifs=yes&ref=no)

compiled code with gfortran 4.8 with flags: (see Makefile or compiler documentation for descriptions)
-Wno-maybe-uninitialized
-Wtabs
-fbacktrace
-g
-fcheck=all
-Wall
-Wextra
-fimplicit-none
-ffree-line-length-none

warnings not yet fixed:

• lots of warnings like: 'Warning: Equality comparison for REAL(4) at (1)'
  • not sure if this is relevant
  • quite new to gfortran (since 2012?) within -Wall flag
  • in internet: discussions whether this is important but it might cause unexpected behaviour
  • unexperienced programmers should resolve the warnings
• some warnings like: 'Warning: Legacy Extension: Label at (1) is not in the same block as the GOTO statement at (2)'
  • not sure if this is relevant
• hymo_all.f90 line 975: runtime warning: An array temporary was created
  • not sure what to do and what that means

Pedro's / Conrad's options for TC-wise output should be unified (open_subdaily_output_TC), see snow branch (https://github.com/ERottler/WASA-SED/tree/WASA-SNOW)

Check proper initialization of
r_storage
river_sediment_storage
riverbed_storage
sed_storage
when no input file (*.stat) is present. It seems there is a problem (doloadstate=F, dosavestate=T).

--

--

SOTER -> LU
Mun(icipality) -> subbasin

Nbrsoil enthält die Anzahl der Böden in einer TC. Dies muss eigentlich nicht für jede subbasin-LU-TC-Kombination extra gespeichert werden, sondern nur einmal für den TC-Typ. Ebenso bei Rocky (enthält Anteil an Felsen in einer TC). Ebenso ID_soil_intern. Ebenso horiz_thickness, svcrooth, svcbedr. Bei Speicherbedarf, umbauen, Außer horiz_thickness, die sich ggf. durch Erosion verringern könnte

If parameter vol0 in Reservoir input file reservoir.dat is larger than storage capacity, NaN is produced for overspill and, thus, the reservoir and subbasin outflow for the first time step. I guess this results from a problem of missing overspill storage during the calculation of overspill at the very first simulation timestep.

(relates to #40)
The UHG-routing writes the delayed fractions of runoff to sections of riverflow in the future. These values are currently lost when the end of simulation is reached, ie when resuming from this end, their effect is absent.
Solution: Store/load qout(d+(1:length(hrout),:) at end/beginning of simulation.

Currently the the old UHG routing works only in daily resolution. Even if the model is run in hourly resolution, soil-vegetation processes are calculated per hour and discharge is routed only once per day.

File output is a major time issue. However, larger buffers require more memory and less tracability of crashes. (Automatic) configuration of output intervals would be nice.

...instead of builtin Fortran crash messages

*._t contain the fluxes in model resolution. Ideally, these should just be aggregated (if required) prior to output. I think they are not mandatory (or shouldn't be) in the rest of the code.

Various passages in the code have been commented with "ii", indicating that performance could be increased there.
(vectorize array assignments, use implicit loops for file output)

Consideration of wind is already prepared in code, just needs loading a respective file.

...where sensible.
[partially accomplished]

*.doc is troublesome for those without Word. Changes are harder to track.

Solutions:
1 github wiki
2 github io-pages

1. easy editing, straightforward access
2. version control, option to download the markdown document as a substitute for an offline docu

--> option 2 preferred, assign to SHK

As it seems, the parameter 'fvol_over' of reservoir.dat is wrongly described in the documentation.

The documentation says:

Fraction of storage capacity that indicates the minimum storage volume for water release through the spillway of the sub-basin's reservoir [-]

whereas in the source code reservoir_h.f90, line 31 it is written:

flag to simulate reservoir routing during spillway overflow of the sub-basin's reservoir [0 = without time delay; 1 = with time delay]

I discovered it because, when setting the parameter to a real number, an error was thrown as it declared as integer in the source code. This should be clarified.

Cheers,
Tobias