Community Forums

Community Forums

HTDP in California ...
 
Share:
Notifications
Clear all

HTDP in California (read as: Earthquake Land)  

Page 1 / 2

Steinhoff
Posts: 37
Member
(@steinhoff)
20+ posts
Joined: 8 months ago

Here's a situation I haven't dealt with before:

We're working a GNSS project where a few of the local CORS were disturbed by the earthquakes in Ridgecrest (6.4 on 7-4-2019, and 7.1 on 7-6-2019 [sidebar: we got a pretty good shake from them 120+ miles away]). Thankfully SOPAC/CSRC has updated values for many of the affected stations.

My question is: am I still safe using HTDP's calculated velocities for these CORS? I understand that I have to be careful as to which controlling values I use before and after the seismic event, but other than that I should be okay... I think. Famous last words?

17 Replies
SPMPLS
Posts: 400
Member
(@spmpls)
250+ posts
Joined: 4 years ago

Which CORS do you plan to use? The time series plots I have viewed for the stations closest to the Ridgecrest events have mostly returned to their pre-event linear velocity rates. You should look at the time series plots for the stations you plan to use. If the pre and post velocity rates look consistent, you should be able to use the CSRC epoch 2019.55 positions and apply HTDP to move them to the date of your observations. Even better, why not use SECTOR to compute true-of-date positions for the CORS you plan to use for control?

http://sopac-old.ucsd.edu/sector.shtml

Reply
1 Reply
Steinhoff
Member
(@steinhoff)
Joined: 8 months ago

20+ posts
Posts: 37

@spmpls Great point- I was actually playing with SECTOR earlier today. For conversation's sake it appears that P056, P566, and P571 are potential project CORS that have been affected.

Out of curiosity, where are you finding the time series plots? One of my gripes with SOPAC (as opposed to NGS) was that I couldn't find their time series. Knowing me, I was probably just "man looking".

Reply
SPMPLS
Posts: 400
Member
(@spmpls)
250+ posts
Joined: 4 years ago

Those are all UNAVCO stations. The time series plots for their stations can be accessed here:

https://www.unavco.org/instrumentation/networks/status/nota/gps

An example for P566:

https://www.unavco.org/instrumentation/networks/status/nota/overview/P566

 The portal to time series data through SOPAC can be accessed here:

http://geodemo-c.ucsd.edu/gridsphere/gridsphere?cid=Time+Series+Plots

 

Reply
2 Replies
Steinhoff
Member
(@steinhoff)
Joined: 8 months ago

20+ posts
Posts: 37

@spmpls That will do it- really appreciate the help.

On a somewhat related note: have you noticed that attempting to download rinex from the SOPAC data browser yields zero results from 06-10-2020 to present? I've noticed via their ftp that the high rate rinex (which luckily has data for some of my project CORS) and GNSS products folders are being updated, but the "regular" rinex folders aren't being populated. I've reached out to Dr. Bock, but haven't heard back.

In hindsight it may have been excessive to reach out to the director, but c'est la vie.

Reply
SPMPLS
Member
(@spmpls)
Joined: 4 years ago

250+ posts
Posts: 400

@steinhoff

The only way Dr. Bock knows if something is not working correctly is when users let him know, so you did the right thing. I will follow up with him on the RINEX archiving issue.

Reply

xyHt Magazine -- Still absolutely free!

SPMPLS
Posts: 400
Member
(@spmpls)
250+ posts
Joined: 4 years ago

Just so others understand the magnitude, one of the closest Continuous GNSS stations to the epicenters for the Ridgecrest events, P595, moved approximately 25 cm south by 63 cm east (about 2.2 feet total) from where it was before the events. Time series can be viewed here:

https://www.unavco.org/instrumentation/networks/status/nota/overview/P595

Those events, and the shifts associated with them, and several other earthquakes, are not modeled in HTDP because it hasn't been updated to include these events for many years.

Reply
3 Replies
Steinhoff
Member
(@steinhoff)
Joined: 8 months ago

20+ posts
Posts: 37

@spmpls Is it me or does HTDP have an advantage over SECTOR when you account for HTDP being able to transform any given location, while SECTOR is limited to CORS?

Using HTDP you could transform your CORS to your average project epoch, run your control adjustments, and then return everything (along with your newly established points) back to the original (published) epoch. If you're using SECTOR, I don't believe you can do that. I could be wrong, though.

 

EDIT: This doesn't mean I won't use SECTOR, of course- I'll just have to be clear that SECTOR was used and make sure 2020.xxxx was the calculated epoch.

Reply
SPMPLS
Member
(@spmpls)
Joined: 4 years ago

250+ posts
Posts: 400

@steinhoff

