Is there a known BUG when using Zmodel and Temperature?Is there a known BUG when using Zmodel and Temperature?https://oss.deltares.nl/c/message_boards/find_thread?p_l_id=1806746&threadId=11441962020-11-26T07:14:27Z2020-11-26T07:14:27ZRE: Is there a known BUG when using Zmodel and Temperature?Phillips Georgehttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806746&messageId=34423342020-10-10T09:59:31Z2020-10-10T09:59:31ZThanks for addressing this topic. I was looking for the information regarding the sameĀ <a href="https://www.upsers.run/">Upsers</a>Phillips George2020-10-10T09:59:31ZRE: Is there a known BUG when using Zmodel and Temperature?Frank Platzekhttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806746&messageId=11913612017-04-03T13:51:05Z2017-04-03T13:51:05ZDear Evangelos,<br /><br />From your question and the previous respnses, I would deduce two points:<br /> <br />1) For a 50m horizontal grid size, and an 8m vertical grid size (40 meters depth with 5 layers), I would say that a 15 min time step is very optimistic, in particular for the partly explicit z-layer model.<br />I think the previous comment made by Ben to check what the Courant numbers are in QuickIn/QuickPlot, is a good idea. Based on water depth only it might be that the Wave Courant number (based on sqrt(g*H)) can still be as high as e.g. 10, but the Courant number for flow (based on u) should be below 1, since the advection is explicit in the z-layer model (both for momentum and for scalar transport). Probably one would end up with a time step around 10-30 seconds, assuming flow velocities around 1m/s.<br /><br />2) I am not sure whether you are using MPI or whether want to use it, but for the 1 km2 domain, with 50m cells, you should have about 20x20 cells (if I understood your dimensioning correctly), so I do not think that parallelization is really needed. Delft3D should be able to do this computation fairly efficiently, even with time steps of 10-30s.<br /> <br />One additional point: If the model does not remain stable with a smaller time step, It might be that there is a (strong) mismatch between the initial and boundary conditions causing the large water level gradients.<br /><br />Best regards,<br />FrankFrank Platzek2017-04-03T13:51:05ZRE: Is there a known BUG when using Zmodel and Temperature?Ben Williamshttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806746&messageId=11459582017-02-16T03:38:00Z2017-02-16T03:38:00ZHi Evangelos,<br /><br />A 15 minute timestep for a 50m grid does not sound stable to me. Use QUICKIN to check the what time step you need to achieve a courant number of less than 8. This is the maximum timestep you can get away with to keep your model stable if not considering transport of e.g. heat or salinity. <br /><br />There are other courant numbers to satisfy transport of salnity and heat. The z model imposes additional constraints, especially if your bathymetry is in such a way that some cells near the coast are very thin at certain depths. Using MPI also adds additional numerical challenges. <br /><br />Look in the manual to see what courant number applies to your simulation and then see if you can work out a commensurate time step. Sometimes the tool in QUICKPLOT helps but it is simple and a guide only.<br /><br />I would recommend not using MPI at first, and coarsen your horizontal gird by a factor of (say) 5 to a simple 'toy' model that captures the relevant physics but is quick to run. <br /><br />Once you are progressed enough to look at upwelling, make sure you also check to see if you need to use the non-hydrostatic solver. Particularly if you have internal waves present in the model. <br /><br /><br />Best,<br /><br />BenBen Williams2017-02-16T03:38:00ZRE: Is there a known BUG when using Zmodel and Temperature?Evangelos Romashttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806746&messageId=11449992017-02-15T09:27:05Z2017-02-15T09:27:05ZHi Ben,<br /><br />thanks for your comments.<br />You are right, my initial intention was to explore upwelling but then, in order to locate the problem, I simplified the case study. I used uniform bathymetry 40m (to avoid thin layers), I used 5 z layers 20% each, I disabled all discharges, heat fluxes and boundary conditions, I set a uniform initial temperature 15oC in all cells (so the Temperature solution should be 15oC always/anywhere) and I am only using a uniform wind with (<1m/s speed). <br /><br />I cannot figure out why such a simple case still requires a 2 second timestep to avoid crash.<br /><br />I am also thinking that the instability problem originates from the Van-leer transport solver but the same solver with a sigma model (where theoretically thinner layers may appear over shallow areas) runs fine with normal time-steps (e.g. 15 min). Is it the combination of Zmodel with Van leer transport solver that causes the instability?<br /><br />Thanks again for sharing your thoughts.<br />EvangelosEvangelos Romas2017-02-15T09:27:05ZRE: Is there a known BUG when using Zmodel and Temperature?Ben Williamshttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806746&messageId=11447772017-02-15T02:35:54Z2017-02-15T02:35:54ZHi Evangelos,<br /><br />My impression of the heat and salinity model in Delft3D is that it imposes quite strict limits on the timestep when there is a density gradient (temperature, salinity). I have found from several uses in the past that dt~2s is required for the model not to fall over when using ~50m grid size with low current speeds. Depending on the density gradients, the numerically stable timestep for transport of heat and salt can be is <<1s. <br /><br />There are also several other problems with the z model with temperature and salinity when using MPI if the timestep is too big (and even if the timestep is not too big), if you your temperature and salinity initial conditions vary in the horizontal and vertical dimensions. <br /><br />Try with dt=0.05m and also check how you are defining the temperature at your boundaries (including any thermal discharges), just in case there is a large thermal gradient in one of your layers. <br /><br />Also make sure that your z model vertical layers are defined adequately, such as smooth transition of layer thicknesses between cells. From memory adjacent layers cannot be wider/ thinner than 1.2/0.8 of the adjacent neighbouring layer. If strong vertical gradients you need to have a finer vertical spacing.<br /><br />I am assuming that you are wanting to look at density processes (such as upwelling) in your model. Otherwise, from a stability point of view you would be better to switch off transport of heat and salt as these won't hugely affect horizontal currents in the surface wind-diriven layer.<br /><br />Further guidance on numerics are given in the FLOW manual. <br /><br />Best regards,<br /><br />BenBen Williams2017-02-15T02:35:54ZIs there a known BUG when using Zmodel and Temperature?Evangelos Romashttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806746&messageId=11441952017-02-14T13:27:36Z2017-02-14T13:27:36ZHello,<br />I am trying to simulate wind driven currents in a small (1 km2) reservoir of 40m uniform depth with d_hydro in a 50m x 50m grid. <br />I am able to run a Z-model with 5 layers with a 15 minutes timestep and results seem quite reasonable. My problem is that when enabling temperature process (even without enabling any heat flux model) the simulation requires very small time-step (e.g. <0.1 minutes) otherwise it crashes with the "Water level change>25.00 m..." error. <br /><br />I noticed that transport solver changes to explicit Van Leer scheme when using Temperature + Zmodel, but this can't be the problem since, a sigma model with the same setup (temperature enabled + Van Leer scheme as Transport solver) runs fine with a 15 min timestep and even larger ones.<br /><br />So does anybody have an idea about why Zmodel behaves so badly when temperature process is enabled?<br /><br />Best regards<br />EvangelosEvangelos Romas2017-02-14T13:27:36Z