Hi Fabrizio and Mariella,
I'm sending a copy to Leonid Elenin who, I hope, will start remote
operation of FIRST in the meantime and thus should be aware of our
progress, and to Igor and Vladimir as well for the same reason
Sorry for late reply - back from Bolivia, I spent the last week some 150
kilometers away from Kiev (together with Igor, Vladimir, and Leonid, by
the way) and had no chance to even check my e-mail.
> for some images we obtained this
>
> I THINK WE WON but not sure
>
> Now we will try on others but before we would like to receive your opinion
First, my congratulations! Definitely, you won. Still a few remarks. I
assume that you visually checked frames after processing and removed any
possible false detections from .RES file, if any. Most of them are
"objects" with only 3 measurements of 5 (however, of course, not all
such objects are false!). And that you had a TLE matching the date of
observations in .Apex\tle, so any question marks in ident.txt refer to
objects that are actually missing from TLE.
Another comment refers to objects like 23331 in .RES.check. If you get
the situation like this, when one or two measurements in a series match
some catalog object (23331 in this case), while others match another
object or no object at all, this is probably a hint that these one or
two measurements should be considered as outliers in this series.
Unfortunately, you cannot confirm this with absolute confidence, as Apex
then splits the whole series into two or more separate sub-series,
according to presumable identification of each measurement, so you
cannot identify outliers according to their residuals. Moreover, this
may be also a matching error, especially if you use outdated TLEs. You
cannot tell one from another. But, in any case, it is safer to consider
such measurements as outliers and remove them from .RES if you have
enough measurements left (three or more).
Another bad case is 23686. Here you obviously have a mixture of two real
objects within the same block of measurements, under the same name
23686. This can be easily inferred from external residuals: RA residuals
for the first 5 measurements clearly differ from those for the next 5.
Also initial orbit determination gives an absolutely crazy result, with
RA residuals of the order of 10 arcminutes! The reason here is false
match, probably due to bad TLEs. Two distinct objects from different
series were identified as a single catalog object, so their measurements
fell into the same block. The same is the case also for 34710. In these
two cases you had to manually split each series into two separate blocks
of measurements, leaving the initial name (e.g. 23686) for the first of
them and assigning a new arbitrary name (e.g. 2368601) to the second
one. Generally, you should pay special attention to "objects" containing
more measurements than the length of original series of observations for
each field (like 10 instead of 5 in our case). Depending on overlap of
adjacent fields, there is non-zero probability that these could be
actually the same "physical" object appearing in both fields (usually at
their edges, or a fast-moving object), but in most cases this is a mere
mis-identification. A good news is that the next update of Apex will not
use catalog names at all in .RES file, assigning unique internal names
to each object found (still ident.txt will be available for your
curiosity
), so by definition there is a guarantee that no distinct
objects will appear in the same block of measurements. Keep an eye on
updates in /unstable. But in the version you use Apex tries to do more
than it can, so you need to check this manually.
Apart from these minor comments, you reached full success, I think.
Congratulations again!
Regards,
Vladimir
