Unable to render {include} The included page could not be found.

Import use cases

  • Import in project as data item; import a (complete) Sobek 2.11 MDB
    • user selects import from file menu
    • user selects data type from available types
    • user specifies data source
    • user selects (parts of) the data geographically or with time interval
    • (selected) data is imported into project and added to project as data item.
  • Import for specific/selected data item
    for selected object in project
    or selected object on map ...
    • user specifies data source
    • user selects (parts of) the data geographically or with time interval
    • (selected) data is imported into project and added to project as data item.

Import existing Sobek model database (MDB)

Version of Sobek MDB that will be imnported by plugin is set to: 2.11
and the following objects are read:

  • node
  • branch
  • cross section
  • friction
  • boundary conditions
  • laterals

Conv_sbk is existing software that can import various formats; reuse is a consideration.
After conferring with knowledgeable people, reviewing the source the following arguments against reuse of the Conv_sbk source were found:

  • dependency to Netter
  • quality of coding
  • end of life of VB6
  • procedural design (not OO)
  • necessity to inflict serious adaptions to source for mapping to DelftShell data model
  • only a fraction of the source code is of interest, namely the parts that actually read and hence have implicit knowledge of the structure of data

Hence it is decided to reimplement the 'readers' in .NET. When applicable implicit knowledge about structure from the Conv_sbk is reused.

The the tool of choice for implementing readers is LEX; contrary to existing reader implementations, with LEX we can define readers in a language independent, reusable industry standard notation.
A C# version of LEX is found in the free product GPLEX. Some first test in DS development environment were successfull.
ANTLR might be an alternative to GPLEX. ANTLR offers both a lexical and syntatical analyzer where GPLEX can only build a lexical analyzer.

TODO

  • choose between GPLEX and ANTLR:
    ANTLR is a more complex environment. It is able to generate both lexical and syntatical automatons; we only need the lexer. At this early stage gplex seems more lightweight and does not carry in any redundant component, does what we want from it, is fitted into the dev and build environment.

The approach is to start with implementing a full Sobek 2.11 MDB import in a time period of 20 days (40 fpe). After this period the experience will be applied to estimate the remainder of this sub project.

node

Import of node from NETWORK.TP has been implemented using gplex. Special type of node: linkage node is interpreted as node.

net-file (topography layer)
 

This file contains the date for the topography: the definitions and positions of the nodes and branches.

The node definition:

NODE id '1' nm 'Node1' px 11404.2 py 123768.5 node Note: Fixed order
Where:
id = node id
nm = name of the node 
px = position X (X coordinate)
py = position Y (Y coordinate)

The branch definition:
BRCH id '1' nm 'Tak1' bn '1' en '2' al '1233.4' brch Note: Fixed order
Where:
id = branch id 
nm = branch name 
bn = id begin node 
en = id end node
al = actual length

Linkage nodes are described in NDLK records. A linkage node is handled as a normal calculation at the actual reach. The linkage node can be used as a start or end connection node for another reach. For the actual reach, this linkage node should also be decribed in the grid layer, at the same position at the reach.
NDLK id '125' ci 'RIV_350' lc 25261.4 ndlk
id = id of linkage node
ci = reach id, where the linkage node is handled as calculation point
lc = location at the reach

branch

branch is imported from NETWORK.TP
geometry of the branch is stored in NETWORK.CN

BRCH id '1' cp 1 ct bc  Note: Fixed order
TBLE ....
tble
brch

Where:
id  = branch id, 
cp  = number of curving points 
ct bc  = curving point table 
TBLE ... tble  = Table with 'curving points: 
column 1 = location on the branch in meters
column 2 = angle (0 = north, 90= east)

remark: the location in column 1 is the location at the center of the branch, not the starting point of the branch. The number of curving points is not stored correctly so it has to be derived from the number of entries in the table.

Dry bed procedure is currently not imported. An example is needed.

This file contains the information for the 'dry bed procedure' in the flow module of SOBEK Rivers (NOT for SOBEK Urban/Rural). The data is necessary for each branch.

BRCH id '1' db 1 th 0.01 sh 10.0 brch

Where:
id = branch id,
db = dry bed procedure active (1) or not (0)
th = threshold
sh = slot depth (depth Preismann)

Cross section

cross section information is stored in a number of files.

NETWORK.CR stores the location of the cross sections along the branch. (import of STON records not implemented)

