steo85it/pyxover

Crossover absolute times not included in xov*pkl

Closed this issue · 6 comments

The time of each crossovers in the pickle containing all the other information regarding the crossovers only contains the time from the start of the gtrack (possibly different whether the Northern or Southern hemisphere is considered).

To compute the "absolute" time, this information has to be fetched in the related gtrack. This is a bit cumbersome, but also lack efficiency, as it takes quite some resources to load the relevant pickle (just for one real value).

When exporting the crossover information to an external format (e.g. csv), this is really the bottleneck in term of computational time, especially for a large number of crossovers (for two hemisphere).

I would suggest to somehow add this information to the xover pkl.

This issue related to issue #5

so you would include the "absolute/j2000" epochs corresponding to the xover along each track? Isn't the "initial epoch" of each track also stored in the xover table? If yes, one could easily reconstruct the "xovers epochs J2000", if not, I think that the same info is retrieved in AccumXov and the step can be copied to pyxover (if that's more convenient for some uses).

The initial epoch of each track in the xover table would be sufficient. It's not in there for now, but it may have been foreseen, as one attribute of the xov class is t0_tracks (=None).

I didn't find something similar in AccumXov. But I could fill xov.t0_tracks with a dictionary containing all the gtrack.t0_orb. Just to give some numbers, reading all the t0_orb for 12 weeks tracks takes me 160s, vs 45s just to export the partials of all 12 weeks combinations to a csv file.

Sounds good, thanks! just double check that those epochs end up corresponding to the ones you would read from the ladata_df tables (one never knows...)

After more investigations, I suggest to add tA/tB to the xover pickle, which can be computed from dtA/dtB. Indeed dtX is computed from the dt's of track X in xov_setup.get_dt() , contained in its ladata_df which can be mapped to ET_TX.

dtA/dtB could even be removed, provided some further adaptation in the code.

If you can replace dtX with tX, thus keeping the size of the xovers table constant, that would be ideal, yes.

Also, as you pointed out, it would be much safer/more efficient to save the xovers df instead of the full object (not the same issue, but somehow related).

After some tests, I can say that loading a pickle containing only ladata_df instead of the full object is indeed more efficient. However, some attributes of the full object (gtrack or xovers) are later used (e.g., pert_cloop, pert_cloop_0, and sol_prev_iter) and need to be somehow stored (in a separate file?).