Notifications
Clear all

OPUS S

25 Posts
8 Users
0 Reactions
6 Views
(@john1minor2)
Posts: 699
Registered
Topic starter
 

I am trying to use OPUS S to process 4 points across a dam. I tell OPUS to use DDSN, CABL and P367 because those are the stations I have used in the past on this project. The problem is that OPUS substitutes LFLO for DDSN this time. I have checked and the data for the time period, April 21, is available and I can download it and process with it but OPUS refuses to use it. Only reason I can think of as the problem is that perhaps the data for that day at DDSN is bad but I can manually process it just fine with good results.

Any other thoughts on possible problems why OPUS refuses to use DDSN for April 21?
I even told it to exclude LFLO in hopes it would force the use of DDSN. It proceeded to use DDSN, CABL and substituted DCSO for P367 instead. I've used CABL, DDSN and P367 as a control group several times in the past and OPUS processed the data just fine.

 
Posted : May 23, 2011 10:32 am
(@moe-shetty)
Posts: 1426
Registered
 

the data feed for ddsn looks good. sometimes you just have to walk away from opus. try again tonight or tomorrow. opus hits some unexplainable hiccups at times

 
Posted : May 23, 2011 10:50 am
(@john1minor2)
Posts: 699
Registered
Topic starter
 

Thanks Moe.
I agree but I submitted the data to OPUS back on May 6 with the same problem occuring.

 
Posted : May 23, 2011 10:58 am
(@loyal)
Posts: 3735
Registered
 

That does sound a little strange John. Have you tried it today?

Here's a solution for LPSB in Eugene on April 21, that I just submitted:

NGS OPUS SOLUTION REPORT
========================

All computed coordinate accuracies are listed as peak-to-peak values.
For additional information: http://www.ngs.noaa.gov/OPUS/about.html#accuracy

USER: ldogeo@aol.com DATE: May 23, 2011
RINEX FILE: lpsb111i.11o TIME: 20:24:28 UTC

SOFTWARE: page5 1009.28 master11.pl 051811 START: 2011/04/21 08:00:00
EPHEMERIS: igs16324.eph [precise] STOP: 2011/04/21 15:59:30
NAV FILE: brdc1110.11n OBS USED: 19460 / 19842 : 98%
ANT NAME: NOV503+CR NONE # FIXED AMB: 76 / 80 : 95%
ARP HEIGHT: 2.020 OVERALL RMS: 0.011(m)

REF FRAME: NAD_83(CORS96)(EPOCH:2002.0000) ITRF00 (EPOCH:2011.3028)

X: -2506817.318(m) 0.041(m) -2506818.086(m) 0.041(m)
Y: -3846907.299(m) 0.004(m) -3846906.068(m) 0.004(m)
Z: 4412264.751(m) 0.024(m) 4412264.806(m) 0.024(m)

LAT: 44 3 4.40674 0.009(m) 44 3 4.42181 0.009(m)
E LON: 236 54 35.75056 0.034(m) 236 54 35.69146 0.034(m)
W LON: 123 5 24.24944 0.034(m) 123 5 24.30854 0.034(m)
EL HGT: 116.031(m) 0.032(m) 115.629(m) 0.032(m)
ORTHO HGT: 139.332(m) 0.057(m) [NAVD88 (Computed using GEOID09)]

UTM COORDINATES STATE PLANE COORDINATES
UTM (Zone 10) SPC (3602 OR S)
Northing (Y) [meters] 4877566.156 268104.779
Easting (X) [meters] 492784.990 1292469.516
Convergence [degrees] -0.06262531 -1.77198907
Point Scale 0.99960064 1.00001342
Combined Factor 0.99958245 0.99999523

US NATIONAL GRID DESIGNATOR: 10TDP9278477566(NAD 83)

BASE STATIONS USED
PID DESIGNATION LATITUDE LONGITUDE DISTANCE(m)
AF9662 CABL CAPE BLANCO CORS ARP N425009.939 W1243347.989 180126.8
DI7529 P367 NEWPRTAIR_OR2007 CORS ARP N443506.870 W1240341.598 97608.5
AJ7211 DDSN DODSON BUTTE CORS ARP N430707.631 W1231439.213 104354.0

 
Posted : May 23, 2011 12:32 pm
(@john1minor2)
Posts: 699
Registered
Topic starter
 

Yes. I resubmitted following your post but I still get the same problem. Could I email you my 4 data files for you to submit to OPUS to see if there is something goofy with my computer?

 
Posted : May 23, 2011 12:49 pm
(@loyal)
Posts: 3735
Registered
 

