Jump to content
TUFLOW Forum

cfrk

Inactive members
  • Content Count

    64
  • Joined

  • Last visited

Community Reputation

0 Neutral

About cfrk

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  • Location
    UK
  1. cfrk

    1D/2D instability

    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...? Cheers Richard
  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... Cheers Richard
  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... Cheers Richard
  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! Cheers Richard
  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 Richard
  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! Cheers Richard
  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 Cheers Richard
  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 Cheers Richard
  10. cfrk

    zsh grid editing

    Thanks Paul, sorry what I meant was a 1D channel with the corresponding 2d cells deactivated. Cheers Richard
  11. cfrk

    zsh grid editing

    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? Cheers Richard
  12. 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! Cheers Richard
  13. 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. Cheers Richard
  14. cfrk

    MapInfo v10.0

    We're now running v.10 - the tools generally work OK but the "batch export .mif" button is missing (probably the tool we use most unfortunately!), and the miTools menu is empty.
  15. 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). Cheers Richard
×
×
  • Create New...