Time-series for morphology forcing

[dangerbaby]

Yesterday, Rusty and I were talking about the generation of time-series from the array of results from StormSim. At present, the SS generates a project_forcing structure that includes a series of individual storms, but they are not distributed in time with periods of low energy conditions in the gaps between storms.

The morphology team wants to build a full time-series from this array of storms. Distributing the arrival times as a Poisson random process is trivial if we neglect seasonal variation in the expected arrival rate. To include the seasonal variation, I am inclined to use a time-changing rate comprised of a constant and a sinusoidal part, but I was wondering if the kids on the stochastic part of the house have thoughts. There is another issue for this plan where storms from SS are finite in length, and the Poisson arrival may result in times where 2 or more storm occur concurrently. I'll probably just work around that in an ad-hoc way.

Also, Melby ran CSHORE as the morpho part of a lifecycle exercise, but I don't think that he created a full timeseries that included low energy periods.

[rustypermenter]

The current models allow the user to select the seasonal variability for the storm events once they are assigned to a year. A uniform distribution is used to find a random number between zero and one. The values between zero and one are divided up into the user inputted seasons based on the specified relative probability. A given storm is assigned to a date based on where the random number falls in the bins created by the user.

[dangerbaby]

Thanks, Rusty. Are you aware of the method used to select seasonal variability. Is there some algorithm used in practice?

[jmelby]

Is it more complicated than historical seasonal frequency? We categorize frequency in our sampling of tropical storms by storm intensity. That is a small addition. Fortunately, we have HURDAT for that. We use 3 intensity bins for most areas now. For extratropicals, you typically have relatively few extreme events and a lot of non-extreme events in the historical record which makes it more difficult to do anything more than arm waving. What we have done to improve this is use many regional gages with SWL, wave height, and wind speed to do our POT so we end up with more events in our POT sample. Then computing POT threshold and Poisson frequencies is more objective or less subjective, depending on whether you are a glass half full or half empty sort of person.

[rustypermenter]

For Beach-fx, this specification really only matters when you get repetitive losses. The tide is baked into the CShore/SBeach modeling, and SLC is linearly superimposed.

[jmelby]

"... but they are not distributed in time with periods of low energy conditions in the gaps between storms." To be clear, they are distributed but only inter-annually, not intra-annually. We have low-energy storms but they are still cyclonic events and not local squalls of frontal systems. We have had intra-annual arrival times in our LC simulation in the past with a wider range of "events". My original LC simulation code, that was the template for G2CRM, had intra-annual storm arrival times of POT events. In the Midbay feasibility study in the early 2000's, I simulated continuous time series with 3hr sampling for 50 years. I filled the low-energy periods with a year of local measurements, if I am recalling correctly. So all low-energy periods for the 50-yr LC were from one year of measurements that including random tide phases. We had random storm arrival times but within an intra-annual monthly Poisson sampling. The time series generation for that employed a simulated annealing surrogate technique and was in Matlab. But the LC simulation code was in FORTRAN because it was computationally demanding and needed to be super efficient. It still took days to run a few life cycles. I would do that differently now with AI throughout rather than using AI for only generating time series. By 2010, we had scrapped the continuous time series (for efficiency) and gone to seasonal Poisson sampling with no low-energy periods. This was about the time I was working with Males on CSsym which was the start of G2CRM. Around that time, we implemented our POT approach from the Great Lakes FEMA study and synthetic hydrographs based on probabilistic hydrograph shape parameters. But in our present code, we have simplified all that to only inter-annual events and within the context of CHS (JPM tropical and POT sampled extra-tropical storms) to make implementation relatively simple because I got little traction within the community from with my previous approaches. My preference now is to prove that resolution or fidelity are required (change the planning answer) before implementing in our production code rather than deploying a complex workflow that nobody will use. TLDR - you are correct, Brad.

[dangerbaby]

Thanks, Jeff. Still trying to understand that message. One followup: in the SS lifecycle workflow, there are a series of storms compiled. So, about 50 storms for a 50 year LC in my case. These storms are provided within project_forcing.CC.Timeseries, but they are not--as near as I can tell--distributed into years. Do I understand that correctly?

[jmelby]

They each have a year from 1 to the number of simulated years. project_forcing.CC.Timeseries(n).LCNUM column 10 has simulation year. CC is combined storms, XC is extratropical and TC is tropical in these arrays.
Note that there are two LC array types: peaks and time series. The peaks files are generated from sampling a multi-variate probability copula of wave and water level parameters whereas the time series are just randomized storms.

[dangerbaby]

things always seem like they will be simple...........