Groups Feed

Welcome to our group Lynett Wave Research Group! A space for us to connect and share with each other. Start by posting your thoughts, sharing media, or creating a poll.

The GPU version of the model is very inefficent at running 1D (horizontal) transects - there are simply not enough grid points to make good use of 1,000's of GPU cores. However, the GPU is efficient at running many 100's to thousands of transects at once. In this case, effectively, we are running a 2D simulation, where the x-dimension is the same (the distance along the transect), but the y-dimension is the "transect dimension." So, for example, y=1 is the first transect, y=2 the second, and so on. The physics model is reduced to 1D, so there is no hydrodynamic information being passed along the "transect dimension." This should allow for thousands of 1D transects to be run in near real time, the output of which could then be used to mine statistics, understand parameter sensitivity / uncertainity, etc. with a large number of transect samples. For example, lets say I…

You can now run simulations using the fully nonlinear extended Boussinesq equations. The implementation follows the equation and numerical model presented in Kim et al., 2009, minus the horizontal rotational terms. The equations are the conservative form of the Wei et al. model, also presented in Shi et al, 2012. The numerical scheme is a hybrid finite-volume / finite-difference approach, with leading order terms solved in a similar way as the standard Celeris solver, but using a 4th-order MUSCL-TVD scheme and an HLLEM flux solver, with a 4th order predictor-corrector time stepping integration. The implementation is essentially the finite-volume version of COULWAVE - very similiar to FUNWAVE-TVD. Tests show accuracy similar to these models.

The fully nonlinear / high order model should be considered experimental, and is likely not as stable / robust as the standard Celeris solver, particularly when interacting with the simulation (changing depth on the fly, etc.). The…

You can now add velocity vectors onto the rendered wave field:

In the "Modify Visualization" panel, you will now see three new options related to the vector arrow overlay:

You can choose to include vectors from either the instantaneous velocity field or the time-averaged velocity (current) field (as shown here). You can change the relative length of the arrows with the "scale factor" or increase/decrease the number of arrows displayed with the "density factor." By changing these two factors, you are able to display vector field detail on any scale of interest. For example, if I was interested in seeing the current profile in the immediate vicinity of one of the breakwaters in the above images, I could increase the density to a large value (e.g. 10 to 10x the number of arrows in both the x and y direction), increase the scale factor to larger value as well (e.…

It is a very experimental feature, but you can now add 3D boxes of arbitrary size, orientation, and location into the Explorer (fly-through) view. Any number of boxes can be added to the view. The box properties are contained in a json file (e.g. model.json), and are loaded through the interface - there is a new user input box for this. The json structure is straightforward, for example: {

"models": [

{

"id": "osm_188709102",

"type": "box",

"center": [

Finally figured out how to add a drone-type fly around mode. It was not easy, maybe getting too close to creating my own game engine... Now, from the Modify Visualization panel, if you choose "Explorer" as your View Mode, you can move through the scene in 3D. For example, with the Oceanside example, your starting "View Mode" view will look like this:

You can "fly" through the scene using the W [forward], S [backward], A [pan left], and D [pan right] keys to move. You can also hold the left button on your mouse and move around. To change your view direction, hold the right mouse button and move the mouse around. To move vertically up and down, use the wheel on your mouse, or the trackpad zoom-in (pinch) gesture. All other viz features work as they did previously. Note that if you want to lock the camera position to…

As more people are using the model, a common desired workflow looks like: 1) Create and fine-tune the model setup using the Web interface

2) Run various different cases, including modifications to water levels, waves, bathy/topo etc Right now step 2) is laborious, requiring alot of manual interaction, including loading the files for each case, clicking Run, setting up the desired output, and then curating (copying, processing) the output. With Chrome, it is possible to automate / script all of step 2). Chrome distributes a "chromedriver" browser application, which can be controlled externally via a library in Python (e.g. Selenium). An example script on how to do this is given below. Right now, the automation abilities allow the user to:

• Create an animated gif, starting at some specified time with a specified frame interval

• Output 2D surfaces of model data (e.g. free surface elevation, velocity) between some start and end times, at a…

Code updates: > Periodic boundary conditions are now functional for the Boussinesq model. Use with care however. Strictly speaking, the wave frequencies and directions in the waves.txt file should be chosen such that an integer number of waves "fit" along the offshore boundary. This is not checked. If you do not have this condition met, the periodic conditions will still work, but the model will artificifically lead to more short-crestedness, as wave crests leaving one boundary with not align with crests along the other boundary. > The model and rendering can now handle different dx and dy values. There are no model limits as to the ratio of these grid sizes. A primary recommendation would be, if surf-zone generated vorticity is of particular interest, do not use a ratio of > ~2 (or less than ~0.5), as this will tend to inhibit the generation of rotational flow. The time step …

I've been enjoying getting to understand setting up some custom models, and doing some comparison with other wave models I'm familiar with.

Something I am finding is that when inspecting the wave conditions within the model simulation, even at the boundary my significant wave height is considerably less than I would expect based on the input conditions.

I wonder if there is any guidance on what might be occurring, or how to address this.

Many thanks

Tom