net-file (cross section layer)
This file contains the definitions of the cross-section locations.
If the file version is 1.1 or higher (CR_1.1 in the first line), also records indicating the nodes with storage are written to the file.
The cross-sections are defined using the CRSN record.
CRSN id 'c1' nm 'crossdef1' ci 10 lc 250.6 crsn  Note: Fixed order
Where:
id = id of cross-section location
nm = name of cross-section definition
ci = carrier id (branch id)
lc = distance from the beginning of the branch
The storage nodes is defined using STON record.
STON id '2' ci '1' lc 0 st 'Normal' ston
Where:
id = node id
ci = dummy
lc = dummy
st = dummy
Only the node id is used, but all record keywords must be present and have a (dummy) value.
If no STON record is written for the node, then the storage as defined in the file nodes.dat should be skipped.
In the old definition of the file (version 1.0) all storage data on nodes is always used, although the actual node type in the User Interface does not suggest this functionality.

PROFILE.DAT

Dat-file (cross section layer)

This file contains a reference to the cross-section definition and information about the relative height of the cross-section.
 
CRSN id 'crossloc1' di 'crossdef1' rl -0.5 ll -0.4 rs 0.9 ls 0.9 crsn Note: Fixed order

Items in one record; ll, rs and ls optional, separated by 1 or more blanks

Where:
id = id of cross-section location
di = id of cross-section definition
rl = reference level 1 (SOBEK Rivers/Rural: level at the cross-section; SOBEK Urban/Rural: level at the end of the pipe)
ll = reference level 2 (SOBEK Urban/Rural: level at the beginning of the pipe)
us = upstream slope (not in SOBEK Urban/Rural)
ds = Downstream slope (not in SOBEK Urban/Rural)
rs = Surface level right (same units as rl) 
ls = Surface level left (same units as rl) 
 
In SOBEK-Rivers a bed-level (code bl) was already given for the cross-section descriptions (except for the tables, here it is given in the table itself). In addition, a local reference level rl at the cross-section needs to be given.
 
In SOBEK Urban/Rural however, it is not possible to give a bed level for every cross-section description. In this case, the bed level is given when placing the cross-section on a reach (pipe) by means of the keywords rl and ll. These keywords give the bed levels of the bottom of the pipe at the end and the beginning of the pipe, so that the slope is determined by the length of the pipe and the difference in height rl-ll.
 
In SOBEK-Rivers, rl stands for the reference level at the location of the cross-section, while the slopes on the left and right side can differ. In the case of more cross-sections on one branch, the bed level slope between the cross-sections is assumed to be constant (based on the bed levels at the cross-sections corrected for local reference levels). For interpolation of the cross-sections both the up- and the downstream slopes are used. 
 
In SOBEK-Rural for open water, only rl is used and interpreted the same way as in SOBEK-Rivers.

PROFILE.DEF (currently we only import tabulated cross section ie tabulated and yz table )

def-file (cross section layer)

This file contains the descriptions of the cross sections. SOBEK River distinguishes 3 sections while SOBEK Urban/Rural only distinguishes 1 section.
 
The following types of cross sections are considered:
 
0. tabulated
1. trapezoidal
2. open circle
3. sedredge (2D morfology)
4. closed circle
5. 
6. egg shaped (width)
7. egg shaped 2 (radius) not implemented
8. closed rectangular not implemented
9. 
10. yz table 
11. asymmetrical trapeziodal
 
 
 
0. Tabulated cross section
 
CRDS id 'Crdef1' nm 'Tabel1' ty 0 wm 86.23 w1 0 w2 0 sw 0 lt lw
TBLE
-2.55 16.80 16.80 <
-1.00 30.13 30.13 <
-0.65 30.13 30.13 <
 0.00 86.23 86.23 <
tble
dk 0 dc 99999. db 99999. df 99999. dt 99999.
gl 0.5 gu 0
crds
 
 
Where:
 
id  = cross section definition id
nm  = cross section definition name
ty  = type cross section (0=table)
wm  = width main channel
w1  = width floodplain 1 (used in River profile only, else value = 0)
w2  = width floodplain 2 (used in River profile only, else value = 0)
sw  = sediment transport width (not in SOBEK Urban/Rural) 
Default 0. Only important for module sediment/morfology 
lt lw  = table for table profile between keywords TBLE and tble; the table contains height, total width en flowing width.
dk  = summer dike (1 = active, 0 = not active) (in River profile only)
dc  = dike crest level in River profile only()
db  = floodplain base level behind dike (in River profile only)
df  = flow area behind dike (in River profile only)
dt  = total area behind dike (in River profile only)
gl    = ground layer depth (meter relative to bed level)
gu   = ground layer to be used within hydraulics calculation (1) or not (0).
 
 
 
