Integral Method Comparison

Warning

This page is under construction. Please bear with us as we port our Java tutorial to python.

Now that we have explored multiple methods to implement integration in Aerie, let’s compare all of the methods in the Aerie UI. To make things more interesting, use the 2nd approach to the Polynomial method so we can see how that approach enforces a data volume capacity. Compile the current version of the model (./gradlew assemble) and upload it into Aerie. Build a new 1 day plan off of that model and call it “Mission Plan 3”.

For this plan, throw a couple of collect_data activities near the beginning of the plan, create a change_mag_mode activity after those activities in the first half of the plan and set that activity’s parameter to HIGH_RATE. Throw one more collect_data and change_mag_mode activity near the end of the plan to make sure we get a plan that goes over our data capacity threshold. With our simple plan built, go ahead and simulate the plan to see the resulting resource profiles.

The easiest way to compare our four integration methods is to use Aerie’s Timeline Editing capability to build a row that includes all four of our data volume resources:

• ssr_volume_simple

• ssr_volume_sampled

• ssr_volume_upon_rate_change

• ssr_volume_polynomial

If you do that, you’ll get a timeline view that looks something like the screenshot below

Looking at ssr_volume_simple, you’ll see that data volume increases at the end of each collect_data activity, and for the first two activities, the result at the end of the activity is consistent with the other volumes. You may recall that we did not implement a data volume integration for the change_mag_mode activity for ssr_volume_simple (although we could have with some work), so as soon as one of those activities is introduced into our plan, our volume is no longer valid.

ssr_volume_sampled has a nice looking profile when zoomed out at the expense of computing many points, which you can see if you zoom into a shorter time span. If you zoom far enough, you can see the stair-step associated with computation of each sampled point. If we were to change our sampling interval to something larger, we would lose some accuracy in our volume calculation if the activity start/end times aren’t aligned with are sample points.

ssr_volume_upon_rate_change has much fewer points, but you can see that it produces the same volume as our ssr_volume_polynomial resource at the time points it computes until we go above our maximum capacity. ssr_volume_polynomial has same computed points as ssr_volume_upon_rate_change, but has linear profile segments in between points. It also has an additional point once it reaches the capacity threshold, and then it remains at that threshold for the remainder of the plan (we don’t have any downlinks or we would see the volume decrease).

Hopefully looking at the various methods of integrating in Aerie has given you some insight into the modeling constructs available to you. You can do a ton with what you have learned thus far, but next we’ll go over some additional capabilities you will likely find useful as you build models with Aerie.