Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About kfrodsham

  • Rank
  1. Hi Katie, If I understand your set-up correctly, you are trying to link ISIS direct to ESTRY not TUFLOW. Therefore you will not need a DUMMY HT boundary since this is only needed when linking an ISIS node direct to TUFLOW (via a SX link). I suspect that what could be happening in you model (providing the ISIS-ESTRY link is configured OK- NB a X1DH link might also be best at the upstream end of the FRC) is that the ISIS HT boundary is controlling the conditions at the upstream extent of the FRC - noting that if your HT boundary values are lower than the invert of the FRC, you will not get any flow through the FRC. Hope this helps, Kevin
  2. Hi, I've also seen this problem a few times when modeller's have added interpolate sections to the 1D model (in this case ISIS) subsequent to the initial 1D-2D build but then omitted to update the 1D network layer. However, if it's ESTRY you're using I guess it would be more difficult to arrive at this situation. Cheers, Kevin
  3. Hi all, I am currently trying to model an area in which one newish property has a sizeable 'void' beneath it that was designed to accomodate some flood storage. I am wondering how best to model this; given that I have a base (invert) level for the void, current ground floor levels and can assume a certain floor thickness. I have tried using a layered flow constriction with Layer 1 (the void), Layer 2 (the 'solid' floor with 100% blockage) and Layer 3 for above the ground floor but have noted that the 2D water level being calculated often lies within Layer 2 (the supposedly impermeable layer) so I am concerned that the storage capacity of the void is being exceeded when using this approach. Therefore, can anyone suggest a (simple ) 2D solution to this type of issue which would more accurately utilise the underground storage capacity or will I have to consider using ESTRY? Thanks, KF
  4. Diane, I've had it twice so far using TUFLOW 2011 builds yet one of these modelled works fine with TUFLOW 2010 so it might be worth sending the model details to TUFLOW support. If in a hurry you could try reducing the cell size or extent of the model grid but this is probably not going to be an ideal solution. Cheers, Kevin
  5. In case someone encounters this "Node duplication" error in future, I have now discovered what was causing my model to flag this error. In this instance the problem was caused by having a culvert unit in the ISIS model directly connected to river sections at either end (not recommended) rather than being connected via junction units (the recommended way). The supplied ISIS model ran fine on its own with this type of culvert configuration but the link had problems reading this unexpected setup in the DAT file.
  6. Any news on a solution or best way around this problem. I'm trying to construct an ISIS-TUFLOW model from an 'oldish' ISIS model and keep hitting on this problem. Have tried a few ways around it but with no success so far. May now try rebuilding the ISIS model from scratch in 3.3 (only 120 nodes so not impossible!!). Thanks, Kevin
  7. Has anyone tried connecting an ISIS model with user defined ReFH inflow units (with observed rainfall and estimated ReFH parameters) to TUFLOW yet? I have an ISIS model with inflows of this type which runs fine on its own but when linked to TUFLOW the model grinds to an instant halt reporting 'fatal errors in ReFH'! I can get around this easily enough by converting the ReFH calculated flows in the standalone ISIS model to QT boundaries but this is not an ideal long term solution. If anyone has found another way around this problem by maintaining the ReFH inflows then some advice would be appreciated. Regards, Kevin
  8. Vicky, This error is due to a bug in the link which Halcrow are aware of and are working on but to date I am am not aware of a definitive solution. I have come across the error 3 times and the best approach seems to be to try using an earlier version of TUFLOW (eg 2006-06-BF). Alternatively as a temporary solution I managed to by-pass the error in one model by deleting surplus HX lines (ie those which are unlikely to be overtopped). Hope this helps, Kevin
  9. I have recently had a small but notable number of TUFLOW model runs that fail to write the results to disk even though the simulations run through to completion. Sometimes the results stop being recorded half way through model runs and sometimes it is only the maximums that fail to be recorded. Occasionally but not always this is accompanied by a 'disk write fail error' message box in the Windows Task Bar. This is oviously frustating when it happens during longer model runs so is there anyone out there who knows why this happens and who can provide any tips on how to minimize the number of unrecorded model runs?
  10. I am in the process of setting up a new ISIS-TUFLOW model and shortly after the start of the model run the software stops running and displays a WIndows box headed 'Visual Fortran run-time error' with the following message: forrtl: severe (157): Program Exception - access violation Image PC Routine Line Source TUFLOW_LINK.dll 100B551C Unknown Unknown Unknown TUFLOW_LINK.dll 1018E12A Unknown Unknown Unknown ISIS_TUFLOW.exe 0043888B Unknown Unknown Unknown The message only appears when I try to run this model. Hopefully someone could advise me of the cause of this error and, if possible, how to by-pass it?
  • Create New...