Format Requirement for PaHM and ADCIRC for `BEST` and `OFCL`

[SorooshMani-NOAA]

See noaa-ocs-modeling/EnsemblePerturbation#99.

There seems to be different contradicting requirements for track inputs for ADCIRC vs PaHM. The ones currently identified are

• The importance of the advisory type (e.g BEST vs OFCL)
• The importance of date tags vs forecast hours for different advisory types
  • BEST track has increasing date tags from ATCF but 0 for all forecast hours
    • ADCIRC requires the forecast hours to be increasing (like a normal advisory)
    • PaHM just looks at the date tags, so no changes required to forecast hours
  • OFCL and other non-BEST tracks have fixed date tags for each issued advisory (i.e. track start time), but have increasing forecast hours
    • ADCIRC is fine with this format since it looks at the forecast hours
    • PaHM requires modified date tags based on the forecast hour, since it only cares about the time tag.

These changes potentially require a separate file extension for PaHM vs ADCIRC compliant input files (i.e. stormevents outputs) as discussed in noaa-ocs-modeling/EnsemblePerturbation#98 (comment)

[SorooshMani-NOAA]

@pvelissariou1 it seems there's a difference between how ADCIRC processes track files vs what PaHM does. @WPringle and I would like to first confirm this before separating the logic of handling both in stormevents and ensembleperturbation.

My understanding based on our prior discussions is that in PaHM, the advisory type (e.g. BEST vs OFCL vs CARQ, etc.) and forecast hour (e.g. 0, 6, 12, 18, ...) don't matter, and all that the model looks at is date tag column for figuring out time. And other than that PaHM cares about the isotach speed column and the rest of the physical variables, such as velocity , direction, pressures, radii.

Please also look at the issue description above and let me know if I'm missing anything.

[SorooshMani-NOAA]

@WPringle I just had a meeting with Takis and it seems I didn't have the full picture for PaHM. Later he will paste the link to locations in PaHM where the ATCF files are processed, as well as the ADCIRC code that does the same. Let's then review those and decide how to move forward with the stormevent handling of different cases.

[pvelissariou1]

@SorooshMani-NOAA The atcf files are preprocessed in PaHM in the https://github.com/noaa-ocs-modeling/PaHM/blob/main/src/parwind.F90 as follows: - Holland Model: In SUBROUTINE `ProcessHollandData`, lines: 1017 - 1068 - GAHM: In SUBROUTINE `ProcessAsymmetricVortexData`, lines: 1227-1324. Here there is no checking for BEST, OCFL fields as the loop goes through the sequence of times only. Both were designed having "best" track files in mind. Might need to explicitly consider the OCFL fields filtering out all hours except hour 0. In ADCIRC the atcf files are processed in a similar way and in file: https://github.com/adcirc/adcirc/blob/bd62a3c1b167cfb95db5af13325b031de2a1cdfb/src/wind.F a) Holland Model: In SUBROUTINE GetHollandStormData, lines: 5283-5385 b) GAHM: In SUBROUTINE NWS20GET, lines 6578-6662 (no testing on OCFL fields either). To use forecast files input data need to be filtered to consider only "hour 0" (possibly also hour 3). Furthermore, in the forecast atcf files the radius of the last closed isobar is not estimated (is set to 0) which makes both ADCIRC and PaHM produce zero wind fields.

[SorooshMani-NOAA]

@pvelissariou1 @WPringle
I'll try to summarize my concerns and understanding here, including #81 (i.e. explicit normalization):

• PaHM and ADCIRC have the same requirements in terms of input track file format and needed columns.
• In either ADCIRC or PaHM, the GAHM model does not check for OFCL vs BEST vs anything, it just reads the tracks and the track rows must be unique in time (3 isotachs per time)
  • In ADCIRC for GAHM the forecast hours must be increasing (?)
• In either ADCIRC or PaHM for the Symmetric Holland (SymH) model, the input data is processed differently for BEST vs OFCL:
  • For BEST the tracks are filtered and only the first entry for unique dates str is kept.
  • For OFCL only hour-0 or the first available entry for every date (track start date) is taken, the rest are filtered

stormevents must do the following normalizations in any case:

• Remove duplicate inputs (such as the ones for Ian best track file from NHC)
• Calculate missing values for forecast tracks:
  • Background pressure [currently done implicitly]
  • Eye pressure [currently done implicitly]
  • Radius of maximum winds [currently done implicitly]
  • Forecast hour must be increasing for BEST track [currently done implicitly]
  • Speed [currently done implicitly]
  • Direction [currently done implicitly]
  • Radius of the last closed isobar [missing]
  • Radius for quadrants for GAHM [missing]

