Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

1 Follower

About rachel.jensen

  • Rank
    Advanced Member

Profile Information

  • Gender

Recent Profile Visitors

4454 profile views
  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
  • Create New...