IGS Analysis Center Workshop - IGS - NASA

known, the two solutions will be adjusted to the same value (since they both refer to thesame monument). In this case, it is acceptable to remove the redundant information so longas a flag is set to indicate this along with the information given in (vi) above. This flagindicates that more than one antenna height or type was used for that estimate, and thereforethe eccentricity information given in this file is incomplete..(viii) The header of the file include the epoch of the solution, start and stop time of inputdata, number of parameters, institutional identifier, date produced, a flag to indicatewhether or not velocity parameters are included, a code number to indicate presence andtypes of constraint, a unique solution identifier, a quality control code, and optionally adescriptive character string. A solution “type” identifier will indicate whetherrepresentations (a), (b), or (c) are used (see Section 3.3), and whether Cartesian orspherical coordinates are estimated, An ambiguity resolution identifier will indicatewhether the solution has been bias-fixed (integer carrier phase biases) or remains bias-free(real-valued carrier phase biases).3.5 Combination of orbital parameters and “sister solutions, ”. .Fixing the regional orbits to that of the global solution leads to the problem that somesatellites are better determined than others, and this information is no longer propagatedinto the regional solution. One consequence is that the regional covariance matrix will beartificially reduced. Another consequence is that the effects of badly modeled satellites willbe amplified in the regional solution. The first problem can be partly mitigated by ad hocresealing of the covariance matrix, or equivalently, by inflating the assumed data noise.The second problem might be partly mitigated by applying different weights to data fromdifferent satellites; however, the validity of this approach is questionable. On the otherhand, it is clear that a very badly modeled orbit should be eliminated completely from theregional solution. Therefore, it is important that GAC’S agree upon some method ofindicating orbit quality.Another approach is to combine not only station coordinate parameters, but also orbitalparameters and EOP between regional and global solutions [Lindqwister et aL, 1991;Dong, 1993; Feigl et al., 1993]. This will formally propagate orbital errors into theregional network solution. This approach is not as convenient from the point of view ofthe user, who must now estimate all the orbital parameters. Moreover, it is not clear howto do this properly unless (i) the RAC is using exactly the same software as the GAC, (ii)the same nominal orbital parameterization is used at the same starting epoch (e.g., is solarradiation parameterized the same way?) , and (iii) the same nominal EOP series is used.The use of stochastic orbit parameters makes this scheme even more difficult.Nevertheless, IGS should be prepared to accommodate those RAC’S who might cooperatewith GAC’s in this way, because in principle such regional solutions are more rigorous,and it may be useful to assess the relative performance of such solutions versus those usingfixed IGS products.In the case that RAC’S and GAC’S cooperate to combine orbital parameters, we nxommendthat the RAC and GAC cooperate in forming a NAC, and prepare and submit the fullycombined fiducial-free solutions themselves. In addition, the regional solution could besubmitted separately from the global solution provided the file header contains informationso that the pecessity of pairing the two solutions is apparent. We recommend an identif~erthat states the name of its “sister solution(s).” It might be convenient to submit sistersolutions for those users who are only interested in, say, the global portion.A complication arises when the global free-network solution is computed and submittedfirst, followed by a later computation of a regional sister solution, The problem is that77