Suggestion for rechdf5 output: add actual recorded location and distance to target

[jf-huang]

When SW4 outputs the receiver time histories in the USGS ASCII file format, the actual location of the receiver and the distance to the target are recorded, an example is shown below:

Station: D_01_01
Target location (WGS84 longitude, latitude) (deg): -1.223651e+02 3.769469e+01
Actual location (WGS84 longitude, latitude) (deg): -1.223652e+02 3.769462e+01
Distance from target to actual location (m): 1.131371e+01

However, in the rechdf5 file, only the target location is available which may be far away from the actual location depending on the grid size. Would be great if the two pieces of information can be added back as two additional datasets or as attributes of the station. Actual X/Y/Z coordinates or longitude/latitude/depth can be stored based on the isnsew option.

[houjun]

@jf-huang Can you check the tang/sachdf5new branch and run your test case?
Each station group will have new "ACTUALSTLA,STLO,STDP" and "DISTFROMACTUAL" datasets, which correspond to the USGS actual location and distance. The original "STLA,STLO,STDP" remains the target location.

[jf-huang]

@houjun Thanks for the quick response! I have run a test case and the new branch gives the same info as the USGS format.

Besides, I was wondering if it's advisable to store the actual X/Y/Z coordinates as well when isnsew is set to 0 (false) in view that the X/Y/Z coordinates are explicitly requested by the user?

[houjun]

Currently “STX,STY,STZ” should store the SW4 X/Y/Z values regardless of ISNSEW

On Wed, Aug 24, 2022 at 22:18 jfhuang ***@***.***> wrote: @houjun <https://github.com/houjun> Thanks for the quick response! I have run a test case and the new branch gives the same info as the USGS format. Besides, I was wondering if it's advisable to store the actual X/Y/Z coordinates as well when isnsew is set to 0 (false) in view that the X/Y/Z coordinates are explicitly requested by the user? — Reply to this email directly, view it on GitHub <#132 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYWMWXHAFXGAI3L5UG333LV236ZHANCNFSM56KBY5XQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Thanks, Tang

[jf-huang]

Sorry I wasn't clear, I meant the actual X/Y/Z (i.e., mGPX/mGPY/mGPZ in TimeSeries.C). I am asking because the geographic coordinates are not easy to interpret sometimes and actual X/Y/Z may be easier in hypothetical runs.

[houjun]

@jf-huang I just pushed an update to add "ACTUALSTX,STY,STZ" to each station group, can you try it out?

[jf-huang]

@houjun It works, thanks!

[houjun]

Updated code merged to developer

[jf-huang]

Sorry I wasn't clear, I meant the actual X/Y/Z (i.e., mGPX/mGPY/mGPZ in TimeSeries.C). I am asking because the geographic coordinates are not easy to interpret sometimes and actual X/Y/Z may be easier in hypothetical runs.

…

On 8/25/2022 8:47 AM, Houjun Tang wrote: Currently “STX,STY,STZ” should store the SW4 X/Y/Z values regardless of ISNSEW On Wed, Aug 24, 2022 at 22:18 jfhuang ***@***.***> wrote: > @houjun <https://github.com/houjun> Thanks for the quick response! I have > run a test case and the new branch gives the same info as the USGS format. > > Besides, I was wondering if it's advisable to store the actual X/Y/Z > coordinates as well when isnsew is set to 0 (false) in view that the X/Y/Z > coordinates are explicitly requested by the user? > > — > Reply to this email directly, view it on GitHub > <#132 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAYWMWXHAFXGAI3L5UG333LV236ZHANCNFSM56KBY5XQ> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > -- Thanks, Tang — Reply to this email directly, view it on GitHub <#132 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKQBLZFSZ622V7ZNVPJP33DV26IRBANCNFSM56KBY5XQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>