Jump to content

Search the Community

Showing results for tags '2d'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • About This Forum and Announcements
    • How to Use This Forum
    • Forum Feedback
    • Announcements
  • TUFLOW Modelling
    • 1D/2D Linking
    • 1D Domains
    • 2D/2D Linking
    • 2D/2D Nesting
    • 2D Domains
    • Boundaries
    • Documentation & Tutorial Model
    • Dongles/Licensing/Installation
    • Ideas / Suggestions / New Features
    • Mass Balance/Mass Error
    • MATH Errors & Simulation Failure
    • Restart Files
    • Post-Processing
    • Software/Hardware Requirements
    • Text Files (.tcf, .tgc, .tbc, .ecf)
    • Utilities
    • Miscellaneous
  • Other Software
    • MapInfo/Vertical Mapper
    • miTools
    • Other GIS/CAD
    • SMS
    • XP-SWMM2D
    • UltraEdit/Excel
    • TUFLOW Apps

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL







Found 9 results

  1. Hi all, I'm following the method suggested in the manual for modelling fences in an urban environment: a thin variable height breakline, but it doesn't seem to be working because outputs show no maximum head difference at fence lines. Inputs I have set-up the fences to a nominal height that collapses to 0.2m high when adjacent water depths reach 1.0m: VZSH points with fence elevations (Z) and all other attributes 0 or null VZSH lines with dZ = 0.2, Shape_Option = REPEAT, Trigger_1 = DEPTH, Trigger Value = 1.0, Period = 0.002, all other attributes 0 or null. Checks I've done Flood depths, levels and vectors indicate fences are not obstructing flows despite being crossed by shallow flow (<0.3m), so trigger values are never activated because water doesn't accumulate and depth doesn't exceed trigger of 1.0m Check file for VZSH points is empty. TLF indicates the right number of elevation points were read. I've check snapping and all looks ok. Check file for VZSH lines indicates inputs read as expected, confirms final z, but doesn't have any attribute for initial Z. Does this mean initial Z varies along line, but final Z is constant/ horizontal? Thanks in advance for any ideas. Nick.
  2. All If I wanted to model a large river channel and floodplain using 2D only, how would people go about including the river channel bathymetry into the DTM? LiDAR will provide the terrain data, but will poorly-define the river channel itself. Is there a way to use channel cross section data to modify the base DTM to reflect the surveyed channel? We have regular channel cross-sections, and would like to use this data to 'carve' a more detailed channel through the DTM. The method will need to account for any meanders etc... Are there clever ways to do this in Arc/MapInfo/QGIS? Any pointers gratefully received :-)
  3. All, We are running a rainfall model using TuFLOW, which uses variable Manning's for the 2D domain to help maintain model stability. However, the thought occurred as to why it is not more common to incorporate variable Manning's into all models? Is this something that people have given much thought to, or is a constant Mannings roughness value considered to be appropriate? Any thoughts would be most welcome. Regards, L
  4. Is is possible to apply HT boundaries within the 2D domain to withdraw flows out of the model and avoid using 1d estry components? I'd like to maintain using the GPU module. Cheers O
  5. Hi, I’ve recently been running a linked ISIS‑TUFLOW model (ISIS 3.7 / TUFLOW 2013‑12‑AD – both 64‑bit DP) and I’m noticing a large change in simulation time if I include PO lines along the 1D/2D boundary. No PO lines – the simulation takes approx. 4hrs. Including the PO lines (approximately 100 in total) – 11hrs. No other changes to the model setup. I understood from the latest release notes that 2d_po flow lines should not slow down a simulation (see point 23 on p11 - TUFLOW Release Notes.2013-12.pdf). Is this still a known issue or a bug? Cheers for any help. Dave
  6. Hi Tuflow admins we are trying to run a GPU solver model. it is purely 2D. strangely the simulation prematurely exits stating: Allocating 13600 Kb of temporary 1D domain memory (RAM) Determining 1D array sizes SORRY - 1D linking not available yet with adaptive time-stepping. I have compared the setup files to another GPU solver model. They are consistent with each other. I can only think the error is in one of the layers? We have checked our BC's and other layers. We are really not sure. Cheers O-Dogs
  7. Hi admins, Have just been running a ~ 50ha ROG model, pure 2D domain with the GPU solver. We really wanted to run it using 1m cells so we could pick up on small overland flow paths within the site. the model continued to be unstable until we adopted 4m cells. The 4 hour simulation ran very very fast, in about 5 minutes. Am I right in thinking that maybe the time step may have some impact on the instability? Are there any codes that can applied to slow the time step and accept (force) a smaller grid, such as a 1m or even 2m? Cheers
  8. Hi Tuflow Not sure why we are getting this error: ERROR 0103 - BC Groups not supported for .csv formats have not come across this before. our 2D GPU model bcbase files are setup the same. we are using 2d_sa buffers. thanks O-Dogs
  9. trying to run a pure 2D model with some steep terrain, 1:1, using QT and HQ boundaries. As expected we are getting high instabilities at this change in elevation. typically we could overcome this using rainfall on grid, however in this instance, the client prefers hydrograph. has anyone modelled steep terrain with QT and HQ boundaries? can anyone suggest a method to override, overcome these instabilities?
  • Create New...