Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by ndeeks

  1. Hi, this white paper mentions the intention for a Classic/HPC Linux release in mid 2020. Is a Linux release still on the cards? https://www.tuflow.com/media/5024/2020-vision-running-tuflow-on-the-cloud-van-der-velde-et-al-tuflow-whitepaper.pdf
  2. Hi groganm, your post is spot on, it's only the shared machines with concurrent users that give me this problem.
  3. Hi, despite setting a custom log file path in my DCF file (found buy TULFOW), TUFLOW tries to write to "C:\ProgramData\TUFLOW\log\_ All TUFLOW Simulations.log", which returns an error "forrtl: severe (47): write to READONLY file, unit 905, file C:\ProgramData\TUFLOW\log\_ All TUFLOW Simulations.log", and the simulation fails.. This applies to 2020-01-AA-iSP/DP. Can the coding be changed not to write to C:\ ?
  4. Hi Duncan, I see that Quadtree is mentioned in the agenda. Is there a release date for quadtree? Regards, Nick
  5. Hi Pavlina, Problem solved- the HQ boundaries I was using were polygons. I changed them to polylines and I am no longer getting the error. I have a bunch of other models that I still need to test, so will post again if the problem continues. Regards, Nick
  6. Hi, I am getting HPC Error code 3022 https://wiki.tuflow.com/index.php?title=TUFLOW_Message_3022 What would cause this? Too many/ too long HQ boundaries? Regards, Nick
  7. ndeeks

    Non-Newtonian Fluids

    Hi, Are there any plans to introduce capability to model non-Newtonian fluids (i.e. fluids with different viscosity to water, e.g. oil, tailings)? I expect this will impact many of the equations, and is probably a tall order! Nick
  8. ndeeks

    TBC variables

    After further testing I can answer my own question: yes, TBC files can contain variables.
  9. 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.
  10. ndeeks

    TBC variables

    Hi, can variables be used inside TBC files? I tested this and couldn't get it working, but I may have done something wrong also.
  11. Hi, Are there plans to support cloud computing? Perhaps through Amazon EC2 of Google Cloud compute. For Amazon you will need to build an Amazon Machine Image. I assume this would be based on Windows Server 2012, unless you plan on recompiling TUFLOW for Linux. I'm not sure if there's a way to port existing user licences, otherwise you could charge an hourly rate for licences through the AWS marketplace. Cloud computing would open up a number of opportunities: Model owners, such as local governments, who can't justify a TUFLOW licence could rent a licence at the same time as having a pre-configured server to simulate minor changes to their networks or test scenarios.Bigger and more complex models could be run faster, including post-processingSmaller consultancies who can't afford a TUFLOW licence could have access to a licence at lower costAs an engineer for a large organisation, these ideas might do me out of a job! Regards, Nick
  12. Hi all, Referring to attached sketch, I have a 1D channel within a 2D model. The channel invert is deep in a cutting, with the 1D head well below the 2D head. 2D flows will drain down the face of the cutting into the channel. What is the best way to link the flows? A HX boundary doesn't seem like the right way to do it. Thanks in advance, Nick. img-222145411.pdf
  13. Hi Phillip, Banding of depth results is fixed by using Interpolate ZUVH ALL command. Search works for me now also. Thanks, Nick.
  14. Hi Phillip, There is a strong possibility that the DTM could be the cause, since I assigned zpts based on a 25m DTM, and although cell sizes are 25m, zpts are only 12.5m apart. I will re-run using Interpolate ZUVH ALL command and see how it looks. And maybe in the meantime try assigning cells to a finer DTM (8 million grid cells takes a lot of time on my PC...). Will give an update when I get the results. Cheers, Nick p.s. I don't think the forum search is working as I did search for "banding" before posting!
  15. Hi Tuflow users, The results of my model show a banding of depth (as illustrated in the attached screenshots). Bands are horizontal, stretch across entire model, are about 1.41km high, more prevalant in flat terrain. Head looks normal (no sudden changes). 2D grid check looks normal (no sudden changes). I have attached screenshots of close up and full model. Details of model: 25m grid, direct rainfall, Cell Wet/Dry Depth == 0.0002, Map Cutoff Depth == 0.03, Build: 2010-10-AC-iDP-w32, Mass balance < 0.5%. Not sure if it's related but Map Cutoff Depth doesn't seem to be working as many depth cell results are <0.03m. It might be totally coincidental but the bands heights are the square root of 2, making me think it could be a math problem. Any ideas or suggestions for other checks I could do? Thanks in advance, Nick.
  16. Phillip, I didn't think that would make much difference, but it has worked quite well. However, when I first tried to do it, I snapped the QT line and 2d_code polygon to "H" zpts (i.e. corner of cell), and although the model appeared to be running a lower mass balance error, the model crashed due to instabilities in the vicinity of the QT line. I suspect this was because I drew the lines along the edge of the cells rather than inside a cell. Moving the QT line and 2d_code polygon to be within the cell (as well as being perpendicular to flow direction) resulted in a stable model with low mass balance errors (0.1%). Thanks for your suggestion. Nick.
  17. I regularly have trouble with upstream QT boundaries in 2D models. I have tried a number of methods to resolve the problems, and can usually get rid of the worst instabilities, but still suffer from minor instabilities and poor mass balance. Smoothing the upstream terrain to reduce wetting-drying problems (see attached) usually helps but inspection of the results near the boundary reveals "bumpy" head levels still occuring (see attached). Does anyone have any other suggestions? Nick.
  • Create New...