OPUS Possibly Not Working

Well, NGS did some work last Friday on OPUS and OPUS Projects. The notice was still there over the weekend so I clicked on OPUS. There was a note that they had done some maintenance, but nothing that should impact how OPUS worked.

I thought that disclaimer a bit odd.

I ran one Monday and saw the notice. The results (precise orbits) were very close to the Rapid orbits results I'd gotten on it a couple weeks earlier. The report was different in that it attached an XML report to the ordinary email of the extended report and I hadn't seen that before.

I re-ran that same file and it processed fine. It used one different CORS and gave me a position 2 mm different horizontal and 1 mm vertical. No XML attached.

I have not done any OPUS this week. I checked the CORS ftp site and the folders seem to be filling in normally with data. Do they still have a West Coast CORS data site?

Paul in PA

Bill93, post: 429936, member: 87 wrote: I ran one Monday and saw the notice. The results (precise orbits) were very close to the Rapid orbits results I'd gotten on it a couple weeks earlier. The report was different in that it attached an XML report to the ordinary email of the extended report and I hadn't seen that before.

The XML report is not an option with the extended output. I always select the extended output, but every so often the email includes the XML report as an attachment.

I reran a 6 1/2 hour session from last October and found a slight difference with the previous solution that used rapid orbits. The difference was 2mm, 2mm, 1mm (NEU), but one of the CORS stations changed from P041 to DSRC. I resent requesting P041 be used and the differences are 1mm, 2mm, 7mm (NEU).

The OPUS message from Tuesday is at https://geodesy.noaa.gov/sitemsgs/OPUS/archive/OPUSmsg-Linux.shtml when the OPUS code was migrated.

OPUS had some trouble downstream with organizing the files users opted to share, but no other problems proven yet.

I ran one today from yesterday's data, and it hits an RTN position within 0.05' -- about what I'd expect.

I've run three today with no problem. I have however had problems with data availability from several CORS stations.

Well, Loyal figured it out and it is important. But I am going to let him detail the fix as he figured it out.

Loyal...

Okay, so here's what I figured out:

This is the RINEX that I get out of my HCRinex6 (or Covert to RINEX) converter (Observation types):

8 C1 L1 D1 S1 P2 L2 D2 S2 # / TYPES OF OBSERV

It has been my SOP for many years, to strip all of the "unnecessary" observations out of a RINEX File before submitting it to OPUS_S

3 C1 L1 L2 # / TYPES OF OBSERV

This has always worked FINE (up until this week), when these files STOPPED working through OPUS (including files that processed just fine LAST WEEK). So I went back to the Original RINEX, and stripped everything BUT C1L1L2P2 (which is what I do for the RARE occasions when I play with OPUS_RS).

4 C1 L1 L2 P2 # / TYPES OF OBSERV

Bingo...the file(s) process just fine. Apparently PAGES_LT has been modified to require the "extra" (P2) observation. OR something else has been changed in the OPUS_S routine that has the same net effect.

Mystery solved for my purposes.
Loyal

Not quite solved Loyal. Perhaps this change was unintentional.

I have been informed that OPUS Static now, as in this afternoon, will accept files without P again.

I have heard that they are constantly doing tweaks to OPUS and PAGEs, and not really changing any version numbers, etc.

I do the same with my programs, I am always "tweaking" them, and I don't consider that a major change. But, sometimes a small change can have a large effect.

I could be wrong, but that is what I was told by someone.

Most likely someone swapped in the OPUS-RS filter for the OPUS-S submission chain without thinking of the consequences.

BTW, why strip out P1? Leaving it in makes it easier to split a file for OPUS-RS to confirm your solution.

Paul in PA