Using the beta : http://beta.ngs.noaa.gov/OPUS/ , I'm not getting any solutions back at all. 3 days ago they were submitted, and if I try to re-submit it says it's still in the processing que.
Using the 2011 frame : http://www.ngs.noaa.gov/OPUS/index.jsp , I believe I got 1 out of the 3 solutions back in 24 hours.
I just started using Opus a month ago, so I'm not sure if these kind of delays are normal now and then? I've enjoyed usually getting a solution back within 15 minutes or so.
I've been having the exact same problems.
They need some better programmers...
I posted one on Wednesday and received the solution within 45 minutes.
I have not submitted the last few days.
I am unable to access the CORS data ftp site, but was able to use ufcors for some data from last week.
Paul in PA
I submitted 2 files to OPUS Static yesterday around 3pm (AK) and received a solution last night just before midnight.
i submitted 2 yesterday and it took about 6 hours
Maybe the reason for the variety of response time is due to increased use from abandoned TGO users. We are using OPUS because of that!
Got a response from NGS :
"Any results yet? System has been down and now
backed up due to many submissions. Sometimes
sending in a file during off hours might help.
Peak hours are 8am-6pm EST."
Glad it wasn't just me, thanks guys.
FWIW, I am waiting on one file over 24 hours. I have since done my own baseline and achieved better results on a known point than OPUS could give (as a confidence check).
I just received one that I sent in yesterday moring about 8:30. I'm going to be interested to see what TBC calculates for the same point when I finally get it. Usually they are very close.
This OPUS solution gave me the EL HGT (2495.744m), but at the ORTHO HGT it states:
[Geoid Model Not Yet Available w/ NAD83 (2011).] OK...so why not use Geoid09? No big deal as I'll apply it myself, but it's always nice to see if everything is checking.
I got the same message and I did it myself in StarNet which is probably a violation of some cosmic Geoid rule.
I hooked a come-along winch onto the Geoid and dragged it over to NAD83(2011) epoch 2010.00 ha ha!
You mean you moved that .04'?
NAD83(2011) & GEOID09
A comment about using GEOID09 & NAD83(2011)...DON'T DO IT!
There is a reason WHY the NGS is NOT returning GEOID09 based NAVD88 Height estimates with the NAD83(2011) OPUS results...they are NOT actually related to each other properly. This is (one of) the reason(s) that the Passive Network (with contains the GPS_on_Bench Mark data) is being reprocessed. At that point, the Geoid group can process a NEW HYBRID Geoid Model (GEOID12) that represents the BEST fit of the NAVD88 Bench Mark Data AND the new NAD83(2011) Realization Ellipsoid Heights (Apples & Apples).
I believe that you will find the variance to be NON-trivial!
Just my 2-bits, and maybe I'm wrong (again).
Loyal
NAD83(2011) & GEOID09
Your comment sounds similar to this excerpt from a post-porcessing software user manual:
When correcting ellipsoidal heights to produce orthometric heights, it is very important that the geoid and processing datums match. For example, if EGM-96 is used, then the base station coordinates should be in WGS84, and this datum should also be used for processing. Be careful to use the same geoid model as used on the control sheet. This lessens the likelihood of differential errors developing.
Another problem with OPUS
I have also een experiencing the LONG return times.
But, there is another problem, well, only if you use Trimble R8 GNSS receivers.
OPUS-RS gives an error message:
1027 WARNING! You have selected an antenna/dome combination for
1027 which NGS does not have calibration information. However, OPUS
1027 was able to find calibration information for your antenna
1027 with a different dome (or no dome). This antenna calibration
1027 information will be used.
1027
but the results are reasonably correct.
However, using OPUS-S there is no error message, but yet the Z values are off by more than a decimeter, more like 0.15 m.
Its broke.