In terms of our use cases, we have the following items, along with what it means for stormevents output:

1. Simulate BEST track for hindcast
   • The duplicate removal (normalization) stated in duplicate time issues from original dataset #81 should be added
   • The forecast dates need to be increasing for it to work with GAHM (at least in ADCIRC) -- it seems that's not true see Format Requirement for PaHM and ADCIRC for BEST and OFCL #84 (comment)
2. Simulate forecast track for incoming storms (NHC collaboration)
   • OFCL track data from a single advisory needs to be used.
   • The OFCL track needs to be modified to add missing fields
   • The OFCL date and forecast hour need to be modified to feed it to the model. This means:
     • For a single advisory, the first entry's date stays the same, the rest will need to increment by the forecast hour.
     • The forecast hours need to be increasing (remain as they are).
     • This should work for both SymH and GAHM, because SymH gets the first entry for each date if 0 does not exists for that date, and GAHM only cares about forecast time after making sure dates are unique
3. Simulate past-forecast track for probabilistic analysis method implementation and testing
   • Requirements are similar to item 2.

Please note that:

• Reading back the modified tracks into stromevents requires the user to tell stormevents that it's a modified track, either by file extension or by explicit argument.
• Ideally we do not want to have two different outputs from stormevents for GAHM vs SymH models

I'd like to also note that @WPringle has told me that the processing of OFCL in ADCIRC GAHM only cares about the forecast hours, and not the date tags, and I'm not sure if PaHM is the same; so please let me know if my understanding is incorrect.

Please let me know if any part of this is incorrect or anything is missing so that I update the comment! Also please let me know if any part of this is unclear. I want to make sure we're all on the same page before making any major changes!

[pvelissariou1]

For OFCL only hour-0 or the first available entry for every date (track start date) is taken, the rest are filtered
In both models OFCL filtering is not performed at this point

Radius of the last closed isobar [missing]
We should add the capability to estimate the radius; methods to do so exist but we need to understand how thay do it at NHC

Radius for quadrants for GAHM [missing]
The radii of quadrant wind intensities need to be estimated when their values are missing (again need to check with NHC on how they estimate these values)

The forecast dates need to be increasing for it to work with GAHM (at least in ADCIRC)
PaHM checks the timestamps and re-orders them in ascending order if needed

OFCL track data from a single advisory needs to be used.
The OFCL time intervals are not constant, using the OFCI field that contains the interpolated values for every 6 hours may be a more useful approach.

Link to format documentation: ATCF Formats

[SorooshMani-NOAA]

@pvelissariou1 thank you for the information. I just have some follow up questions/points:

In both models OFCL filtering is not performed at this point

Isn't this line doing the filtering in PaHM for SymH (not GAHM)?
Lines 1024-1026

          IF (iCnt > 1) THEN
            IF ( (strOut%fcstInc(iCnt) /= 0) .AND. (strOut%fcstInc(iCnt) == strOut%fcstInc(iCnt - 1))) CYCLE
          END IF

Also in response to

The OFCL time intervals are not constant, using the OFCI field ...

Right now for SymH only BEST and OFCL are accepted, right? So if we use OFCI we can only use it with GAHM, isn't it so?

And for

The forecast dates need to be increasing for it to work with GAHM (at least in ADCIRC)

I meant to say we cannot have all 0 forecast hours (even with different date tags) for BEST track in ADCIRC. Is it the same in PaHM? In other words the following doesn't work for ADCIRC GAHM I think:

