To see this working, head to your live site.

Automation & Running through Python

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 specified time increment
Output wave height and water level statistics. The user needs to specify a time to start determining the mean water level (this should be the time when the simulation has reached quasi-steady conditions, usually between 5-15 minutes, depending on the bathymetry), a time to start determining the wave height statistics (usually 10-15 minutes later), and finally a time to write the wave height surfaces, after which the simulation will terminate.

An example Python script with required files is attached, and a more complete (and living) example can be found at the github (https://github.com/plynett/plynett.github.io) in the "automation" directory. As you will see from the example, you will need to download the "chromedriver" application, which can be found here for various OS's:

https://googlechromelabs.github.io/chrome-for-testing/ I recommend using the "Stable" version, and download the "chromedriver" zip for your system. Hopefully the Python script is fairly understandable. You can see that running any configuration that does not need interactivity during the simulation can easily be configured with this script. It should also be straightfoward to use this script, or a variant of it, within a batch-type workflow, running many simulations in sequence.

7 answers0 replies

Comments (7)

JoseB

May 07

A note here to warn folks that if/when Chrome updates, you also need to update chromedriver... Chrome updates automatically, chromedriver doesn't.

Mathieu SOULAYROL

Apr 24

Hi Patrick,

I’m trying to drive Celeris with incident_wave_type = 5 in my config.json (“Time Series from loaded file”), but I can’t find anywhere the exact syntax you expect for that text file.

I still have one of our old “custom spectrum” forcing files that we created for earlier tests—let me know if you’d like me to share it. In the meantime, could you confirm:

How many columns are required, and in what order?
Which physical quantities go into each column, and what units?
Whether the first column (time) can be omitted if I set a fixed interval in the JSON?
Any requirements on delimiters, header lines or decimal formats?

Thanks for your help!

Patrick Lynett

Apr 24

Replying to

Hey Mathieu- The "Time Series from loaded file" option isnt functional yet. Do you mean incident_wave_type = 4 ("Custom Spectrum from loaded file")? This is the option that allows you to input a spectrum file (not a time series), and is the default option when using west_boundary_type = 2 (or east, north, south). In this case, you are driving a simulation with a set of [amplitude, period, direction, phase] individual components. If you have "count" individual components, the waves.txt (the waves file), should be formatted as:

fileID = fopen('waves.txt','w'); line1='\n';

line2=['[NumberOfWaves] ' num2str(count) '\n'];

line3='=================================\n';

for i=1:3

eval(['cline = line' num2str(i) ';'])

fprintf(fileID,cline);

end

for i=1:count file_data(1)=amp(count);

file_data(2)=period(count);

file_data(3)=theta(count); % this is the angle in radians w.r.t. numerical grid) 0=from west, pi/2=from south, pi=from east, -pi/2or 3*pi/2 from north

file_data(4)=phase(count); % component phase in radians

cline=[num2str(file_data '\n'];

fprintf(fileID,cline); end

So you have a file that looks like: [NumberOfWaves] 990

=================================

0.00647705 22.2222 1.24697 4.20537

0.00678913 22.2222 1.57075 3.96944 ... Typically, when I am creating this input file, I have a gridded energy density spectrum (either from the field or from TMA / JONSWAP), convert this energy density spectrum into a discrete amplitude spectrum, and then write only the components above some threshold energy. The Matlab scripts I have provided in the tutorials do this for you, but the above is the format and approach.

JoseB

Apr 10

Thanks Pat, much appreciated!

JoseB

Apr 09

Hey Pat,

Great stuff, I think I have it working for my test case. A few clarifications:

This is how I modified thecode for my situation:

trigger_resetMeans_time = 300.0 # time to reset means

trigger_resetWaveHeight_time = 1800.0 # time to reset wave height

trigger_writeWaveHeight_time = 2000.0 # time to write wave height, this is also the end time for the simulation

does this mean it is doing the FSmean, HUmean and HVmean for times between 300 and 2000 secs? but doing the wave height stats (Hs and Hrms) between 1800 and 2000 secs?

do you have any suggestions for appropriate time windows over which these averages/stats should be calculated?

are the HUmean and HVmean files the average u and v currents speeds?

Thanks!

-jose

Patrick Lynett

Apr 10

Replying to

Hey Jose-

does this mean it is doing the FSmean, HUmean and HVmean for times between 300 and 2000 secs? but doing the wave height stats (Hs and Hrms) between 1800 and 2000 secs?

Yeah, that is what that set of values would do. When I run cases, I typically use: trigger_resetMeans_time = 600.0 # time to reset means

trigger_resetWaveHeight_time = 1200.0 # time to reset wave height

trigger_writeWaveHeight_time = 2100.0 # time to write wave height, this is also the end time for the simulation which means that I am giving the simulation 10 minutes to warm up, 10 minutes to get a good estimate of the mean water levels, and then 15 minutes to calc the Hs surface. Since we are finding the Hs (and Hrms) surface on the fly by updating the local variance (sum of eta^2), we should have a good estimate of the mean water level before we start calculating the eta^2 sum - 10 minutes is typically a good length of time. If you are expecting to have alot of IG, then you would increase the trigger_writeWaveHeight_time. With a long, large swell and a mild beach / reef, a trigger_writeWaveHeight_time that gives up to 60 minutes of Hs calc time (4800 using the other numbers from above), should be plenty. HUmean and HVmean are the time-averaged flux (not velocity) in the x- and y-directions. You can get the flux-averaged velocity by dividing HUmean by the time-averaged flow depth (input still water depth + FSmean).

Edited

JoseB

Apr 09

you 'da man!