rachel.jensen

Administrators
  • Content count

    50
  • Joined

  • Last visited

Community Reputation

0 Neutral

1 Follower

About rachel.jensen

  • Rank
    Advanced Member
  • Birthday

Profile Information

  • Gender
    Female

Recent Profile Visitors

1481 profile views
  1. 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!
  2. As an update to anyone who comes to this post, please refer to this updated topic for guidance.
  3. 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
  4. 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
  5. 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.
  6. 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.
  7. 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!
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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.
  13. 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
  14. 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.
  15. 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