Closed MatthewGrim closed 6 years ago
@darianvp I'm confused by two things, associated with the two commits above - can you help me?
The definitions in the README were inconsistent. I've changed them to match what I have seen in the ManyToOne and single SPS scripts that you generated. Can you check that you agree with the definitions, and order of the orbital elements as they stand?
Also, to make the last parameter in the orbital parameters the mean anomaly, did you have to set it explicitly from true anomaly in the STK simulation satellite properties? Or is it by default mean anomaly?
Looking at the angular distribution function for setting the constellation size and defining the angular distribution, you space the satellites out in true anomaly, and calculate the mean anomaly from there. For constellations > 2, does it not make more sense for this simulation to make the satellites spaced evenly in mean anomaly, as this should ensure they are evenly spaced out in time? I've changed it to this, and am starting a run, so let me know if you disagree.
@MatthewGrim
I see what you changed in 008 README about the start and end times in the report definition, the updated definition is correct.
I don't exactly understand what you mean about the definitions and order of orbital elements. Can you elaborate a bit more?
As for the true/mean anomaly issue: the website that I link to in the README shows that if you use connect command SetState Classical to change the orbital elements then you have access to the mean anomaly and not the true anomaly.
For which method is correct for distributing satellites equally in time: what you said makes sense (distribute equally in mean anomaly) and I could have been mistaken, but I'm not positive which way is correct. It should be relatively easy to verify in STK just by watching the propagation of three satellite orbits distributed via both methods.
@darianvp The two commits I referred to are now pushed - sorry I forgot to do this. The corrected definitions in the README are the ones I have changed in commit ef823ca and the change to distribute in mean anomaly is c8af85d ... both are directly above this message.
From what you've commented, and the reference agi link I didn't see, I think i understand what to do, but with the first issue could you take a look at the changes I made to the README and tell me if they make sense to you. Just to make sure.
@MatthewGrim
I see now. I didn't think anything of the order of the orbital elements in general, but based on the changes you made it looks like I made a mistake between the order in equatorial and south pole orbits. Looks good now.
As far as definitions, my intuition is that nu (true anomaly) is the true classical orbital element describing position in orbit. However changing it to M should really be no problem, especially in the context of the README which includes constellation design based on M.
Viewing the points I have generated oriented in mean anomaly, I think the choice is reasonable to space access periods evenly between the satellites.
The last commit should have been for #32
I still haven't generated this data set (and may not get the chance to, because the CDF need their stuff back), but it might be worth doing a different point, so that the satellites from the equatorial, and north pole data sets can be combined. This would mean taking the same 45 degree target North of the equator, and modelling orbits with apogee above the North pole instead. The results should be similar to the South pole results in principle, and this would make the two data sets comparable/combinable.
@darianvp do you have an opinion on this?
@MatthewGrim
I think adding a North pole satellite aiming at the "equatorial configuration" target seems reasonable. It provides a strong basis for comparison to both the south pole and equatorial configurations since it combines the orbit of one with the target of the other. If going ahead with it, I would immediately simulate a 2-satellite constellation since it gives you the data for 1 and 2 satellite configurations.
However it seems like the trade-off is between this and the 3-satellite south polar constellation. The argument for doing the third satellite in the south pole configuration is "completing" the data set. But for one this is more computationally expensive. Plus the two satellite constellation at the south pole is already shown to have high performance (in terms of blackout reduction) and adding a third satellite is likely to make little difference. In this case bridging the gap between polar and equatorial data sets with what you proposed seems more valuable.
I've done what @darianvp suggested, taking the third satellite as well, because we have time before these results are needed.
This issue is to document writing a script to generate the 3 satellite data set for the South Pole site