Think about what you are proposing. You model your control positions to the average epoch date of your survey so they will theoretically fit your observed vectors/baselines better when you perform your least squares adjustment. You likely will get excellent results/positions (barring some other error source) on your survey epoch date. Now you are going to use HTDP to move everything, including your newly established control, back to a published epoch date? What just happened to your least squares adjustment results? If the area is similar to what I show in the slide below, you just ripped it apart.

Reply
Steinhoff
Member
(@steinhoff)
Joined: 8 months ago

20+ posts
Posts: 37

@spmpls I was thinking more along the lines of when clients require data within xyz epoch (1991.35, 2010, etc.), but your point blew a hole right in that one. You're watching me learn in real time- "d'oh moments" included.

Reply
SPMPLS
Posts: 400
Member
(@spmpls)
250+ posts
Joined: 4 years ago

You are correct that SECTOR only transforms positions over time for the CGPS stations SOPAC processes data from. HTDP will calculate a modeled velocity for any user defined location that falls within its grids. However, there are roughly 850 CGPS stations in California (included in the California Spatial Reference Network), of which only about 250 are NGS CORS.

SOPAC/CSRC has developed velocities for all of the stations and is working on a utility that will work much like HTDP (user defined locations) only be much more refined because more velocity models (nodes) will be used. It will also be capable of being updated in near real-time similar to how the 2019.55 epoch positions were established after the Ridgecrest seismic events. 

This utility will also include a robust geophysical model to improve velocity interpolation in complex faulting areas between where the CGPS stations exist.

It would be possible to use the velocities of the SECTOR CGPS stations surrounding a project area and use a weighted interpolation to compute velocities for passive marks within the project. However, unless the velocities of the CGPS stations vary significantly in direction and rate, there would be little value gained in doing this manual interpolation. There are a few areas in California, such as on either side of the San Andreas or Hayward faults, where the velocity rates/direction differ significantly over relatively short distances, but those are the exception. Here is an example. The velocities shown are from HTDP. I use this slide in courses I teach.

bay area slide

Stay tuned.

Reply
3 Replies
Steinhoff
Member
(@steinhoff)
Joined: 8 months ago

20+ posts
Posts: 37

@spmpls Am I looking at this right? 1 sigma value for height is 0.215477 meters..? That's uh.. a little different than the published 2017.50 2sigma values (2.22mm lat, 2.24mm long, 6.55mm height). Can these SECTOR sigmas be trusted for an adjustment?

SOPAC GLOBK ATS,flt
site,date,x,y,z (m),x_sig,y_sig,z_sig,wgsLat,wgsLon,wgsHt,lat_sig,lon_sig,ht_sig,nadLat,nadLon,nadHt
crcn,2020.4604,-2545533.866136,-4486776.248352,3738432.257536,0.086695,0.152425,0.127999,36 6 50.35003350,-119 34 4.92981047,26.48850293,0.009889,0.007467,0.216748,36 6 50.34114800,-119 34 4.87174800,27.10190000
Reply
SPMPLS
Member
(@spmpls)
Joined: 4 years ago

250+ posts
Posts: 400

@steinhoff

The 2 sigma values listed in the 2017.50 report are based on how well the model trace fit to the time series for several months before and after the epoch date. In many areas of California's valleys, the time series in the vertical can be quite erratic. Therefore, the confidence level of modeling a height at any given time can vary greatly. How well do you think a reasonable height for a specific date could be modeled from this time series? I think the horizontal values are much tighter than the vertical.

P565 TS (002)
Reply
Steinhoff
Member
(@steinhoff)
Joined: 8 months ago

20+ posts
Posts: 37

@spmpls Fair. I also noticed that when running SECTOR for CRCN I only ran filtered/SOPAC instead of filtered/combination as is recommended for west coast users. When running it that way, the sigmas calm down to 0.0052m, 0.0032m, and 0.1097m (lat, long, hgt).

At first those sigmas still seemed a little excessive but sure enough when I ran free & minimally constrained adjustments CRCN had nearly half a foot of play. When I constrained my little network with SECTOR-derived sigmas, everything clicked.

Interestingly enough, two of my CORS have the most extreme up velocities noted within the 2017.50 dataset (-290.46 mm/yr for CRCN, and -195.74 mm/yr for LEMA). Its actually amazing that I can get these CORS to click vertically with others like P056 (-40.65 mm/yr) and DLNO (-58.78 mm/yr). Then again since I have so much play in height due to the SECTOR-derived uncertainties, it makes sense that it clicks.

At this rate I think I just need to come up with a datum statement that outlines the fact that SECTOR was used, and state the modeled positions and uncertainties.

Reply
Page 1 / 2
Scroll to Top