Jump to content


Inactive members
  • Content Count

  • Joined

  • Last visited

Posts posted by cfrk

  1. Hi Ade,

    Is there a reason you haven't continued the1D pipe directly to the 1D channel? It might improve things if you extended the pipe to snap to the upstream end of the 1D channel, and then you could get rid of the 4 cn lines extending from the end of the 1D pipe (the 4 visible ones on the image). I assume there are also 2 cn lines obscured behind the most upstream cross section lines - these would be the only ones you'd need.

    The extended hx lines at the upstream end of the open channel may be causing problems also. It's probably better to only extend them as far as the edge of your 1D code boundary. You could wrap the hx lines around the upper end of the 1D channel though (so that they meet), to allow overland flow to fall straight back into channel (in line with flow) rather than being forced to approach from the sides.

    Having said all that it looks like it is quite a steep fall between the road and the 1D channel, which may be causing the problems...?



  2. Hi,

    It's probably of little use for any further comparisons as it wasn't a tutorial model, but I've run a model on 2 separate machines (I am by no means a computer hacker so I've probably missed the important specs), with the following run times:

    Intel Pentium ® D, 3.2GHz, 2G RAM = 11.6 hours

    Intel Core 2 Duo, 2.66GHz, 3G Ram = 7.2 hours

    It was definitely worth testing, as the second PC was being somewhat under-utilised in reception...

  3. Hi Bill,

    I'm using 2009-07-AD (not the latest release but I'm keeping things consistent across model runs). The model is quite large (4 separate watercourses, roughly 24 hour run time) and was built by others - we are only interested in a small section of one of the rivers.

    We are trying to add proposed developments (in the form of a raised development plateau as well as the conversion of a culverted section of watercourse to open channel) - when I made these changes to the original model it went unstable at a location well away from the development. Rather than start trying to fix problems in the wider model, it seemed simpler to crop the model to our area of interest - hence the addition of PO lines to use as inflows for a cropped version of the model.

    So the only change I made was to add PO lines to the original model, which caused the flood wave to occur...? Something to do with rounding up/down when writing outputs maybe?

    It's a very large model so will be a bit of pain to try to send unfortunately! I've done a bit of a estimating and interpolation in the meantime to get inflows without the flood wave, so have side-stepped the problem, but would be good to clear up why this is happening...



  4. I think Tuflow probably needs a non-zero area for it's calculations, and so there will be a very small amount of flow. I've seen a similar occurrence when using a 100% blockage - the .eof shows an area of 0.02 for the culvert, velocity is around 0.5m/s and flow is 0.008m3/s.

    In my case it didn't significantly affect results, but I guess if you really needed absolutely zero flow you could always remove the culvert completely...



  5. Hi Danny,

    You should specify "75" in the pBlockage attribute to signify a 75% blockage.

    I think the wording should read that the pipe diameter is reduced by the square root of (1 - B ), where B is blockage as a proportion. i.e. in this case, the radius would be reduced by sqrt(1-0.75) = 0.5.

    You can double check that the pipe area in your blockage run is 1/4 of the pipe area in the free flowing run by looking at the area of the pipe, listed under "channel properties at top of section" in the .eof files.

    I've confused myself with algebra now, I hope I've got that right!



  6. Hi,

    I am working on a very large model and I am getting some strange effects. The original model runs through OK, and takes about 15-20 hours of computer run time.

    I subsequently added a few PO lines to part of the floodplain, which somehow caused some excessive oscillations upstream of my area of interest, sending a large flood wave through the model well after the flood peak.

    I wouldn't have thought adding PO lines could cause such a problem, as they merely extract additional data from the model? The only thing I can think that might be happening is that calculations are going astray due to the additional strain on the processor from writing outputs. Is this likely / possible?

    Many thanks


  7. Hi,

    Is the storage basin connected solely to your 1D pipe network? If so then I don't think you need to specify an "R" pit (I believe these are more often used for modelling a connection between the 1D pipe network and the 2D floodplain). You should be able to leave the "Type" attribute blank (i.e. it is a node instead of a pit channel), and use your NA table to specify the extra storage at that node. I wouldn't have thought the shape of your node (i.e. triangular) would be relevant, as this would be accounted for in your NA table.

    I'm not sure if that will have any bearing on your problems but hope it helps!



  8. Hi All,

    I am trying to use a z shape (polyline) to model a ditch which is approximately the width of my 2D cell size (5m), using points in a separate _pts layer snapped to the ends of the polyline. As far as I can tell all I need to do is specifiy MIN (or GULLY or LOWER) in the Shape_Options attribute and this should lower a line of cells (including the centre and side z points). This only seems to lower a thin line of cell sides however.

    I've also tried specifying the Shape_width_or_d_max attribute as 5m (i.e. less than 1.5 times the cell size) which should output a thick line, however I get the same result.

    Am I doing something wrong here? I'm using the latest (2009-07-AD) build.

    Thanks in advance for any help



  9. Hi Gillian,

    I'm not 100% on this but in Appendix C4 of the manual it says that the modified z points for a GULLY z-line (same as MIN) are not output to the _zpt check file, so it may be the same for a z-shape. I think generally you should have at least a cell width modified when using the MIN option (if you're trying to model a ditch or similar), as you'd want to make sure the ZC point is lowered and not just cell sides.

    Hope that is of some help



  10. Hi Paul,

    Just out of curiosity, how wide is your channel in relation to your grid size, and is there a certain width to cell size ratio where you would start using this approach instead of a deactiated 1D channel? Also, are the 2D solution produce comparable results to a 1D deactivated channel?



  11. Hi Paul,

    Is this a 2D HQ boundary? Also what kind of flows are you putting into the model when it is going unstable?

    I have had similar problems with 1D HQ boundaries with ratings derived from 1D packages, early on in the model. To take your rating as an example, my baseflow might start at 10 cumecs, in which case I would fudge the bottom end of the rating so that any flows below 10 cumecs have a stage of 2.335mAOD. You may also need an IWL layer to set this level too. This smooths everything out at the start of the model (obviously the results will be a bit skewed, but not an issue if you're interested in higher flows).

    The other thing I notice is that the left bank of your cross section is a fair bit lower than the upper extent of the rating - I think if the left bank confined the range of flows this may clear things up as well?

    Not sure whether your issue is in any way related, but hopefully this may help!



  12. Hi Paul,

    Off the top of my head here are the steps required for setting up an irregular culvert:

    1) Digitise the culvert in your 1d_nwk layer.

    2) Edit the 1d_nwk attributes as per any other culvert, with Type attribute set to I (type I culverts use thte height contraction coefficient - not entirely sure how to work this in your case, as circular culverts don't use this coefficient)

    2) Import the 1d_tab_empty layer, I normally save it in \mi\cu\1d_cu_xxx (i.e. the same filing structure as 1d_xs files)

    3) Digitise a line in the 1d_cu layer perpendicular to your 1d_nwk layer (as you would with a 1d_xs mid-section, i.e. 2-point line just needs to cross the 1d_nwk layer, a 3-point line will need to snap to a node)

    4) In the Source attribute type the name of your table to link to (eg. cu_10.csv)

    5) Type should be HW, all other attributes can be ignored

    6) Edit your .csv file (i.e. cu_10.csv), which must be in the same folder as your 1d_cu file. There should be two columns: H (elevation) and W (width) - making sure that you never have a width of 0, use something like 0.01. You will need to convert your XZ pairs to this format.

    7) In your .ecf file, add the following lines: Read MI Network == ..mi\1d_nwk_xxxxxx.mif ; Read MI Table Links == ..\mi\cu\1d_cu_xxx.mif

    Essentially it is the same principle as reading a cross section. Hope this makes sense! See the attached jpeg which shows the MI setup (*the use channel storage at nodes looks like an I but it's actually a T*.

    e.g. of .csv file:

    CU100510.csv (Arch Culvert beneath railway - Silted)

    H W

    3.505 0.01

    3.553 0.64

    3.6 0.89

    3.642 1.4

    3.98 1.4

    4.19 1.33

    4.385 1.135

    4.543 0.824

    4.638 0.435

    4.672 0.01

    If you want I can send you through some MI layers and .csv files I've used in past models - just let me know.




  13. The latest version of MapInfo (v.10) seems to handle translucent images OK (may depend on the size of the images, but I had success with a floodplain overlaid on an aerial photo).

    There is also a new MapInfo PDF printer, which overcomes a lot of problems we've had in the past printing raster images using the Adobe driver. The new version will also print complex maps straight to our colour printer, where previously the same maps would not print properly (assumed to be a problem with the printer memory).



  14. Hi All,

    We've just received an update to MapInfo v10.0, (we're currently using 9.5), and I wanted to check that MI Tools (and everything else in Tuflow) is compatible with the new version. Is anyone successfully running v10?



  15. Thanks Bill, that makes sense.

    I guess this is the transition between regimes L and F - in this case it sounds like it would be downstream controlled (F) so the inlet database would be ignored?



  16. Further to this question, what exactly is the "width" attribute calculated from? I see that it is used to select the number of 2D link cells, which would suggest it's the flow width in 2D approaching the gully - if so does this still apply in sump conditions? The orifice equation uses area - is this not extracted from the table to extend the depth discharge curve?



  17. Hi All,

    I'm using a Q pit to control flow into a gully, and I'm wondering if there is any way to specify two different ratings for one gully, depending on downstream water level. I'm using the equations for weir and orifice flow from USFHA Hec-12. This is fine until the water level in the pipe network rises above the ground level, and the depth used for calculations is the difference between 2d and 1d water levels.

    In my case this difference is small (0.1-0.2m), but I would assume the orifice formula would still apply. The standard rating uses weir flow at these lower depths - is there some way to override this when head in the pit exceeds ground level?



  18. Hi,

    I'm adding proposed ground elevations to an existing model, which require sensitive adjustments to fine tune the design. Occasionally I will get the message Error 2232... triangulation failed.... check region does not intersect or snap onto itself.

    I will have only moved one TIN line slightly, nothing which I would have thought would cause this error. If I then move the TIN line again slightly, it may run ok. The error seems to be quite random!

    Any possible reasons why this would occur?



  19. Thanks for your reply Rhys,

    It sounds like what I'm trying to do is pretty straightforward. I was a bit confused by comment :) on page 4-21 which says "If there are one or more points snapped to the perimeter vertices, the perimeter is not merged with the zpt values...".

    However as you suggest, Teble 4.8 indicates that as long as I don't specify MERGE ALL or NO MERGE, then I can use a combination of snapped points to set elevations, vertices with no points to merge to existing values, and points with elevation -99,999 to ignore existing zpts and interpolate to the nearest vertices.

    Cheers for your help


  20. Hi,

    I'm using z shapes to model proposed ground level modifications. From what I gather the polygon is merged to existing z points if no points are snapped to the boundary. If any points are snapped to the boundary, then the entire boundary is set based on the manually specified elevation points.

    Is there a way to use both options in one polygon? For example on one side of my polygon I want to merge to existing levels, but on the other side I want to snap elevation points to the polygon to set elevations (there will be a vertical wall to existing levels here). I guess problems may arise when transitioning from "merge" to "no merge" points on the polygon?



  21. Hi Amul,

    It sounds like the tidal boundary may be outside the model extents - are the nodes of the tidal boundary snapped to the bc_hxe polygon nodes? It may also pay to check that the correct versions of the layers are referenced in both the .tgc and .tbc files. The messages.mif layer will show you exactly where the problem lies, and the 2d_domain check file may be useful to see where your 2d domain ends compared to the tidal inflow.

    Hope that helps



  22. Hi,

    I'm using the XS Editor (for Excel 2003 version), which is fine until I am finished and close the editor, and I get the message "if log file is open changes will automatically be saved". Unfortunately when I come to open the log file next time, the edits are not contained in the file. Has anyone had similar problems?



  23. Hi,

    I've got a batch file that I copy to the results folder for each project, for processing single or multiple outputs for Mapinfo. You can copy and paste the line below within your batch file and it will process as many files as you need. I use the -b switch for batch mode, which may fix your problem. Also I run the .exe from my Tuflow directory, you don't need it to be in the results folder. I think the batch file does though.

    "C:\Program Files\Tuflow\utilities\TUFLOW_to_GIS.exe" -b -asc -t99999 ltc_008_d.dat



  • Create New...