Delft3DDelft3D community sitehttps://oss.deltares.nl/c/message_boards/find_category?p_l_id=1806765&mbCategoryId=02020-11-27T23:43:37Z2020-11-27T23:43:37ZRE: DELWAQ coupled with z-layer Delft3D FLOW model?Ben Williamshttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806765&messageId=14873082018-03-15T00:32:16Z2018-03-15T00:32:16ZHi Johnathan,<br /><br />Have you thought about purchasing an appropriate level of maintenance and support package?<br /><br />Cheers,<br /><br />BenBen Williams2018-03-15T00:32:16ZRE: suspended sediment and salinity from FLOW to WAQ?Ben Williamshttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806765&messageId=14764762018-03-06T02:34:43Z2018-03-06T02:34:43ZHi Johnathon (or Zhanxian?),<br /><br />I'm pretty certain WAQ imports salinity and temperature from FLOW, perhaps just as density field, as ambient water density is needed in order to simulate outfalls in WAQ. However I am not aware of any capability to import sediment quantities from MOR (via FLOW) to WAQ.<br /><br />WAQ does have a sediment transport module, albeit much simpler than MOR in terms of physics and numbers of sediment fractions considered.<br /><br />Are you interested in using suspended sediment concentration to estimate light extinction? <br /><br />Best regards,<br /><br />BenBen Williams2018-03-06T02:34:43ZRE: 3 dimensional model with 3 layersBen Williamshttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806765&messageId=12982762017-08-07T01:41:51Z2017-08-07T01:41:51ZHi Binata,<br /><br />You need to check the 'tri-diag' file in your modelling directory. This is a diagnostics file that often (but not always) gives you useful information on the error that is preventing your model from initialising. <br /><br />As the error is during the initialisation of your model, rather than during the simulation itself, the error is due to the way you have set up the model rather than anything numerical (such as timestep etc). Common things that can result in an error, and are typically mentioned in your tri-diag file:<br /><br />* An error in one of your boundary files<br />* The model starts at a time incompatible with the time stated in one of your input files<br />* A file is missing (grid, depth, etc)<br />* The simulation period is less than your specified smoothing time<br />* You have a problem with your Domain Decomposition (if using DD)<br /><br />Cheers,<br /><br />BenBen Williams2017-08-07T01:41:51ZRE: multi-port diffuserBen Williamshttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806765&messageId=12894552017-07-26T05:32:11Z2017-07-26T05:32:11ZDelft3D is a far-field model only. You'll need a plume model such as Cormix to 'simulate' the thermal plume in the nearfield and determine the transition zone from nearfield to farfield and therefore the initial dilution to apply in your model as well as the grid cells to apply the discharge within.Ben Williams2017-07-26T05:32:11ZRE: Unable to read subfields of sediment transport using qpreadBen Williamshttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806765&messageId=12801712017-07-14T01:50:10Z2017-07-14T01:50:10ZThanks Bert, I'll give that a go.Ben Williams2017-07-14T01:50:10ZRE: Boundary conditions in macrotidal estuaryBen Williamshttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806765&messageId=12785012017-07-12T07:19:38Z2017-07-12T07:19:38ZHi Fredrico,<br /><br />Those model domains are a work of art! They must have taken ages....<br /><br />I didn't see a scale on those diagrams but I am guessing the offshore and lateral extents of your ocean boundary is order of 50km for the domain on the left and 10km for the domain on the right. From a practical approach both seem pretty reasonable. The choice will depend on the physics of your coast (i.e. the way in which the tide propagates along or across your coastline, and the way the tide resonates within your estuary), and if you have tidal constituent available at multiple locations. <br /><br />Your stated (spring?) tidal range is 8m (at the ocean boundary?) and there is tidal amplification within the estuary, which suggests that tidal currents will be pretty large and therefore coriolis effect may alter your offshore tide by introducing a lateral gradient across the boundary. This lateral gradient can be quite appreciable for mid and high lattitudes. You don't mention if you have a single tide gauge or if you have data at multiple locations at your ocean boundary.<br /><br />If single tide gauge only (and the lateral extent of your model is very small relative to the tidal wavelength) I would be of the opinion to use the domain on the right, as the lateral extent is probably small enough that spatial gradients in surface elevation can be ignored. On the other hand, if tidal resonance is at play you need to make sure that your boundaries are far enough away from the estuary to not interfere with the tidal propagation within the estuary and its interaction wit the adjacent coast. As a first approximation, if the ebb tidal jet is able to reach your ocean boundary without dissipating then your boundary is too close as the assumption of uniform or smoothly varying surface levels is violated. <br /><br />It is more likely that the offshore boundary for the domain on the left is far enough away to not interfere with the tidal resonance within your estuary. However the ocean extent of your model is too large to assume a single water level across it, unless that what occurs in nature. If the tide propagates *along* your coast and water levels are constant in the cross shore dimension then you can assume neumann lateral boundaries with zero gradient through time. You will need to specify seperate tidal constituents at each end of your ocean boundary to capture the tidal wave as it propagates past your estuary. <br /><br />If the tide propagates directly onshore then you'll need to specify tidal levels at both your onshore and offshore corners of your lateral boundaries, and neumann lateral boundaries would not be appropriate. If you really need to use neumann boundaries, for example if you will have a wave model and therefore currents driven by wave set up and radiation stresses, then you can have a water level boundary from the offshore to say 15m water depth and then a separate nuemann boundary from the 15m deoth to the shore. If the distance from shore to 10 or 15m contour is say 1 or 2km then assuming zero tidal gradient in the cross shore is pretty valid <br /><br />You'll be able to tell if the tide propagates in the along or cross shore dimension by looking at a co-tidal chart of the area.<br /><br />So, not exactly a clear answer but hope this helps a little. It looks a really interesting area and i wish you luck with your endeavours. <br /><br />All the best, <br /><br />BenBen Williams2017-07-12T07:19:38ZRE: Help with Matlab and grid cell average of horizontal velocityBen Williamshttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806765&messageId=12254182017-05-12T03:11:13Z2017-05-12T03:11:13ZHi Guilherme,<br /><br />If you want to plot the values as a map then you can use either 'pcolor' or 'quiver' as builtin matlab functions, or 'colquiver' found in the quickplot matlab functions (which have to be added to your matlab path). <br /><br />figure<br /><br />% Plot U component <br />subplot(2,1,1)<br />pcolor(G.X( 70:110, 36:90),G.X( 70:110, 36:90),squeeze(U_mm)); shading flat; clim([-0.5,0.5]); daspect([1,1,1]); grid on<br />ylabel('m N'); xlabel('m E')<br />colorbar<br />title('U component (depth-averaged)<br /><br />subplot(2,1,2)<br />pcolor(G.X( 70:110, 36:90),G.X( 70:110, 36:90),squeeze(V_mm)); shading flat; clim([-0.5,0.5]); daspect([1,1,1]); grid on<br />ylabel('m N'); xlabel('m E')<br />colorbar<br />title('V component (depth-averaged)<br /><br />% Note that you may have to transpose the U_mm or V_mm on order to match dimensions of the grid. squeeze(U_mm)'; %(note the ')<br /><br />% quiver plot<br /><br />figure<br />quiver(G.X( 70:110, 36:90),G.X( 70:110, 36:90),squeeze(U_mm),squeeze(V_mm))); daspect([1,1,1]); grid on;<br />ylabel('m N'); xlabel('m E')<br />title('Quiver plot)<br /><br />% plot quiver with colours <br /><br />figure<br />colquiver(quiver(G.X( 70:110, 36:90),G.X( 70:110, 36:90),squeeze(U_mm),squeeze(V_mm)),sqrt(squeeze(U_mm).^2+squeeze(V_mm))); grid on; daspect([1,1,1])<br />clim([-0.5,0.5])<br />title('Colour Quiver plot)Ben Williams2017-05-12T03:11:13ZUnable to read subfields of sediment transport using qpreadBen Williamshttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806765&messageId=12134212017-04-27T10:05:15Z2017-04-27T10:05:15ZHi,<br /><br />I have a 3D simulation considering transport of multiple sediment fractions. Using QUICKPLOT I am able to load and visualise the sediment transport fields of each sediment fraction. For example, d.a. suspended transport for subfield 'Sediment1'. <br /><br />I remain, however, unable to load the same data in matlab using qpread function. It seems stubbornly unable to read subfields from trim files. <br /><br />If qpread could handle reading griddata of subfields from trim files, I assume the code would go something like...<br /><br />% Get info on subfields to read in for depth-average sediment transport<br />dpath = '..\Runs\Test003\';<br />F = qpfopen([dpath,'trim-FLOW.dat']);<br />FLDS = qpread(F,0);<br />SBFLDS = qpread(F,0,'d.a. suspended transport','subfields');<br /><br />% read in data for first subfield (first sediment fraction), all timesteps, all grid cells:<br />S1 = qpread(F,0,'d.a. suspended transport','griddata',SBFLDS{1},0,0,0);<br /><br />However, no matter what I try, I keep getting get a 'Index exceeds matrix dimensions' error. <br /><br />The offending function is 'd3d_trimfil' at line 118, with the dimensions of variable 'idx' not matching that of varargin(2:end). Although at first sight it seems a relatively simple bug fix, it's not that obvious how to do it such that the dimensions are handled correctly for all cases rather than just the one particular instance. <br /><br />Has anybody solved this problem? It is possible to hack DETRAN to give you what you want, but it's a pain in the arse - especially if curvilinear grid as vs_let only exports u,v, not x,y components. It would be better if qpread could just load in the data and give you what you want as either u,v / x,y/ m,n components. <br /><br />Cheers,<br /><br />BenBen Williams2017-04-27T10:05:15ZRE: Read/plot curvilinear sediment transport field with MatLabBen Williamshttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806765&messageId=12134102017-04-27T09:53:05Z2017-04-27T09:53:05ZHi Stephan,<br /><br />I have the same problem: I want to read in sediment transport fields for simulations considering multiple sediment fractions. <br /><br />Normally one can read in fields using <strong>qpread</strong> function, but it this function seems stubbornly unable to read subfields from trim files. <br /><br />Assuming qpread can handle it, the code would go something like...<br /><br />% Get info on subfields to read in for depth-average sediment transport<br />dpath = '..\Runs\Test003\';<br />F = qpfopen([dpath,'trim-FLOW.dat']);<br />FLDS = qpread(F,0);<br />SBFLDS = qpread(F,0,'d.a. suspended transport','subfields');<br /><br />% read in data for first subfield (first sediment fraction), all timesteps, all grid cells:<br />S1 = qpread(F,0,'d.a. suspended transport','griddata',SBFLDS{1},0,0,0);<br /><br />However, no matter what I try, I keep getting get a 'Index exceeds matrix dimensions' error. <br /><br />The offending function is 'd3d_trimfil' at line 118, with the dimensions of variable 'idx' not matching that of varargin(2:end). Although at first site it seems a relatively simple bug fix, it's not that obvious how to do it such that the dimensions are handled correctly for all cases rather than just the one file. <br /><br /><br />FYI: A workaround I found (very unsatisfactory) is to hack DETRAN to give what I want. <br /><a href="https://svn.oss.deltares.nl/repos/openearthtools/trunk/matlab/applications/detran/detran_engines/detran_d3dTrans_single.m">https://svn.oss.deltares.nl/repos/openearthtools/trunk/matlab/applications/detran/detran_engines/detran_d3dTrans_single.m</a><br /><br />You only need lines 141 to 192. Substitute 'names' for your trim file name (and path).<br /><br /><strong>It would be much better if qpread could read subfields directly from trim files - has anybody solved this?</strong><br /><br />Cheers,<br /><br />BenBen Williams2017-04-27T09:53:05ZRE: Vertical mixing in a 3D model with a temperature gradientBen Williamshttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806765&messageId=12009312017-04-13T01:13:52Z2017-04-13T01:13:52ZHi Frank,<br /><br />Are you asking the question in the official capacity of Deltares? If so, let me know your email address and I will start a dialogue with you offline.<br /><br />I think there remains improvements to be made in the z model with parallel, particularly in artificial mixing along MPI boundaries. I used several tagged versions, the most recent dating from June 2016. I recognise that several improvements have been made since then but it was a difficult site with multiple numerically challenging aspects. <br /><br />Lets see if we can work together on this.<br /><br />Regards,<br /><br />BenBen Williams2017-04-13T01:13:52ZRE: Vertical mixing in a 3D model with a temperature gradientBen Williamshttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806765&messageId=11835602017-03-25T22:52:38Z2017-03-25T22:52:38ZHi Fernando, <br /><br />After some months of pain I did find a solution. There were multiple problems that I was dealing with. <br /><br />My suggestion to you is :<br /><br />1) Forget using the z layer model with parallel. There are simply too many problems with it. <br />2) If a temperature gradient exists in either the horizontal or vertical, the courant number for baroclinic terms requires a very fine time step to satisfy relative to barotrophic terms. I had to coarsen my horizontal grid by factor 5 to achieve realistic time step. Dx=dy=150m.<br />3) it's really hard to stop layers below surface interfering with surface layer. Try describing your gradient with at least 5 layers, bearing in mind the limitation of each row only being 1. 2 or 0.8 that of adjacent cells . If your tidal range is greater than surface layer thickness this is also a problem that is hard to beat. <br /><br />Might help if you post more details of your model setup <br /><br />BenBen Williams2017-03-25T22:52:38ZRE: Medium-term Modelling using delft3d (stationary or non-stationary)Ben Williamshttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806765&messageId=11718662017-03-14T22:01:11Z2017-03-14T22:01:11ZHi Ruchira,<br /><br />Thanks for putting up the post to that email thread! I was unaware that there was continued discussion in the years after I posted, and there is some useful and relevant information there. <br /><br />In the end in desperation I had to resort to using SWAN as a stand-alone wave model, and prepared the wind files in a format that it could read. My situation was different as I was only after nearshore wave parameters, not boundary conditions for sediment transport.<br /><br />Unfortunately I'm not able to advise for your specific situation and I don't know if Deltares ever solved the problem. <br /><br />If you do discover a solution, please post your findings here :-)<br /><br />Best regards,<br /><br />BenBen Williams2017-03-14T22:01:11ZRE: Medium-term Modelling using delft3d (stationary or non-stationary)Ben Williamshttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806765&messageId=11693492017-03-12T09:35:58Z2017-03-12T09:35:58ZHi Ruchira,<br /><br />To me that looks like a good calibration and you should be proud. <br /><br />If I am to understand what you have written, you have used a global/ regional wave model as boundary conditions to your 'coastal scale' model, and then calibrated certain numerical parameters to try and best reproduce integral wave parameters (Hm0, Tp, MWD etc.) measured at a wave buoy near your site of interest. <br /><br />It is pretty difficult to get a global model to reproduce fine-scale wave processes, so in part your results show the quality of the ERA-interim model you have used as boundary conditions. However, this means that your under-prediction may not be an artefact of your Delft3D model but instead an artefact of the ERA-interm model at the location you have used as boundary conditions. If true, it will be hard for you to 'bump up' your wave height at the calibration point without adding energy - e.g. increasing wind speed a bit. <br /><br />In terms of parameters in vary in the calibration, you have investigated JONSWAP. The other parameters one could try might be: <br /><br /><br />* Other bed friction formulations<br />* Wind growth processes<br />* Whitecapping formulation<br />* Depth-indiuced braking alpha and gamma values<br />* Accuracy/ resolutrion of your frequency spectrum<br />* Discretisation of your directional spectrum<br />* Presence of surge during storms<br /><br /><br />The wave height is most underestimated during the storm so I might try with increasing wind speeds first. <br /><br />You don't show your bathymetry but if there are strong 2D features - such as canyons or offshore sandbanks - then these can act to strongly refract waves depending on thier incident direction and frequency. If these features are present then I would try increasing your directional and frequency resolution.<br /><br />If your wave buoy is in shallow water then you might need to look at your wave breaking coefficeints in more detail. <br /><br />If your calibration site has directional spectra available then this is often very useful for drilling down in to the details of how well your model is performing - is it getting the frequency shape correct, is it getting the peak and mean directions correct. <br /><br />Lastly, models calibration are usually also quoted as error (such as Mean Absolute Error, Bias, Scatter Index, Correlation Coefficeint, Skill, Root Mean Square Error, etc.) to the measurements. If you are unable to improve your calibration then at least you will know to what accuracy your model results are.<br /><br />Cheers,<br /><br />BenBen Williams2017-03-12T09:35:58ZRE: how can i use Van Rijn 2004 transport formula?Ben Williamshttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806765&messageId=11645122017-03-07T06:37:12Z2017-03-07T06:37:12ZHi Zahra, <br /><br />I stand corrected - TRANSPOOR2004 requires IFORM = -2. <br /><br />Accessing the various different sedimnet transport formula is relatively straight-forward. See FLOW manual section B9 for details. <br /><br />1) Use the keyword #TraFrm# in the MDF file (you specify this in the 'Additional Parameters' tab). <br />2) Use value #TRANSPOOR2004.tra#<br /><br />From memory I think you need to include the # each side of the key word and value as it is text not just number.<br /><br />The 'tra' file is just a free-format ASCII text file. An example format is given in the FLOW manual pg 568. Its a bit simpler for Van Rijn 1993 and 2004 formulae, as no other parameters (as described in Table B9) are required. Try copying and paste the follwing text to an ascii file (hopefully this works): <br /><br /><br /><br />-2 Number of transport formula IFORM<br />*--------------------------------------------------------<br />#-2 TRANSPOOR2004<br /># End of specification of transport relation<br /><br /><br />You don't need to enter any other additional parameters as they are already taken from the SED and MOR file.. Other transport formulae may need various parameters defining (as described in table B9) but you are not using any of these at present. <br /><br />Good luck,<br /><br />BenBen Williams2017-03-07T06:37:12ZRE: how can i use Van Rijn 2004 transport formula?Ben Williamshttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806765&messageId=11635482017-03-06T05:02:14Z2017-03-06T05:02:14ZMy understanding is that this is the default sedimnet transport algorithm in Delft3D.<br /><br />For using other transport formulae, look at Table 11.1 (FLOW manual pg 347) and IFORM numbers as defined in Table B8 (FLOW manual pg 566).<br /><br />Others can comment but I think when the FLOW manual refers to Van Rijn (2000), it really means the TRANSPOOR2004 algorithm as described in Van Rijn 2007.<br /><br />Best,<br /><br />BenBen Williams2017-03-06T05:02:14ZRE: Berm creation in stormy condition!!Ben Williamshttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806765&messageId=11635402017-03-06T04:55:03Z2017-03-06T04:55:03ZZahra,<br /><br />Some thoughts:<br /><br />1) Your wave condition is a bit extreme and is showing on-shore directed dissipation even at the boundary. Have you tried a wave that is not breaking at the boundary? For example, a 2m wave? It's hard to work out what the depth is at your boundary but typically one would want it not to be breaking or dissipating. <br /><br />2) Is your model 2DV (as in beach profile model, just one grid cell wide) or fully 3D? If 3D, plot a map of current vectors for top and bottom layers. Just to see what is going on and if there are any spurious currents being generated at your boundary. Are there any long-shore currents at the site? Superimpse on the vector map bathymetric contours of your site (suggest 1m or 2m intervals).<br /><br />3) You seem to be plotting variables for different cross-sections (m =25 vs m=50).<br /><br />4) What is your wave incidence angle are the lateral boundaries of your wave model much greater in spatial extent than your flow model?<br /><br />It's not unusual to get behavior like this but seems typically related to the way one sets up the model (grid design, bathymetry etc) and boundary conditions. <br /><br />BenBen Williams2017-03-06T04:55:03ZRE: Waves distorting harmonic tides, help?Ben Williamshttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806765&messageId=11580412017-02-28T10:16:17Z2017-02-28T10:16:17ZHI Curtis,<br /><br />Maybe try simplifying your model a bit until it works and then gradually build up complexity. Your site looks quite complicated in terms of rapid changes in depth and wave/current processes occuring.<br /><br />For example, remove the tidal signal from your east boundary. Close off your west boundary (make dry land) and then keep the north and south as Neumann boundaries. Then you can check to see what the water level is doing, and also check map outputs of your current magnitude and direction. <br /><br />In general you need your wave model to be the same resolution or finer than your flow model. This is especially the case where you have wave breaking, which is clearly occurring at your site. <br /><br />You also don't make clear which is your flow model grid - is it (2) or (3)? (1) probably won't work as your boundaries are too close to the island. <br /><br />It is usually better to have your flow model aligned so that it runs parallel to some bathymetric contour. Given the geometry of your island I would be tempted to do just that, running your flow model in a curvilinear fashion from NW to SE along say the 20m contour. Admitedly this is probably not that easy. The goal is to try to locate your boundaries far enough away from the area of current generation (breaking waves in the nearshore and around the island), but whilst keeping your flow model in water shallow enough that you don't have to have a tiny time step to satisfy your courant number. <br /><br />You could try a simple 'toy' model that is a simple sketch of the physical processes at your site. That is, heavily schematised and simplified. Just an island of approximate dimension and depth, but with much simplified bathymetry on the island and the surrouunding area. Then experiment with what grid resolutions work and how your boundary design affects your model stability or predicted currents. To do this it might help to output time series of water level, current speed and direction, and wave height, period, direction and orbital velocity at various locations around your island. <br /><br />Then, once you think you have a reasonable idea of how things are behaving in your model, build up complexity until you have a reasonably realistic approximation of your site. Do you have validation data?<br /><br />Good luck.<br /><br />BenBen Williams2017-02-28T10:16:17ZRE: Medium-term Modelling using delft3d (stationary or non-stationary)Ben Williamshttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806765&messageId=11567852017-02-27T07:51:42Z2017-02-27T07:51:42ZHi Ruchira,<br /><br />Others may correct me on this but:<br /><br /> * Unless you are considering waves generated or appreciably modified by wind between the boundary and your area of interest, stationary computations are the way to go. You might glean some idea about how important about stationary vs non-stationary wave simulations are by comparing predictions from your model with that measured by wave buoy at or near your site of interest. You could also try analysing the relationship between wind speed and direction and the wave hieght, period and direction you are applying at your model boundary. <br /><br />* For coastal applications you don't normally need to worry about writing hotstart files for SWAN. Numerical convergence is usually achieved fairly rapidly if you have specified your directional and frequency resolution adequately. <br /><br />* If you are simulating morphology, it usually pays to keep your model as simple as possible. Some find this a good approach as it forces you to think about exactly what process you are trying to capture in your model and how you should interpret the results. <br /><br />* Setting the coupling interval between WAVE and FLOW model is usually a compromise between computational accuracy (in theory, more frequent coupling is better) and computational efficiency (less frequent coupling is better). If your site is tidal then as a very rough first guess hourly coupling is a practical and useful interval. You will need to check if increasing or decreasing the coupling interval has an influence on your final morphological prediction. If your site is very tidal (range or rapidly changing wave and current conditions) then this can be an indicator that you need to have more frequent coupling. <br /><br />* Morphological models are typically in the order of 1km offshore vs 2-5km alongshore. Rather than the 160km you seem to be implying. <br /><br />* Writing hotstart for FLOW model can be useful and I would suggest either 12.5 hours (i.e. tidal cycle) or 24 hours. But really you only need to write hotstart files if you think you will need to restart your simulation halfway through. Otherwise you can forget about them. <br /><br />* It might not be that surprising that you are getting the same results for (Case 1) and (Case 2), as you are essentially applying a static wave condition at the boundary and applying a static wind conditions across the model domain. The difference between (Case 1 + 2) and (Case 3) might be one of numerical convergence, but it is hard to say with the information provided. <br /><br />* References: There are rather numerous references that a google search will reveal. Papers and books contributed by Dano Roelvink are the place you should start. <br /><br />Success,<br /><br />BenBen Williams2017-02-27T07:51:42ZRE: Berm creation in stormy condition!!Ben Williamshttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806765&messageId=11519132017-02-22T07:28:32Z2017-02-22T07:21:29ZZahra,<br /><br />Very useful diagnostic plot. You do indeed have currents moving offshore at the bed but apparently onshore movement of sediment. Are you simulating fine/ medium sand (which can be transported in suspension by waves), or coarse sand/ gravel (which are almost exclusively bedload)?<br /><br />If coarse sand / gravel, then you will get onshore movement because the offshore currents generated by the waves cannot move the sediment. The current-related transport is typically negligible, which means that the wave-related load is doing all the work. In this case Delft3D assumes transport is purely in the wave direction and there is little you can do about this. [Other than increasing your wave height and period, but then is this the scenario you want to considerr?]. <br /><br />Typically tweaking fsusw is all about trying to achieve a balance between the wave-related load, which is imposed in the wave vector at each cell, and the current-related load, which is imposed in the current vector at each cell. <br /><br />If fine/ medium sand, some suggestions:<br /><br />1) I see that your resolution is something like 10m, yet your profile is quite steep (1V:10H?) compared to sandy beaches. It is possible that you are not adequately capturing your wave breaking, which you want to occur over about 5 grid cells in order to get wave dissipation , currents and transport correct. Smaller waves break over a shorter distance, as do shorter period waves. As a practical guide, aim for ~5m resolution in the breaking zone as a starting place.<br /><br />2) Reproduce your plot, but with wave height and dissipation instead of current vectors. This will inform if you are adequately describing wave breaking, which in turn is driving your morphology. <br /><br />3) A similar plot, but showing suspended sediment concentration in each cell. On the same plot, show somehow the direction and magnitude of transport on the bed at each grid cell (or every few grid cells) along your profile. <br /><br />If nothing works then this is telling you something about the physicality of your scenario, and you might try changing either the sediment diameter or beach slope until you are simulating conditions that would typically have offshore migrating bars in real life (e.g. Duck, Edgmond). Noting that getting onshore/offshore bar migration even vaguely correct in morphological models is a tricky business. <br /><br />Best,<br /><br />BenBen Williams2017-02-22T07:21:29ZRE: Waves distorting harmonic tides, help?Ben Williamshttps://oss.deltares.nl/c/message_boards/find_message?p_l_id=1806765&messageId=11518872017-02-22T06:57:53Z2017-02-22T06:57:53ZHi Curtis,<br /><br />This is a numerical problem. <br /><br />Some first guesses as to what may be causing it:<br /><br />1) Check for instabilities caused by depth-induced wave breaking at your boundary. Make sure you don't have breaking waves at your boundary, unless this is on purpose and occurs over ~5 grid cells. <br /><br />2) Your spin-up interval could be insufficient, especially if you are causing a perturbation at the beginning of your simulation by not starting the water level at the exact same level as that specified at your boundary. Either improve your starting condition toy match your boundary, or wait for oscillations to die down before starting the wave coupling. <br /><br />3) Either your your timestep or your grid resolution may be insufficeintly fine for fully coupled wave-current simulations. <br /><br />Best,<br /><br /><br />BenBen Williams2017-02-22T06:57:53Z