Sure John, got the files and I'll play with them as soon as I sober up a little!

🙂
Loyal

 
Posted : May 23, 2011 5:30 pm
(@dave-karoly)
Posts: 12001
 

uh

S stands for Static, not Sober.

 
Posted : May 23, 2011 5:52 pm
(@loyal)
Posts: 3735
Registered
 

Dave

That "depends" on you spent your particular Monday afternoon!

🙂
Loyalsky

 
Posted : May 23, 2011 5:55 pm
(@keith)
Posts: 2051
Registered
 

Dave

Musta been a good time!

 
Posted : May 23, 2011 8:18 pm
(@loyal)
Posts: 3735
Registered
 

John

Got'er done, OPUS Solutions forwarded to you this am.

Keith, well not THAT good a time, but I wanted to be CLEAR headed in case the files required some manipulation (they didn't). I did convert them to RINEX and reviewed each one before submission to OPUS though.

Loyal

 
Posted : May 24, 2011 5:29 am
(@john-hamilton)
Posts: 3347
Registered
 

John

Did you only have one receiver? I do GPS on points across dams all the time for monitoring, but we network them all together to get the best local results. I do send the data from the off dam control point to OPUS to make sure that it hasn't moved, but I prefer to process the lines between monitoring points myself. I use either 4 or 5 receivers-one or two on reference points, the other two or three to leapfrog across the dam. It creates a nice tight network.

 
Posted : May 24, 2011 5:51 am
(@loyal)
Posts: 3735
Registered
 

John

Good point John...and the same thing that I thought.

There were four receivers involved pretty much running simultaneously, so the data is really all there. If it was me, I might use OPUS (vectors in the G-Files) to connect to the NSRS, then combine those vectors with the inter-station vectors (solved using Waypoint or SoftSurv...whatever) in a fully constrained Network Adjustment, holding the CORS as partial fixities. I have done that on several multi-receiver projects recently with excellent results.

Loyal

 
Posted : May 24, 2011 5:59 am
(@dave-karoly)
Posts: 12001
 

John

Are you a Dam Surveyor?

OH HAR HAR HAR HA HA HA HAR HAR HAR!

 
Posted : May 24, 2011 6:00 am
(@john-hamilton)
Posts: 3347
Registered
 

John

I've been called that...and much worse!

Actually, doing some dam(ned) surveying today. We did a dewatering surveying of a navigation lock two weeks ago. Then it flooded. Now they are dewatering again today, started at noon. Probabaly be 18-24 hours for the pump down. Hopefully less, I am suffering from a bit of jet lag.

 
Posted : May 24, 2011 10:13 am
(@john1minor2)
Posts: 699
Registered
Topic starter
 

John

A big thank you to you Loyal!
I just home from Portland this evening and got my present from you. I apparently still have some bad voodoo going on between me and OPUS though. I tried RINEXING all 4 files tonight and sending them in but in every case OPUS substituted LFLO for DDSN. I also tried sending the data files from my daughter's computer in Eugene and had the results sent to her email address and OPUS still substituted LFLO for DDSN for 2 of the files. I'm sure glad you were able to get it to work correctly. Just out of curiosity, did they all work the first time you sent them or did you have to resubmit to get the correct stations?

Thanks again for your help.

 
Posted : May 24, 2011 5:58 pm
(@john1minor2)
Posts: 699
Registered
Topic starter
 

John

John
Yes, I had 4 receivers running simultaneously. I'm a little embarassed that I didn't think of using your suggested approach to the project several years ago when I started measuring the dam. I agree it would have been a better method.

The client has asked me to set some new control monuments within sight of the dam so optical measurements can be used to monitor in the future. I have done that and using an S6 have turned multiple angles and distances to get good control values on the new monuments. I also ran digital levels. Scott Partridge is going to give me a hand doing a GPS/terestrial adjustment in TGO. I guess this has turned into a "beer leg" community project of sorts. I haven't done an adjustment involving both GPS and terrestrial observations. I thought about trying to incorporate the "G" files from OPUS but there doesn't appear to be a way to do that in TGO that I can figure out.

Thanks for your thoughts. I certainly can use the advice.

 
Posted : May 24, 2011 6:11 pm
(@loyal)
Posts: 3735
Registered
 

John

They went through (and came back) as you see them FIRST time around.

Beats me why it would vary by "submitter."

I saved the OPUS solutions, so if you want me to, I will convert the G-File data to simple dX,dY,dZ vectors and 3x3 covariance mtarix if you like.

Loyal

 
Posted : May 24, 2011 6:18 pm
(@john1minor2)
Posts: 699
Registered
Topic starter
 

John

Loyal
I appreciate the offer but I don't know how to get the data into the TGO adjustment software. I'll be sending some data to Scott Partridge tomorrow and I'll ask him if he is aware of how to get the "G" file stuff from OPUS or your "massaged G file" into TGO.
I appreciate your's and eveybody's help.

 
Posted : May 24, 2011 6:29 pm
(@john-hamilton)
Posts: 3347
Registered
 

John

There are 39 dams in the Pittsburgh District that I do deformation surveys on, some yearly, some every other year. So, I will spell out very briefly how I do it...

For settlement, we use a digital level. Everything is run in a loop, and adjusted.

For alignment (i.e. horizontal movement):
On concrete dams, we only use a total station (Trimble S6 high accuracy). We shoot every point from at least two different standpoints. The flood control dams have pedestals on either end and a set of alignment pins, one in each monolith, nominally on line in between. There are other pedestals located further away for verification of stability of the two on the dam axis. Here is one of the concrete flood control dams, pedestals in red, alignment pins in yellow:

I download the data collector files, read them into a database, and then apply corrections for temperature, pressure, HI/HT, and wind up with angles, mark-to-mark distances and mark-to-mark zenith distances. I use mark-to-mark values because there is only a single value for these, and they do not depend on elevation. They are similar to GPS vectors in that aspect. I adjust these in Geolab. Some projects have the reference points adjusted separately to verify stability. The network is designed and observed to obtain 3 mm accuracy on all of the points.

The results of these surveys are presented as plots of offsets from the reference lines. The units are inches to match what is in their database, although they are now switching to meters:

The navigation dams are different. They have multiple lines of pins in monoliths. We assume that disks in gate monoliths (which rest on bedrock) are more stable than a regular monolith, which are usually built on pilings. We occupy all of the gate monolith disks, as well as points located off the structure. Here is one of the navigation locks, where there are actually two dams, one on either side of the island. In this image, the "stable points" (gate monoliths as well as off structure pedestals) are yellow X's, alignment pins are green dots.

The data is processed similar to the above described procedures. The results are presented similar to the plot above, one plot for each wall.

The third type of structure are earth dams (earth/rock). Because the accuracy requirements are looser, we use GPS for these. Although there are pedestals defining the axis, and the points are collinear, we no longer use the pedestals, unless possibly as a base for GPS. I use one or two receivers as a base, running all day. The other two or three receivers I leapfrog across the dam, making sure that each point has at least 30 minutes, plus at least 15 minutes with each of its neighbor points. The base data is processed against nearby CORS to check its position, and also submitted to OPUS as a check. The results are presented as differences from a reference year (2005, when we did the first GPS surveys at the projects), rotated so that one of the axis is upstream-downstream. Here is what one of these projects looks like:

All of the above are computed on NAD83 (NSRS2007), UTM17.

We also have auxiliary surveys at the projects, like conduit settlement, conduit elongation, bridge elongation and settlement (bridges to intake towers), tower surveys (tilting and settlement), crack monitoring, as seen here:

Finally, we have to verify the NAVD88 elevation of all gages at the projects and the that the pool elevations match.

 
Posted : May 25, 2011 4:10 am
(@john1minor2)
Posts: 699
Registered
Topic starter
 

John

John
Needless to say that I am not even close to being in your league. The dam I have been monitoring is about 750' earthen. When the dam was constructed, they had 3 control points. I was brought in about 2 yrs after construction. I checked their control with gps and decided the control values they gave me were not tight enough plus 2 of the 3 points would soon be lost because of vegetative growth. I gave them 2 proposals. Use 3 local high accracy offsite already established GPS points or use the closest CORS sites which were about 100-150 miles away to the N-S-E. We run into the ocean to the W. The least expensive for them was to use the CORS and process using OPUS so all measurements could be related back to the same instant in time namley NAD 83 CORS96 epoch 2002. We also run digital levels across the dam. This year the client decided they would like to have the ability to go back to optical monitoring so we have established 2 new control monuments plus we still had one of the old original control monuments. The new monuments are currently in the open but we had to do some amount of brushing to clear sight lines between the monuments. This will become more burdensome as time goes by.

Thanks for taking the time to show your techniques. We all benefit. By the way, I enjoyed your recent postings about your FIG trip.

 
Posted : May 25, 2011 6:28 am
Page 1 / 2