stormsurgelive / stormreplay.com Goto Github PK

Data is not added directly to StormReplay.com, but to the "storm-archive" repository. However, once the requisite files are added to this archive, there must be some testing to ensure it works properly - otherwise, adjustments to the site's workings or available tooling must be made.

really for development convenience, lower priority

For future test runs, a storm that affected more than one mesh like Laura 2020 or Zeta 2020 could be a great exercise.

3 different things in this issue, all somewhat related

Part 1:

• user DB init script
• add user script that uses a library defining members
• web app to use SQLite DB instead of YAML
• API to use SQLite DB instread of YAML

Part 2:

• CLI account create tool that emails credentials to provided email address (used for "invite" mode)
• #21

Part 3:

• #22

Gustav appears to work even when dorian is running. Need to figure out why, likely an issue with replayd.

hindcast only consists of:

• don't nowify
• select final advisory as start and ending
• provide support for the calculation of the following:

HINDCASTENDDATE=2004091100
HINDCASTLENGTH=30.0
COLDSTARTDATE=2004081200

Notes:

• the COLDSTARTDATE is HINDCASTENDDATE - 30 days
• you first calculate the base time which is essentially the landfall date + the landfall time rounded (no minutes)
• the theoretical run start is the same as the base time but always ends with 00
• if you find find this theoretical run start in the advisory list in noaa website you take that as an ASGS RunStartTime which is the same as **HINDCASTENDDATE**
• if you don't find it in the list you take the first available date and time minus 3 hours
• landfall date is determined by what was documented at the Time ([Stratos] has detailed links of all the documents that say when landfall was observed)

Looking at the results for the nowified Gustav (al072008), the COLDSTARTDATE value came out at hour 20Z rather than 18Z or 00Z the following day.

#-- gustav configurations generated by StormReplay.com WebUI --#
BACKGROUNDMET=off
TROPICALCYCLONE=on
  STORM=07
  YEAR=2023
  STARTADV=1
  ENDADV=35
TRIGGER=rssembedded # required mode
  FTPSITE=stormreplay.com
  HDIR=/atcf/btk/82AaeD2EOWvgjZ6fKYaXXHuSxwyh1Q04
  RSSSITE=stormreplay.com:443/rss/82AaeD2EOWvgjZ6fKYaXXHuSxwyh1Q04
COLDSTARTDATE=2023040920
HINDCASTLENGTH=30.0
WAVES=off
CYCLETIMELIMIT="99:00:00"
#-- gustav configurations generated by StormReplay.com WebUI --#

Will be used by StormSurgeLive/asgs#963

Currently, the storm sticks around in an ENDED state (last adv issued) when the last adv is reached; this just says "delete" when in ENDED state (persistent should remain, so it can be "restarted" if that is desired).

This will allow us to adjust the nowification interval to match, e.g., NHC's regular intervals but also provide a sped up storm replay for smaller meshes that don't take very long to turn around.

maybe combine in dropdown specifying a reload time interval?

During active storms, the RunStartTime in ASGS is usually 3 hours earlier than the advisory time.
This would be 00, 06,12,18. While this is not set in stone, 99% of our runs work that way. For the CERA app, the RunStartTime is currently tested to be earlier than the advisory time.

advisories seems to be getting updated in order, gets confused on the first advisory issue after the start; the below screenshot was taken when the posted advisory was number 17

For some of the users of this tool like CERA, it might be helpful to associate the advisory times to the official NHC times 03, 09,15, 21Z.