1. Trapezoidal cross section
 
CRDS id 'Crdef2' nm 'Trapezium' ty 1 wm 86.0 w1 0 w2 0 sw 0 bw 10 bs 0.5 aw 100 gl 0.5 gu 0 crds 
 
 
Where:
 
id  = cross section definition id
nm  = cross section definition name
ty  = type cross section (1=trapezium)
bl  = bed level
wm  = width main channel
w1  = width floodplain 1 (in SOBEK Urban/Rural always 0)
w2  = width floodplain 2 (in SOBEK Urban/Rural always 0)
sw  = sediment transport width (not in SOBEK Urban/Rural) 
Only important for module sediment/morphology (River)
bw   = bottom width
bs   = bank slope (horizontal/vertical)
aw   = maximum flow width 
gl  = ground layer depth (meter relative to bed level)
gu  = ground layer to be used within hydraulics calculation (1) or not (0).
 
 
2. Open circle cross section:
 
CRDS id 'Crdef3' nm 'Opencirkel' ty 2 rd 5 gl 0.5 gu 0 crds
 
 
Where:
 
id  = cross section definition id
nm  = cross section definition name
ty  = type of cross section (2=open circle)
bl  = bed level
rd  = radius
gl  = ground layer depth (meter relative to bed level)
gu  = ground layer to be used within hydraulics calculation (1) or not (0).
 
 
Note: This profile cannot be used for sediment calculations (Rivers). A table should be used instead.
 
 
3. Sedredge cross section:
 
Only for 2D morphology calculations(SOBEK Rivers). 'left' means main channel, and 'right' is the floodplain.
 
CRDS id 'Crdef4' nm 'Sedredge' ty 3 ll 3 rl 2.5 lw 10 rw 5 crds
 
 
Where:
 
id  = cross section definition id
nm  = cross section definition name
ty  = type cross section (3=2D morphology sedredge profile)
ll  = left bed level
rl  = right bed level
lw  = left bed width
rw  = right bed width
 
 
4. Closed circle cross section: (only SOBEK Urban/Rural) 
 
CRDS id 'Crossdef5' nm 'Geslotencirkel' ty 4 rd 4 gl 0.5 gu 0 crds 
 
 
Where:
 
id  = cross section definition id
nm  = cross section definition name
ty  = type cross section (4=closed circle)
bl  = bed level
rd  = radius
gl  = ground layer depth (meter relative to bed level)
gu  = ground layer to be used within hydraulics calculation (1) or not (0).
 
 
 
6. Egg shaped cross section: (only SOBEK Urban/Rural) 
 
CRDS id 'Crossdef6' nm 'Ei' ty 6 bo 0.5 gl 0.5 gu 0 crds 
 
 
Where:
 
id  = cross section definition id
nm  = cross section definition name
ty  = type cross section (6=egg shaped)
bl  = bed level
bo  = bottom width profile; 
For this profile, the height is considered to be 1.5 * the width.
gl  = ground layer depth (meter relative to bed level)
gu  = ground layer to be used within hydraulics calculation (1) or not (0).
 
 
10. yz table cross section: (only SOBEK Urban/Rural) 
 
CRDS id 'Crdef' nm 'y-z table1' ty 10 st 0 lt sw  0 12.0 lt yz
TBLE
0.0  12.0   <
1.0   10.0   <
2.0   9.0     <
3.0   9.5     <
4.0   10.5   <
5.0   11.0   <
tble
gl  0.5
gu 0
crds
 
or
 
CRDS id 'Crdef' nm 'y-z table1' ty 10 st 0 lt sw 
TBLE
12.0  0 <
20.0  1 < 
tble
lt yz
TBLE
0.0  12.0   <
1.0   10.0   <
2.0   9.0     <
3.0   9.5     <
4.0   10.5   <
5.0   11.0   <
tble
gl  0.5
gu 0
crds
 
 
Where:
 
