Jump to content

Francis Lane

  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Francis Lane

  • Rank

Recent Profile Visitors

1886 profile views
  1. Hi, We have a Council TUFLOW model running build 2017-09-AC. Results are output to .xmdf and we have maintained that for consistency when we hand back to Council We are using the current TUFLOW_to_GIS utility build 2020-08-AA We have been able to extract height and depth as ascii grids, however we can't seem to extract the zaem1 output. ZAEM1 was definitely written as an output, and is listed as a scalar dataset within the .xmdf file (see attached image). We have tried converting to.dat first using the res_to_res utility, but to no avail. Any help or suggestions as to how to extract the zaem1 hazard as an ascii grid would be appreciated. Kind regards, Francis
  2. Hi, Administrator - not sure which topic this should be in. Please move or create a new one as appropriate. We have just started running multiple GPU models on our grunt computer. We noticed that the first model in the list ran fairly quickly, however the others were much slower. We have the following commands in our .tcf file. If Scenario == GPUEx Hardware == GPU Solution Scheme == HPC GPU Device IDs == 0,1,2 End if Do we need to assign a separate GPU device to each specific model to overcome this? Ideally we would like the GPU cards to be automatically assigned. We would appreciate advice on how best to set this up.
  3. No need to reply to this one. We found the issue was related to an un-announced server change by our IT department. Scheduled policy updates were imposed on our modelling machines. This cut network connectivity while TUFLOW was writing results to a network drive. Shorter runs all missed the regular scheduled policy update, so all completed without issue. Hope this helps someone else with a similar issue. Regards, Francis
  4. Hi, We are running some TUFLOW models using the GPU hardware and HPC solution scheme (Build 2017-09-AC). We found that some of the runs fail without warning (well into the simulation). It seems that they are 'exiting without prompt', so we are unable to view the dos window to see what has caused the models to fail. We have tried disabling the 'quick edit mode' in the dos window in case the issue was related to the 'TUFLOW pause mid simulation? cause and solution' topic posted by Chris Huxley, but this didn't make any difference. Three runs (15, 25, and 540 minute) completed without any apparent issues. Two runs (90 and 120 minute) failed, but when re-started they completed successfully. However three longer runs (720, 2400 and 2880 minute) failed and will not complete on re-start. We have reviewed the .tlf files (both standard .tlf and hpc.tlf). We appreciate that the adaptive timestep will mask potential instabilities, but there is nothing in the tlf files to indicate that TUFLOW is having instability issues (i.e. the timesteps are consistent at the time of failure). We would appreciate some guidance on how to resolve this issue. We are managing the runs via TRIM. Kind regards, Francis Lane
  5. Hi, We have noticed that when modelling extreme depth tailwater conditions (i.e. depth > 15 m), we are getting oscillations across the floodplain. Review of the PO.csv file reveals that the flood height at the tailwater boundary is fluctuating below a fixed tailwater level. We don't understand how the water level can drop below the fixed global level. We have tried adopting a boundary viscosity factor of 4 in lieu of the default 1, and it had no measurable effect. We have also tried reducing the timestep - which did not change the results. We mapped the courant number for a problem timestep, and the maximum value was 4.9 - which would appear to be okay. We would appreciate some advice on how to minimise this oscillation. Is this a known issue when modelling extreme depths? We have had the same issue with models elsewhere in the same floodplain when modelling deep regional tailwater conditions. Regards, Francis
  6. Hi Paul, I know this post is quite old, but I would appreciate if you could re-post the Catchment Slope calc doc. It seems to be unavailable or moved. Regards, Francis
  7. Thanks Rachel. We will investigate the issue a bit more and see if we can work it out. This particular model is quite complex. If we can't resolve the issue, we'll get some support. Mitch has looked at other aspects of this model previously. Cheers.
  8. Always fun replying to your own topic... Update - I have installed the latest version of QGis and the TuPlot utility is available. However I get the following error " IOError: [Errno 13] Permission denied: 'C:\\Users\\flane\\.matplotlib\\fontList.cache' " I think this is related to the install of the matpotlib exe file. Anyone else had issues installing matpotlib on windows 8, 64 bit OS?
  9. Hi, I'm having a bit of difficulty in finding the TuPlot plugin for QGis. I have followed the instructions in the Tuflow Wiki, and TUFLOW is listed in the QGis Plugins dropdown, but TuPlot is not there. I would appreciate some advice both on where to find the TuPlot plugin and which folder to save it when I get it (i.e. does it go in the "C:\Program Files\QGIS Chugiak\apps\qgis\python\plugins\Tuflow" folder?).
  10. Hi Rachel and Peter, We found that removing the -b switch kept the window up, which is okay when running models manually. Thanks. However, we prefer to manage the our runs in TRIM where possible. We have found the best workaround for us for the time being is to run the model in an earlier build of TUFLOW until you have a model that at least runs to the point of writing the log file, and then run it in the 2016 build from there. We have had similar 2016 crash with '..unable to complete triangulation' issues. 2016 build just closes , but 2013 build tells you what's wrong so you can bring the 2d_sh_obj_check.mif file and fix the problem. Thanks for your advice. Hopefully the next build resolves this issue. Kind regards, Francis
  11. Hi, We are modelling a fully submerged trunk drainage culvert with flood depth to invert > 7 m due to regional tailwater. There is hydraulic grade across the structure due to local upstream flows. Intitial water levels in both the 1d and 2d domain are set based on the regional tailwater. We have checked the time series results and the .eof file. At the beginning of the event, the water level in the culvert starts at the IWL/fixed tailwater condition, but then drops below by approx. 100 mm throughout the storm. Flow regime is 'F' (submerged entrance and exit, full pipe flow, downstream controlled), which is what we expect. We do not understand how the head in the 1d domain can drop below the tailwater conditions. We think the head drop at the outlet could related to the nodal area, as the automatically created nodal area table in the .eof stops just short of our fixed tailwater level. Is there a quick way extend the automatically created nodal area table of a 1d_nwk culvert, or do we need to take an alternate approach via an NA table and 1d table link? Regards, Francis
  12. Thanks Peter. Our preferred method is to manage our runs in TRIM software. I might check with the guys at Catchment Sim and see if the issue is due how the TRIM software interacts with the new build. An example of a recent issue causing the crash was a mistake in a line of code when using variable <<~s1>> in a new model. I had inadvertently included an extra '<' (i.e. <<<~s1~>>). Build 2016 just crashed straight away, and as it hadn't reached the line of code relating to the Log File path, there was no log file to open to find out why the model wouldn't start. To resolve - rather than searching through lines of code, I ran it in Build 2013 (even though it still crashed) and the TUFLOW run dialogue window told me straight away what the error was. Once this was sorted - I could then run in 2016. A similar issue occurs if the TUFLOW model build in the .tcf is different to the one we are calling up in TRIM. Regards,
  13. Hi, We have noticed that with the 2016-03-AA Build of TUFLOW, models will crash without an error. This is particularly frustrating when the crash occurs before the log file is written. Is there a way to keep the command window up to see what went wrong? Regards, Francis
  14. Hi, Could someone please help me understand the width column in the pit inlet database. As I understand it. TUFLOW uses this information to extrapolate beyond the depth/flow curve (Section of the TF manual). If we are modelling a kerb inlet pit (lintel only) would the width be the effective perimeter of the lintel opening? and if modelling a surface grate, would the width be the effective perimeter of the grate? Or alternately do we need to work backwards with an orifice calc to determine the width that gives the same flow at the top of the curve? Regards, Francis
  15. Hi, We generally use a materials file that contains a range of sixteen (16) different materials. Is it possible to get a colour palette created for use with the new materials .asc grid that can be imported into VM? Regards, Francis
  • Create New...