Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by rachel.jensen

  1. Hi Sunita, I've taken a look at your model logs. The .gpu.tlf states that your GPU card does not have enough memory to run this model (refer to the figure below). There are a few ways to fix this issue. If possible, you can run the model as is on a different computer or GPU card which has enough memory If this is not an option, you will need to alter how you are running the model: Store fewer maximum fields - reduce the number of variables you are outputting with the Map Output Data Types command Reduce the model domain - look at the 2d_dom check file in relation to your 2d_code layer and make sure that the domain is as small as it can be to include your code. This may mean changing your 2d_loc line and Grid Size (X,Y) command. Make sure your 2d_code layer is a small as it can be to contain your modelled results. Increase your cell size - if the above two have not helped, then increasing the cell size will reduce the amount of RAM required I hope that helps, please let me know if you need more information or ideas to reduce the required RAM.
  2. Hi Adam, I know this is a while ago but I thought I'd share what we're using here. The 'Refractor Fields' functionality in QGIS has been really helpful for bulk editing of tables. I'm not sure if you're using a database or just a layer. This example will only work for a layer. Unfortunately I've not been able to find much documentation on the tool, so what I know is mostly from experimentation.See below for an example. I've loaded up an exiting table that I have called 06_PropertyCounts_LBWF_COM_EXG_002_AOI. QGIS has filled out the table below with the existing fields that I have in there (legend etc). I'm going to transform this table using the things that I pop into the expression box. In the first line, the 'Legend' field is going to stay the same, so in the expression box I keep the name the same (I.e. it will map to itself). In the second box I'm making a field called Toid, and its value will be the 'Version' field times 1.2. In the new version field, I'm setting it all to the value of 7. Finally, in the FC field, I'm using the area of the shape. It's essentially a way to bulk transform tables and we use it a lot to move things into a TUFLOW format. The best bit - if you do this a lot on similar tables you can save your field mapping as a template and batch process this. Magic. I hope that helps. Please let me know if you want more information. Rach
  3. Hi Sam, There are two hardware factors that could be impacting your run times: 1) When you start a GPU run, TUFLOW compiles the model on the CPU, as per normal, before passing it to the GPU. The model then stays on the GPU, except at output times, where it passes information back to the CPU to get written. Thus, when you are running a GPU model run, you take up one GPU and a part of the CPU. Depending on the output frequency and size of the model, how much of the CPU you take up can be substantial. When I run a GPU model, I like to keep a CPU core free for this purpose. 2) TUFLOW GPU runs need both CPU RAM and GPU RAM for the process I've described above. Each run needs about 5 times more CPU RAM than GPU RAM, this has been optimised in the 2016-03-AD release, so check which version you're running. If you exceed the amount of GPU RAM available on the card, the model wont run. But if you exceed the amount of CPU RAM available on your computer, you will move to virtual memory, which is very slow for models! Check in your tlf or in the task manager how much memory your models need each. So, if you've got a 4 CPU core machine with 64 GB of CPU RAM and 2 GPU cards with 2GB of GPU RAM each, you'll be able to run 4 models, 2 of which could be GPU. The total amount of RAM required for the models should not exceed 64GB and each GPU model could take up 2GB of GPU RAM each. I hope that makes sense. Others who are hardware minded feel free to weigh in!
  4. As an update to anyone who comes to this post, please refer to this updated topic for guidance.
  5. Hi CHJ, Pretty spectacular model pop! I see that in your tlf the instability is first registered in the 2D, does it start there or can you see it propagate from the 1D or another 2D location? Can you see earlier oscillations in either the 1D or 2D before this originating from somewhere? Your list of things to check is very sound, and would cover most of the causes of these types of issues. I would add a couple of things to your checklist to investigate: - Look for changes in the flow patterns just before the instability. For the 1D, review the flow regime in the channels (in the EOF). In the 2D, it looks like the channel is starting to seriously break out just before the instability occurs. This is also the low point of HX line. Just double check that the boundary and elevations sit as best they can here. - You're right that the high velocities hitting the bridge just stating to surcharge could be causing issues. If you can, it would be good to drop your output interval (or use an output zone) to see exactly where the instability starts and if indeed its the bridge. If it is looking like this, then you might need to check how you've schematised it, maybe look for big changes in conveyance or flow area. - For 1D sections, I like to visualise conveyance (nwk_C_check). This helps look at big changes in channel geometry and section length, Ideally, you want this to be fairly gradually changing, no big jumps. If you're still having trouble finding the cause of the instability, feel free to post again here with more information or send us through the model to support@tuflow.com and we'll take a look. Regards, Rachel
  6. Hi Francis, You can use a node in the 1d_nwk layer to add a bit of storage.Refer to table 5-16 of the 2016 manual. Using the Len_or_ANA, US_Invert and DS_Invert attributes, you can tweak the NA table that TUFLOW will create. From the sound of the problem, it could be that the issue is complex and is influenced by a few things. If, after looking into the NA options, you're still not sure where the head drop is coming from, feel free to email us the model at support@tuflow.com Cheers, Rachel
  7. This is a common question that we receive through support, here's a round up of our advice. Q: I am using z shapes in a direct rainfall model to lower LiDAR values by 1m using the command Read Mi Zpts ADD. For some reason the cells around the edge of the z shape result in deeper depths. There is ponding against one side of each z shape where the lowest elevations exist but there are also wet cells around the edges of the z shape (which are not the lowest elevations). Is this something to do with the way a direct rainfall model works with z shapes? A: What’s happening to cause this: TUFLOW is calculating the WSL at each cell ZC point like usual. Refer to the first figure below. To output these results, TUFLOW interpolates between the ZC WSL (the red line in the second figure below) and outputs this interpolation at the ZH locations (the purple points). This means that you can get strange interpolation results across steep areas or topography step changes. What you can do to remedy this: 1) Output the grid formats directly through TUFLOW. When TUFLOW writes the grids, it outputs both the ZC and ZH points, giving you more interpolation points and potentially smoothing the interpolation. (FYI, if you has noticed that your TUFLOW grids were bigger than your post processed ones, this is why ) 2) If there are still issues, provided that the model is NOT rotated, output the grid on the same dimensions as the cell size. Map Output Format == ASC Grid Output Cell Size == 4 ! Set to your model cell size Grid Output Origin == MODEL ORIGIN This means that you will only get the ZC output 3) Last option is to use the Interpolate ZUVH ALL command. This means that TUFLOW interpolates all ZU, ZV and ZH elevations. Caution, this will alter how your model input grid is read and could result in slightly different results. It should sort the whole results interpolation issue, as the topography itself is interpolated.
  8. Q: I have a QGIS query and hopefully you can easily answer it. I know how to do this with my eyes closed in MI, but, I was wondering if you have any tips for: • merging a grid (by grid order) in QGIS (layer stack merge never seems to work), and; • exporting a grid to .flt in QGIS I want to “read grid zpts” the grid(s) so if you don’t have a solution for the layer stack merging I can read them in order if I can export as .flt – I find ASCII’s produced by QGIS don’t behave like those created in MapInfo, do you also find this? A: If you want to merge a grid, I usually use raster>miscellaneous>merge. There is a useful tute here. I normally use this for adjacent grids, where they don’t overlap. If you need to get a bit more in depth then the SAGA tool box is the way to go. This stack exchange post is pretty much what I use. You can use first or last method to make sure that you get the right grid order. Exporting to flt is a bit trickier. QGIS currently does not export these perfectly. You can export as the ESRI BIL file and change the header. Here’s an example. Another option is to export as asci in QGIS then use the TUFLOW utility asc_to_asc to convert it. I usually use TUFLOW to read in the grids in the correct order, then typically work with the resulting DEM_Z.flt file. Sometimes, QGIS can default to the ‘golden surfer’ style of asci, which doesn’t have a fixed cell size. This may be why you’re seeing a difference. The ‘export asci in QGIS’ link above, there’s instructions on how to get around this.
  9. Q: Is there an easier way to determine whether or not the manholes/gullies are surcharging other than using the EOF file, take the elevation of each MH, and take the max stage and compare the two together? A: When I want to visualise surcharging pits I load the mmQ layer and thematically map to see if there are any negative values in the Qmin column. I’ve popped an example in the first image below. You can do this by thematically mapping in MapInfo or using graduated styles in QGIS. You can so use the TuPlot plugin for QGIS to get more information on flows and how the pits are performing. Refer to the second image. Comments on how you visualise things most welcome!
  10. Morning Frances, Bill Syme and Phil Ryan have a very useful presentation on different modelling techniques for piers. Its located here in our publications library. The first one addressed is the technique you've used of blocking out the pier cells. In the absence of calibration data or anecdotal information for verification of a larger head drop than you're currently seeing, I would not apply an additional form loss. Any additional form loss could be used to take 3D effects (like mixing or vertical effects) or sub-grid scale features. However, I would expect these to pale to insignificance compared to the losses from the piers themselves, which look to be well captured by the blockage you've applied. Discussion and debate welcome! Regards, Rachel
  11. Hi Francis, Let us know how you get on with TRIM and seeing if the error is any different in 2016 or without the TRIM run manager. If you need more help, feel free to send us an email through to support@tuflow.com. (PHA: noted and corrected here ) Regards, Rachel
  12. Hi Kwanza, I expect the issues comes from the direction of your upstream X connector. X connectors are used to join side channels to the main channel, as you have done with the weir and the open 'S' Channel. The direction of the X connector is important, as it tells TUFLOW which is the side channel and which is the main. They must always be from the side channel to the main channel. Refer to section 5.8.3 of the 2016 Manual. Thus, the direction of your upstream one is not right, change the direction so that it points from the weir back to the main channel. I've popped an image below of my version. I'll update the tutorial so that this point is clearer. Let me know how you get on and if you need more help. Regards, Rachel
  13. Nice work around Robin! and thanks for updating the question We've noted down the trouble you had so that the issue can be fixed in future builds
  14. Hi Lucy, The 'maximum' function in the Asc_to_Asc utility is the one that you need to achieve both of these Steps for both points: Set up a batch file similar to the one in the first image. You need to link to the utility and, using the '-max' flag, link to the H max grids you need to combine. You can also use the optional '-out' flag to set the final filename, else the utility names it for you. From this step you will get three outputs. 1) a maximum grid that has combined all the WSL to get the maximum. This is what you wanted in point 2. 2) a classified grid that details the source file for each of those maximums. See the second picture I've attached. This is the map that you will need for your first point. This classified grid references the order of the files you put into the batch file. For example, if the maximum WSL in one area of my catchment came from the 15min duration, my classified grid would have the value 1 in this area, because it was first in the batch file. 3) a csv that links the integers in the classified grid to your file names. This is so you don't lose track of what each number means if you change the batch file. Hope that helps.
  15. The Introductory, New Features and TUFLOW FV workshops in London are filling up. Take a look at the training page for more information or email training@tuflow.com to register your interest
  16. Q: In ESTRY is it possible to apply a QH rating in the channel. Not as a downstream boundary, but in the middle of a reach to act as a control representing a structure in the channel? A: In regards to QH ratings in channels, there are two different methods: • M Channel (section 5.8.1 of the 2016 Manual) The M channel uses a matrix of QH relationships to define the mechanics. You can also read the description in the manual but I’ve coloured up my example csv for easy reading below. There are a few rules with the flow values: the matrix must be square, it must have the centre line of diagonals and it must be negative (or zero) below the diagonal and positive (or zero) above. • Q Channel (Section 5.8.2 of the 2016 Manual) This uses a Depth Discharge curve, like you would for a pit inlet. The H values in this case are for the upstream end of the culvert. In deciding between the two of them, I’d have a look at the culvert and the flow regimes you expect. If you think that the culvert will have significant downstream control, then an M channel is the better option. If it’s pretty much always upstream controlled, then you may be able to get away with just a Q channel.
  17. Hi Sam, This post might help you out in regards to the weighting factors being greater than 1. The RFR and RFC outputs are currently not supported within Tuflow GPU for 2d_rf polygons. This is in order to keep the memory footprint low and to optimise the speed of the solver. I hope that helps out. Cheers, Rachel
  18. Dates for the 2016 UK TUFLOW Workshops have been announced and are provided below. We are offering computer based training for new users and workshops aimed at bringing existing users up to date with the latest features. 7th June: Introductory TUFLOW Training 8th June/ 5th July: TUFLOW User Workshop 28th June: TUFLOW FV User Workshop The workshops are designed for both new and proficient users who are looking to enhance their modelling capabilities. Located in Central London, the one day workshops offer topics from introductory model build to advanced structures and modelling efficiencies. In addition to the introductory and proficient users workshops, the TUFLOW team will be hosting an introduction to TUFLOW FV, our flexible mesh software for simulating hydrodynamic, sediment transport and water quality processes. For more information, including dates, prices and the topics covered in each workshop, please refer to the information sheet on our website. To register your interest or ask any questions, please email training@tuflow.com Regards, Team TUFLOW UK
  19. Q: I’m trying to do a grid difference with asc_to_asc utility and using the method in the 2016 manual (section 15.2.2), I get an error saying it cannot find the asci file. The file it cannot find is the name of the one that I'm trying to output The Manual says: Example 1 asc_to_asc.exe –dif Q100_dev_impact_h.asc Q100_dev_h.asc Q100_exg_h.asc Outputs an ASC file called Q100_dev_impact_h.asc that contains the difference of Q100_dev_h minus Q100_exg_h. A: I’m afraid that’s a typo in the new manual sorry. Thanks for bringing it to our attention, I will have it adjusted. You can find the correct version of the line of code you’re looking for on the Tuflow wiki, located here. The manual version was missing the ‘-out’ flag that tells the utility that this is file name that you want to use, not to look for the actual file. You can see an example that I’ve colour coded up in the attached image. It doesn’t matter if the output section or the difference section goes first, just as long as they have the flags so that the utility knows what to do with the input you’re giving it.
  20. Hi Laura, One thing to check is that when you open up the ascii in a text editor is that your headings look something like the below attached image. You should have a 'cellsize' header line, not dx and dy values. You might have already seen it, but i'll point it out just in case; there's a post on the wiki on how to convert to ascii using QGIS and I've found this stack exchange post helpful in explaining what's going on and how to manage it. If you're still having troubles, please send a copy of the ascii and the tlf through to support@tuflow.com and we can have a look. Regards, Rachel
  21. rachel.jensen


    Hi Rohan, The ESTRY software has been used in numerous projects involving real world calibration of fluvial, pluvial or tidal events. One recent and particularly notable calibrated ESTRY model is the Brisbane River Fast Model. The model is a pure 1D model and comprises more than 2,500 channels. The model was calibrated and verified to 5 real world events. A paper discussing the creation of the model, the calibration and results is located at this link on the BMT WBM website. In addition, there are several documents on the TUFLOW Wiki benchamarking page that illustrate real world calibrations of ESTRY-TUFLOW coupled models. I hope that helps answer your question. Regards, Rachel
  22. Hi Kathy, It might be easiest to diagnose if you send us through a copy of the model. Could you please make a copy of the model using the -ca switch, delete the checks and results (we'll recreate them here) and zip it up. If it's small enough, you can email it straight through to us at support@tuflow.com, otherwise, be in touch and I'll send through details for an FTP link. Regards, Rach
  23. For those following along with the forum, we replied to Ketaki through support@tuflow.com There’s a very handy presentation that Bill Syme, the Tuflow author, gave recently at the UK conference located here Only the first 10 slides or so are relevant to the bend losses question but the whole presentation is on losses and how Tuflow performs, so it’s an interesting read nonetheless. If the channel is in 2D, then you will need the bend loss to represent the sub-grid scale and 3D effects that a 2D solver will ignore. If it’s in 1D, then I expect the loss to be larger as not only do you need to represent the 3D effects, but also the 2D effects, like super elevation and different flow patterns on either side of the bends. If possible, and I know that in reality it’s often not, you should seek to calibrate the channel against real world data. Water surface levels up and downstream are really the best that you can get. In the likely case that this data does not exist, then I strongly recommend that you carry out some sensitivity testing to investigate the effects that different losses have on the bends. Without calibration data the best approach is to test how you channel responds and investigate what you think it suitable. There is some literature on bend losses that is also quite useful. A good one is Bend Losses in Rectangular Culverts by the Kansas Department of Transportation or another one by Bill Syme, Modelling of Bends and Hydraulic structures in a Two Dimensional Scheme (more information and similar to the presentation that was linked above).
  24. Hi PHA, Good question The outflow is limited to the maximum value of that HQ curve. If the water level stays above the curve, Tuflow will continue to remove the maximum Q specified but the water surface will back up behind the boundary. This obviously has a marked effect on your model results so I'm of the opinion that's why the error persistently reoccurs and is very obvious in your tlf! In the case of your boundary, and perhaps you've already looked at these things, I'd have a look in your 2D tables check file to see exactly what curve Tuflow is using and check that upper limit. If you think the boundary is still behaving oddly, you're welcome to send through your WSL grid, boundary layer and 2D table check for us to investigate. Either way, if you're getting that error your totally right that a 'd' value or reconfiguration of the line is the way to go Cheers, Rachel
  25. We often get asked about instability troubleshooting and how to have a basic review of model health. Below is a short workflow for how we normally start checking mo dels, typically for instabilities but also for schematisation problems or general health. The below is for basic 2D models but also applies to 1D/2D models. How do you go about checking for instabilities? What do you find most helpful when it comes to picking up problems? Is there anything on your wishlist that your Tuflow simulation could tell you about how to get to the bottom of these? Check the Tuflow log file (.tlf) Search for the words WARNING, CHECK and ERROR in the tlf. If there are messages that you don't understand, then use the wiki messages page to help you look for what the codes means and suggestions for how to solve them What's are the cell size and time step? Is the time step around half or one quarter of the cell size (or down to one eighth for direct rainfall models)? Is the cell size appropriate for the results that you expect (ie: no depths much larger than the cell size) Scroll to the bottom of the tlf and check the simulation summary – image one below shows two examples on how to read the summary in your tlf Has the model finished? Are there any negative depths? If so, import the layer into your GIS package to find out where these instabilities are occurring. What is the peak mass balance in the model? As a rule-of-thumb this should be between ±1%. Look at your messages layer If it goes unstable, is it in the 1D or 2D? Find the first UNSTABLE errors that occur and visualise those in your GIS package, along with you model inputs, are there any correlations? Topography o Load your zpt_check file (or DEM_Z check) and review the topography around your area of interest. If you’re using topographic modifiers, also load you zsh_zpt_check file to review what changes you’re making. Are there any sharp edges or quick changes? 4. Materials o Load your grd_check file and thematically map by material or load your DEM_M to look at your materials. Are there any big changes in roughness? 5. Results o Step through the depth results and velocity vectors, look for sudden changes o Check for circulations or oscillations, particularly around boundaries. Are there circular flow paths or undulating water surface levels?
  • Create New...