id = cross section (profile) definition identification 
nm = cross section (profile) definition name
ty = type of cross section (10 = yz table)
st = storage type 
0 = reservoir
1 = loss of water that is above surface level
lt sw 0 = storage width on surface in m
lt sw  = storage width on surface level as tabulated function of level above surface level in m (starting from zero).
lt yz = table for y-z values.  Y - horizontal distance increasing from the left to right , Z - vertical distance increasing from bottom to top in m. In other words, use a coordinate system to define the Y-Z profile.
gl = ground layer depth (meter relative to bed level)
gu = ground layer to be used within hydraulics calculation (1) or not (0).
 
11. Asymmetrical trapeziodal cross section: (only SOBEK Urban/Rural) 
 
CRDS id 'Crdef' nm 'Asymmetrical Trapezoidal1' ty 11 st 0 lt sw 0 12.0 lt yz
TBLE
0 .0  12.0   <
1.0   10.0   <
2.0   9.0     <
3.0   9.5     <
4.0   10.5   <
5.0   11.0   <
tble
gl  0.5
gu 0
crds

or
 
CRDS id 'Crdef' nm 'Asymmetrical Trapezoidal1' ty 11 st 0 lt sw 
TBLE
12.0  0 <
20.0  1 < 
tble
lt yz
TBLE
0 .0  12.0   <
1.0   10.0   <
2.0   9.0     <
3.0   9.5     <
4.0   10.5   <
5.0   11.0   <
tble
gl  0.5
gu 0
crds
 
 
Where:
id = cross section (profile) definition identification 
nm = cross section (profile) definition name
ty = type of cross section (11 = asymmetrical trapezoidal)
st = storage type 
0 = reservoir
1 = loss of water that is above surface level
lt sw 0 = storage width on surface in m
lt sw  = storage width on surface level as tabulated function of level above surface level in m (starting from zero).
lt yz = table for y-z values.  Y - horizontal distance increasing from the left to right , Z - vertical distance increasing from bottom to top in m. In other words, use a coordinate system to define the Y-Z profile.
gl = ground layer depth (meter relative to bed level)
gu = ground layer to be used within hydraulics calculation (1) or not (0).

Cross Section types in Sobek

0. tabulated
1. trapezoidal
2. open circle
3. sedredge (2D morfology)
4. closed circle
5. 
6. egg shaped (width)
7. egg shaped 2 (radius) not implemented
8. closed rectangular not implemented
9. 
10. yz table 
11. asymmetrical trapeziodal

After discussion with Edward: Initially

  • Tabulated/WH
  • YZ

friction

Friction data is contained in the file friction.dat

Friction can be defined for a branch a cross section or a floodplain
Friction is defined for positive and negative flow direction

We only import
friction in negative or positive flow direction
friction at cross section segments.

Friction.dat contains friction data for branches and cross sections

This file contains the bed friction data per branch.

For Channel Flow, Sewer Flow and River Flow:
BDFR id '1' ci '1' mf 7 mt cp 0 20 0 mr cp 0 20 0 s1 6 s2 6 sf 7 st cp 0 20 0 sr cp 0 20 0 bdfr
Fixed number of items in one record, separated by 1 or more blanks
Where:
id  = id of bed friction definition
nm  = name of the bed friction definition (not in SOBEK Urban/Rural)
ci  = carrier id = id of the branch
mf  = main friction type (main = main channel)
0 = Chezy
1 = Manning
2 = Strickler Kn
3 = Strickler Ks
4 = White-Colebrook
5
6
7 = De Bos and Bijkerk
mt  = friction in positive flow direction
mt fq = friction=f(Q)
mt fh = C=f(h)
mt cp = friction as a constant or as a function of the location on the branch
For fq, fh, and cp: a constant (entered as a table) or a real table:
0 = constant
1 = variable
The options fq and fh may have more dimensional tables:
column 1 =Q or h value, 
column n = friction value on different locations along the branch for every Q or h
Thus, the options fq and fh are a function of the location on the branch and Q (of h).