AL, 09, 2022092600,   , BEST,   0, 168N,  809W,  50,  991, TS,  34, NEQ,   60,   60,    0,   30, 1007,  120,  30,  60,   0,   L,   0,    ,   0,   0,        IAN, D, 12, NEQ,   30,    0,    0,    0, genesis-num, 028, 
AL, 09, 2022092600,   , BEST,   0, 168N,  809W,  50,  991, TS,  50, NEQ,   30,    0,    0,    0, 1007,  120,  30,  60,   0,   L,   0,    ,   0,   0,        IAN, D, 12, NEQ,   30,    0,    0,    0, genesis-num, 028, 
AL, 09, 2022092606,   , BEST,   0, 177N,  817W,  65,  985, HU,  34, NEQ,   70,   70,   30,   70, 1007,  150,  15,  80,   0,   L,   0,    ,   0,   0,        IAN, D, 12, NEQ,   45,   30,   30,   30, genesis-num, 028, 
AL, 09, 2022092606,   , BEST,   0, 177N,  817W,  65,  985, HU,  50, NEQ,   30,   30,    0,   20, 1007,  150,  15,  80,   0,   L,   0,    ,   0,   0,        IAN, D, 12, NEQ,   45,   30,   30,   30, genesis-num, 028, 
AL, 09, 2022092606,   , BEST,   0, 177N,  817W,  65,  985, HU,  64, NEQ,   15,    0,    0,    0, 1007,  150,  15,  80,   0,   L,   0,    ,   0,   0,        IAN, D, 12, NEQ,   45,   30,   30,   30, genesis-num, 028, 
AL, 09, 2022092612,   , BEST,   0, 187N,  824W,  70,  981, HU,  34, NEQ,   90,   80,   40,   90, 1008,  150,  15,  85,   0,   L,   0,    ,   0,   0,        IAN, D, 12, NEQ,   60,   30,   30,   60, genesis-num, 028, 
AL, 09, 2022092612,   , BEST,   0, 187N,  824W,  70,  981, HU,  50, NEQ,   40,   40,    0,   30, 1008,  150,  15,  85,   0,   L,   0,    ,   0,   0,        IAN, D, 12, NEQ,   60,   30,   30,   60, genesis-num, 028, 
AL, 09, 2022092612,   , BEST,   0, 187N,  824W,  70,  981, HU,  64, NEQ,   20,    0,    0,    0, 1008,  150,  15,  85,   0,   L,   0,    ,   0,   0,        IAN, D, 12, NEQ,   60,   30,   30,   60, genesis-num, 028, 
AL, 09, 2022092618,   , BEST,   0, 197N,  830W,  80,  976, HU,  34, NEQ,  100,   90,   60,   90, 1008,  150,  20, 100,   0,   L,   0,    ,   0,   0,        IAN, D, 12, NEQ,  120,   60,   30,   75, genesis-num, 028, 
AL, 09, 2022092618,   , BEST,   0, 197N,  830W,  80,  976, HU,  50, NEQ,   50,   50,   20,   30, 1008,  150,  20, 100,   0,   L,   0,    ,   0,   0,        IAN, D, 12, NEQ,  120,   60,   30,   75, genesis-num, 028, 
AL, 09, 2022092618,   , BEST,   0, 197N,  830W,  80,  976, HU,  64, NEQ,   30,   25,    0,   20, 1008,  150,  20, 100,   0,   L,   0,    ,   0,   0,        IAN, D, 12, NEQ,  120,   60,   30,   75, genesis-num, 028, 
AL, 09, 2022092700,   , BEST,   0, 208N,  833W,  85,  965, HU,  34, NEQ,  100,   90,   60,   90, 1006,  130,  20, 105,   0,   L,   0,    ,   0,   0,        IAN, D, 12, NEQ,  150,  120,   60,   90, genesis-num, 028, 

instead it should be like:

AL, 09, 2022092600,   , BEST,   0, 168N,  809W,  50,  991, TS,  34, NEQ,   60,   60,    0,   30, 1007,  120,  30,  60,   0,   L,   0,    ,   0,   0,        IAN, D, 12, NEQ,   30,    0,    0,    0, genesis-num, 028, 
AL, 09, 2022092600,   , BEST,   0, 168N,  809W,  50,  991, TS,  50, NEQ,   30,    0,    0,    0, 1007,  120,  30,  60,   0,   L,   0,    ,   0,   0,        IAN, D, 12, NEQ,   30,    0,    0,    0, genesis-num, 028, 
AL, 09, 2022092606,   , BEST,   6, 177N,  817W,  65,  985, HU,  34, NEQ,   70,   70,   30,   70, 1007,  150,  15,  80,   0,   L,   0,    ,   0,   0,        IAN, D, 12, NEQ,   45,   30,   30,   30, genesis-num, 028, 
AL, 09, 2022092606,   , BEST,   6, 177N,  817W,  65,  985, HU,  50, NEQ,   30,   30,    0,   20, 1007,  150,  15,  80,   0,   L,   0,    ,   0,   0,        IAN, D, 12, NEQ,   45,   30,   30,   30, genesis-num, 028, 
AL, 09, 2022092606,   , BEST,   6, 177N,  817W,  65,  985, HU,  64, NEQ,   15,    0,    0,    0, 1007,  150,  15,  80,   0,   L,   0,    ,   0,   0,        IAN, D, 12, NEQ,   45,   30,   30,   30, genesis-num, 028, 
AL, 09, 2022092612,   , BEST,   12, 187N,  824W,  70,  981, HU,  34, NEQ,   90,   80,   40,   90, 1008,  150,  15,  85,   0,   L,   0,    ,   0,   0,        IAN, D, 12, NEQ,   60,   30,   30,   60, genesis-num, 028, 
AL, 09, 2022092612,   , BEST,   12, 187N,  824W,  70,  981, HU,  50, NEQ,   40,   40,    0,   30, 1008,  150,  15,  85,   0,   L,   0,    ,   0,   0,        IAN, D, 12, NEQ,   60,   30,   30,   60, genesis-num, 028, 
AL, 09, 2022092612,   , BEST,   12, 187N,  824W,  70,  981, HU,  64, NEQ,   20,    0,    0,    0, 1008,  150,  15,  85,   0,   L,   0,    ,   0,   0,       
...

[pvelissariou1]

@Soroosh Mani - NOAA Affiliate ***@***.***> Isn't this line doing the filtering in PaHM for SymH (not GAHM)?

Lines 1024-1026 IF (iCnt > 1) THEN IF ( (strOut%fcstInc(iCnt) /= 0) .AND. (strOut%fcstInc(iCnt) == strOut%fcstInc(iCnt - 1))) CYCLE END IF

It does it partially, it does not filter out the remaining OCFL fields though. I need to modify PaHM and ADCIRC to allow for the filtering of these fields. Also in response to

The OFCL time intervals are not constant, using the OFCI field ... Right now for SymH only BEST and OFCL are accepted, right? So if we use OFCI we can only use it with GAHM, isn't it so?

Correct. You may want to rename the OCFI fields to OFCL from within StormEvents. I will modify PaHM and possibly ADCIRC to accept these fields as well. Just have in mind that the OCFL fields are irregularly spaced in time (not every six hours). In PaHM I do a temporal interpolation to bring the data to the time intervals requested by the user. In ADCIRC these fields are temporarily interpolated (linearly) at the end at each model's time step. It will be a good idea to know how NHC does this interpolation. And for

The forecast dates need to be increasing for it to work with GAHM (at least in ADCIRC) I meant to say we cannot have all 0 forecast hours (even with different date tags) for BEST track in ADCIRC. Is it the same in PaHM? In other words the following doesn't work for ADCIRC GAHM I think:

For BEST fields the 6th column should always have 0 values (the timestamp 2022092600 is exactly the time for the data to be used). So the second block: instead it should be like:

AL, 09, 2022092600, , BEST, 0, 168N, 809W, 50, 991, TS, 34, NEQ, 60, 60, 0, 30, 1007, 120, 30, 60, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 30, 0, 0, 0, genesis-num, 028, AL, 09, 2022092600, , BEST, 0, 168N, 809W, 50, 991, TS, 50, NEQ, 30, 0, 0, 0, 1007, 120, 30, 60, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 30, 0, 0, 0, genesis-num, 028, AL, 09, 2022092606, , BEST, 6, 177N, 817W, 65, 985, HU, 34, NEQ, 70, 70, 30, 70, 1007, 150, 15, 80, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 45, 30, 30, 30, genesis-num, 028, AL, 09, 2022092606, , BEST, 6, 177N, 817W, 65, 985, HU, 50, NEQ, 30, 30, 0, 20, 1007, 150, 15, 80, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 45, 30, 30, 30, genesis-num, 028, AL, 09, 2022092606, , BEST, 6, 177N, 817W, 65, 985, HU, 64, NEQ, 15, 0, 0, 0, 1007, 150, 15, 80, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 45, 30, 30, 30, genesis-num, 028, AL, 09, 2022092612, , BEST, 12, 187N, 824W, 70, 981, HU, 34, NEQ, 90, 80, 40, 90, 1008, 150, 15, 85, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 60, 30, 30, 60, genesis-num, 028, AL, 09, 2022092612, , BEST, 12, 187N, 824W, 70, 981, HU, 50, NEQ, 40, 40, 0, 30, 1008, 150, 15, 85, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 60, 30, 30, 60, genesis-num, 028, AL, 09, 2022092612, , BEST, 12, 187N, 824W, 70, 981, HU, 64, NEQ, 20, 0, 0, 0, 1008, 150, 15, 85, 0, L, 0, , 0, 0,

won't work either in ADCIRC or PaHM. Panagiotis Velissariou, Ph.D., P.E. UCAR Scientist National Ocean and Atmospheric Administration National Ocean Service Office of Coast Survey CSDL/CMMB Physical Scientist - Project Lead cell: (205) 227-9141 email: ***@***.***

…

On Tue, Jun 27, 2023 at 1:16 PM Soroosh Mani ***@***.***> wrote: @pvelissariou1 <https://github.com/pvelissariou1> thank you for the information. I just have some follow up questions/points: In both models OFCL filtering is not performed at this point Isn't this line doing the filtering in PaHM for SymH (not GAHM)? Lines 1024-1026 IF (iCnt > 1) THEN IF ( (strOut%fcstInc(iCnt) /= 0) .AND. (strOut%fcstInc(iCnt) == strOut%fcstInc(iCnt - 1))) CYCLE END IF Also in response to The OFCL time intervals are not constant, using the OFCI field ... Right now for SymH only BEST and OFCL are accepted, right? So if we use OFCI we can only use it with GAHM, isn't it so? And for The forecast dates need to be increasing for it to work with GAHM (at least in ADCIRC) I meant to say we cannot have all 0 forecast hours (even with different date tags) for BEST track in ADCIRC. Is it the same in PaHM? In other words the following doesn't work for ADCIRC GAHM I think: AL, 09, 2022092600, , BEST, 0, 168N, 809W, 50, 991, TS, 34, NEQ, 60, 60, 0, 30, 1007, 120, 30, 60, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 30, 0, 0, 0, genesis-num, 028, AL, 09, 2022092600, , BEST, 0, 168N, 809W, 50, 991, TS, 50, NEQ, 30, 0, 0, 0, 1007, 120, 30, 60, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 30, 0, 0, 0, genesis-num, 028, AL, 09, 2022092606, , BEST, 0, 177N, 817W, 65, 985, HU, 34, NEQ, 70, 70, 30, 70, 1007, 150, 15, 80, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 45, 30, 30, 30, genesis-num, 028, AL, 09, 2022092606, , BEST, 0, 177N, 817W, 65, 985, HU, 50, NEQ, 30, 30, 0, 20, 1007, 150, 15, 80, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 45, 30, 30, 30, genesis-num, 028, AL, 09, 2022092606, , BEST, 0, 177N, 817W, 65, 985, HU, 64, NEQ, 15, 0, 0, 0, 1007, 150, 15, 80, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 45, 30, 30, 30, genesis-num, 028, AL, 09, 2022092612, , BEST, 0, 187N, 824W, 70, 981, HU, 34, NEQ, 90, 80, 40, 90, 1008, 150, 15, 85, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 60, 30, 30, 60, genesis-num, 028, AL, 09, 2022092612, , BEST, 0, 187N, 824W, 70, 981, HU, 50, NEQ, 40, 40, 0, 30, 1008, 150, 15, 85, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 60, 30, 30, 60, genesis-num, 028, AL, 09, 2022092612, , BEST, 0, 187N, 824W, 70, 981, HU, 64, NEQ, 20, 0, 0, 0, 1008, 150, 15, 85, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 60, 30, 30, 60, genesis-num, 028, AL, 09, 2022092618, , BEST, 0, 197N, 830W, 80, 976, HU, 34, NEQ, 100, 90, 60, 90, 1008, 150, 20, 100, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 120, 60, 30, 75, genesis-num, 028, AL, 09, 2022092618, , BEST, 0, 197N, 830W, 80, 976, HU, 50, NEQ, 50, 50, 20, 30, 1008, 150, 20, 100, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 120, 60, 30, 75, genesis-num, 028, AL, 09, 2022092618, , BEST, 0, 197N, 830W, 80, 976, HU, 64, NEQ, 30, 25, 0, 20, 1008, 150, 20, 100, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 120, 60, 30, 75, genesis-num, 028, AL, 09, 2022092700, , BEST, 0, 208N, 833W, 85, 965, HU, 34, NEQ, 100, 90, 60, 90, 1006, 130, 20, 105, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 150, 120, 60, 90, genesis-num, 028, instead it should be like: AL, 09, 2022092600, , BEST, 0, 168N, 809W, 50, 991, TS, 34, NEQ, 60, 60, 0, 30, 1007, 120, 30, 60, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 30, 0, 0, 0, genesis-num, 028, AL, 09, 2022092600, , BEST, 0, 168N, 809W, 50, 991, TS, 50, NEQ, 30, 0, 0, 0, 1007, 120, 30, 60, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 30, 0, 0, 0, genesis-num, 028, AL, 09, 2022092606, , BEST, 6, 177N, 817W, 65, 985, HU, 34, NEQ, 70, 70, 30, 70, 1007, 150, 15, 80, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 45, 30, 30, 30, genesis-num, 028, AL, 09, 2022092606, , BEST, 6, 177N, 817W, 65, 985, HU, 50, NEQ, 30, 30, 0, 20, 1007, 150, 15, 80, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 45, 30, 30, 30, genesis-num, 028, AL, 09, 2022092606, , BEST, 6, 177N, 817W, 65, 985, HU, 64, NEQ, 15, 0, 0, 0, 1007, 150, 15, 80, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 45, 30, 30, 30, genesis-num, 028, AL, 09, 2022092612, , BEST, 12, 187N, 824W, 70, 981, HU, 34, NEQ, 90, 80, 40, 90, 1008, 150, 15, 85, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 60, 30, 30, 60, genesis-num, 028, AL, 09, 2022092612, , BEST, 12, 187N, 824W, 70, 981, HU, 50, NEQ, 40, 40, 0, 30, 1008, 150, 15, 85, 0, L, 0, , 0, 0, IAN, D, 12, NEQ, 60, 30, 30, 60, genesis-num, 028, AL, 09, 2022092612, , BEST, 12, 187N, 824W, 70, 981, HU, 64, NEQ, 20, 0, 0, 0, 1008, 150, 15, 85, 0, L, 0, , 0, 0, ... — Reply to this email directly, view it on GitHub <#84 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APC7TP3ZGPHFFFVYFLS4SKTXNMPP3ANCNFSM6AAAAAAZUFQY2I> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[SorooshMani-NOAA]

@WPringle please see above. It seems that we don't need the forecast hours for GAHM on BEST track.

[WPringle]

@SorooshMani-NOAA
For everything except ADCIRC GAHM (original NHC format):

• Actual time should be validation time + forecast time (and OFCL vs BEST is not important, but BEST forecast time is always 0).

For ADCIRC GAHM:

• Even for BEST update forecast time based on the validation time difference from the first row because that module does not read datetimes and assumes start of simulation is at the "0" forecast time.

[SorooshMani-NOAA]

@WPringle, @pvelissariou1 as we discussed in the meeting, we'd like to focus on theses three columns datetime tag, track type, and forecast hour, i.e. 3rd, 5th and 6th (e.g. 20180901, OFCL, 24) from the NHC track file (ATCF). The main concern here is what the expected track input is for PaHM and ADCIRC for either of the GAHM or Holland models. There are also missing forecast fields that we'll address later.

Note that we're not talking about column spacing or value types or orders, we already assume it's the same for all cases. The question is about the values within each column in relation to other columns.

So far, this is my understanding of where things stand based on all that was discussed:

• ADCIRC and PaHM can work with the same input track files
• In either ADCIRC or PaHM OFCL vs BEST track types do not matter
• Both ADCIRC and PaHM's symmetric Holland implementation requires datetime tags to be increasing (for every given isotach)
• Both ADCIRC and PaHM's GAHM implementation requires forecast hours to be increasing (for every given isotach)

This means that the output expected from storm events should be different from original NHC file, which means (with focus on the 3 aforementioned columns):

• stormevents output file should always have increasing datetag (to work with symmetric)
• stormevents output file should always have increasing forecast hour (to work with GAHM)
• stormevents output file should contain 1 track, at least this should be an option
• stormevents output file has equal time intervals between track entries (interpolation) -- is this optional or necessary for PaHM to work @pvelissariou1?
• The same stormevents output file should work for ADCIRC and PaHM, for either GAHM or symmetric
• When stormevents reads track files, there should be a way to distinguish original vs modified track (e.g. by extension)
• Based on all above, it shouldn't matter what the track type is, so it could be either OFCL or BEST without any change to any of the other columns (among the 3) as long as all other items above are true

These output requirements mean:

• If input is BEST track, the output file is different in that its forecast hours are not 0 in the output
• If input is OFCL track, the output file is different because the datetime tags are increasing as opposed to constant in original single track

@WPringle @pvelissariou1, please confirm that these statements are valid, then I'll go ahead and make the changes.

[WPringle]

@SorooshMani-NOAA No, for OFCL we do not require the datetime tags to be increasing. They can stay as is. Only change is for best-track GAHM for ADCIRC where forecast hours needs to be present.