The option cp (friction as function of the location) has a two-dimensional table:
column 1 = location along the branch
column 2 = friction-coefficient
mr  = friction in negative direction:
mr fq = friction=f(Q)
mr fh = friction=f(h)
mr cp = friction as a constant or as a function of the location on the branch)
Option fq, fh, and cp may contain a constant given in a table or a table.
0 = constant
1 = variable
s1  = friction for floodplain 1 (not in SOBEK Urban/Rural)
can be either 'equal to main section', or Chezy/../Nikuradse. (0=Chezy,..,6=Equal to main section)
Note: Engelund cannot be used for the floodplains. 
s2  = friction for floodplain 2 (not in SOBEK Urban/Rural)
sf  = ground layer friction type (0 - 7 ) (for further details see description for mf)
st  = friction in positive direction 
st cp = (for all friction types, for further details see description for mt)
sr  = ground layer friction in negative direction
sr cp for all friction types (for further details see description for mt)
c1 cp,fq,fh = floodplain 1 friction coefficients (friction can be defined as a function of Q, of h, of the location or as a constant.
r1 cp,fq,fh = floodplain 1 reversed flow friction coefficients as a function of Q, of h, of the location or as a constant.
c2 cp,fq,fh = floodplain 2
r2 cp,fq,fh = floodplain 2 reversed flow
d9 f9 = D90
 
Same friction for both directions (for SOBEK-River only)
This feature is optional. It is defined by the flags em, er, e1, e2, e3, e4. If these flags are present (in this order) they should follow the carrier id (ci ' ') immediately. These flags are only used by the user interface. For the parser bed friction is fully defined by the keys mf etc.
 
BDFR id '33' nm '(null)' ci '31' em 0 er 0 e1 0 e2 0 e3 0 e4 0 mf 0 mt fh 3 50 9.9999e+009 'Chezy Coefficient Waterlevel' PDIN 0 0 '' pdin CLTT 'H' '603.5' cltt CLID '(null)' '(null)' clid 
TBLE 
-0.5 52.79 < 
0 49.69 < 
0.5 48.98 < 
1 53.66 < 
1.5 56.96 < 
2 65.4 < 
2.5 63.92 < 
3 62.03 < 
3.5 59.89 < 
4 59.02 < 
4.5 59.97 < 
5 59.68 < 
tble
mr fh 3 50 9.9999e+009 'Chezy Coefficient Waterlevel' PDIN 0 0 '' pdin CLTT 'H' '603.5' cltt CLID '(null)' '(null)' clid 
TBLE 
0 53.13 < 
0.5 49.9 < 
1 49.3 < 
tble
s1 0 c1 cp 0 35 9.9999e+009 r1 cp 0 35 9.9999e+009 s2 6 c2 cp 0 9.9999e+009 9.9999e+009 r2 cp 0 9.9999e+009 9.9999e+009 d9 f9 0 9.9999e+009 9.9999e+009 bdfr
 
 
Where:
 
em = flag for main section
1 = bed friction for negative flow equals the definition for positive flow
0 = different friction definitions for both directions
er = flag for main section
1 = bed friction for positive flow equals the definition for negative flow
0 = different friction definitions for both directions
e1 = flag for floodplain 1 
1 = bed friction for negative flow equals the definition for positive flow
0 = different friction definitions for both directions
e2 = flag for floodplain 1 
1 = bed friction for positive flow equals the definition for negative flow
0 = different friction definitions for both directions
e3 = flag for floodplain 2 
Same meaning as e1
e4 = flag for floodplain 2 
Same meaning as e2

Cross section related Friction
CRFR id 'fricid' nm 'Friction1' cs 'Crdef' 
lt ys 
TBLE
0.0 3.0 <
3.0 5.0 <
tble
ft ys 
TBLE
7 20 <
7 20 <
tble
fr ys 
TBLE
7 20 <
7 20 <
tble
crfr


Where:

cs 'Crdef' = cross section definition id (only for yz profile and a-symmetrical trapezoidal) to which this friction definition applies
lt ys = table for y values which defines the sections (in this case 2) within the profile for definition of friction, flow, etc. 
Number of rows defines the number of defined sections and value per row defines the start of a section and end of a section (horizontal distance increasing from the left to right ). For example, the first defined section starts at Y= 0.0 (including) till Y =3.0 (not including), and so on. Note: the defined sections should be based on the same coordinate system used in defining yz table. 
ft ys = table for friction values in positive direction for (in this case 2) sections (division) of cross section with friction type (0-7), constant friction value, the number of rows should be the same as number of sections defined in the 'lt ys'. 
fr ys = table for friction values in negative direction for (in this case 2) sections (division) of cross section with friction type (0-7), constant friction value the number of rows should be the same as number of sections defined in the 'lt ys'.


Structure Friction (for SOBEK Rural / Urban only)

STFR id '1'  ci 'Culvert1' mf 7 mt cp 0 20 0 mr cp 0 20 0 s1 6 s2 6 sf 7 st cp 0 20 0 sr cp 0 20 0 stfr

Fixed number of items in one record, separated by 1 or more blanks

 
Where:

ci = id of structure definition
mf  = main friction type (main = main channel)
0 = Chezy
1 = Manning
2 = Strickler Kn
3 = Strickler Ks
4 = Nikuradse
5 = Engelund
6
7 = De Bos and Bijkerk
mt  = friction in positive flow direction
mt fq = friction=f(Q)
mt fh = C=f(h)
mt cp = friction as a constant or as a function of the location on the branch
For fq, fh, and cp: a constant (entered as a table) or a real table:
0 = constant
1 = variable
The options fq and fh may have more dimensional tables:
column 1 =Q or h value, 
column n = friction value on different locations along the branch for every Q or h
Thus, the options fq and fh are a function of the location on the branch and Q (of h).

The option cp (friction as function of the location) has a two-dimensional table:
column 1 = location along the branch
column 2 = friction-coefficient
mr  = friction in negative direction:
mr fq = friction=f(Q)
mr fh = friction=f(h)
mr cp = friction as a constant or as a function of the location on the branch)
Option fq, fh, and cp may contain a constant given in a table or a table.
0 = constant
1 = variable
s1  = friction for floodplain 1 (not in SOBEK Urban/Rural)
can be either 'equal to main section', or Chezy/../Nikuradse. (0=Chezy,..,6=Equal to main section)
Note: Engelund cannot be used for the floodplains. 
s2  = friction for floodplain 2 (not in SOBEK Urban/Rural)
sf  = ground layer friction type (0 - 7 ) (for further details see description for mf)
st  = friction in positive direction 
st cp = (for all friction types, for further details see description for mt)
sr  = ground layer friction in negative direction
sr cp for all friction types (for further details see description for mt)
c1 cp,fq,fh = floodplain 1 friction coefficients (friction can be defined as a function of Q, of h, of the location or as a constant.
r1 cp,fq,fh = floodplain 1 reversed flow friction coefficients as a function of Q, of h, of the location or as a constant.
c2 cp,fq,fh = floodplain 2
r2 cp,fq,fh = floodplain 2 reversed flow
d9 f9 = D90
 
For Overland Flow:
 
D2FR id '1' nm 'Frictie1' ci '1' mf 0 mt cp 0 45 0 mw cp 0 45 0  d2fr
 
where:
id = bed friction definition id
nm = bed friction definition name (not available yet)
ci = carrier id = reach id
mf = main friction type (main = main channel)
0 = Chezy 
1 = Manning
4 = White Colebrook 
mt = bed friction 
mt cp 0 60 0 = all other cases 
(Chèzy / Manning etc. as constant or dependent on the location)
0 = constant
mw cp 2 'c:\sobek\fls_files\bedfrict.asc'   '  '
2 = file
mw = wall friction 
mw cp 0 60 0 = all other cases
(Chèzy / Manning etc. as constant or dependent on the location)
0 = constant
mw cp 2 'c:\sobek\fls_files\walfrict.asc'  '  '
2 = file

Extra resistance is not used in current sobek. Importing it is not implemented.

exr-file (friction layer)
This file contains the definition of 'extra resistance'.

 XRST id '1' nm 'exr1' ci '1' lc 20 rt rs 
 TBLE .. 
 tble 
 ty 0 xrst

Where:
 
id  = id of the extra resistance definition
nm  = name of the resistance definition
ci  = carrier id (=id of the branch)
lc  = location on the branch
rt rs  = table with extra resistance 
column 1 = water level
column 2 = extra resistance

Engelund friction and global friction (also in friction.dat)

glf-file (friction layer)

This file contains two groups of global data:
data necessary for the Engelund bed friction formula
global bed friction parameters
 
As these parameters are defined globally, they are not linked to any specific location.


GLFR dd 1.65 s1 0.474 s2 0.55 p1 -6 p2 2.75 p3 5.5 p4 4.125 p5 -0.2 p6 2.447 
a1 0.0005 a2 6e-005 ra 1 glfr

Where:
 
dd = delta D (global Engelund parameter)
s1 = sigma1 (global Engelund parameter)
s2 = sigma2 (global Engelund parameter)
p1 = as11 (global Engelund parameter)
p2 = as12 (global Engelund parameter)
p3 = as21 (global Engelund parameter)
p4 = as22 (global Engelund parameter)
p5 = as31 (global Engelund parameter)
p6 = as32 (global Engelund parameter)

a1 = alpha1 (for wind friction)
a2 = alpha2 (for wind friction)
ra = rho lucht (for wind friction)

Wind friction will become a globally defined set of parameters in sobek. It will not be allowed to use it specifically on branches. (reading not implemented yet)

wnd-file (friction layer)
This file contains information for calculation of the wind friction. Other information like the wind speed and direction s stored in the meteo-layer.
 
WNDS id '0' nm 'null' ci '0' lc 9.9E+009 sh ws 0 0 9.9E+009 wnds
or
WNDS id '1' nm 'null' ci '4' lc 9.9E+009 sh ws 2 
TBLE ... 
tble 
wnds
 
Where:

id = id of wind friction definition
nm = name of the wind friction definition
ci  = carrier id (id of the branch)
lc = location on branch (not used)
sh ws = wind shielding table
0 = constant
2 = variable as a function of the location on the branch
column 1  = location
column 2 = wind shielding factor (1=no wind shielding).
Global wind friction is indicated by the extra keyword GLFR ... glfr, with carrier id ci '-1'.

boundary conditions

laterals

Other

NETWORK.SA (reading not implemented)

This file contains extra data for the boundary-nodes in a estuarium-model, necessary for the salt module. Only SOBEK Rivers, NOT for SOBEK Urban/Rural.
NODE id '1' mt 0 node

Where:
id = node id 
mt = mouth
0 = boundary node does not have estuarium mouth
1 = boundary node does have estuarium mouth
This information is necessary for the choice of the formulation of the dispersion, when the Thatcher-Harleman of the 'user defined' option have been chosen. See dispersion layer for more information.

NETWORK.SM (reading not implemented)

This file contains the extra information necessary for the sediment/morphology module of SOBEK. Only SOBEK-Rivers, NOT for SOBEK Urban/Rural.
BRCH id '1' sd 0 fl 1 ft fl 
TBLE .... 
tble
rf 0 brch

Where:
id  = branch id
sd  = sedredge option
0 = no 2D morphology on this branch (default)
1 = 2D morphology on this  branch
fl  = fixed layer (1=active, 0=not active) 
ft fl  = fixed layer table (between keywords TBLE en tble)
The first column in the table contains the locations along the branch and the second column contains the layer.
rf  = reduction function
0 = sinus
1 = linear

NODES.DAT (reading not implemented)

This file contains data for the modelling of different kinds of storage for nodes in sewer calculations. Only SOBEK Urban/Rural, NOT River.

NODE id '1' ty 0 ws 1.0 ss 100.0 wl -4.05 ml -1.0 node

Where:
id = node id
ty = type water on street
1 = reservoir
2 = closed
3 = loss
ws = storage area (manhole)
ss = street storage area
wl = bed level storage reservoir (manhole)
ml = street level

NODE id '0-62' ty 1 ct sw
TBLE
16.28 2 <
20.84 2 <
tble ct ss
TBLE
20.85  100 < 
21.9  150 < 
tble  node

Where:

ct sw TBLE .. tble = table for storage in well
ct ss TBLE .. tble = table for storage at street

Free format import

This comes second in priority.
Free format import should comprise a wizard like interface in which the structure of the data to be imported is investigated and specified by the user interactively.
Hymos has a import wizard for importing time series:

3rd Party network formats

This comes third in priority. These are the formats currently supported by Sobek.

  • No labels

2 Comments

  1. Does ConvSbk not read "sobek network files" are they maybe read somewhere else. I assume sobek supports it's own file format (wink)

    • Can we avoid developing this from scratch?
    • How many days do you need in total?
    • Which file formats will we support?
    • In what order will you do what?
    • Do you require information from others?

    What is wizard functionality?

    GDAL and OGR allow to build a c# version http://trac.osgeo.org/gdal/wiki/GdalOgrCsharpCompile. I think this is also used in SharpMap (http://svn.wldelft.nl/repos/delft-tools/trunk/apps/DelftShellPlugins/SharpMapGis/lib/gdal_csharp.dll)

  2. Unknown User (don)

    The order of steps has to be:

    1. User selects external data source / file type.
    2. Import module provides list of supported items found in the external data source (probably just by extending IDataProvider by something like ImportFrom(string path);.
    3. If necessary - wizard is shown where user can customize import, filter what to import.
    4. Item(s) is(are) imported into the current project.

    See examples below: