Example Section 1-sim_to

[teubert]

First PR updating the examples to the new format.

This example introduces simulation. The first section (the subject of this PR) introduces the simulate_to method, and some features surrounding it (save_pts, save_freq, plotting results, etc.)

The next PR will introduce the simulate_to_threshold method along with the print, progress, horizon, and threshold_keys arguments

[github-actions]

Thank you for opening this PR. Each PR into dev requires a code review. For the code review, look at the following:

• Reviewer (someone other than author) should look for bugs, efficiency, readability, testing, and coverage in examples (if relevant).
• Ensure that each PR adding a new feature should include a test verifying that feature.
• All errors from static analysis must be resolved.
• Review the test coverage reports (if there is a change) - will be added as comment on PR if there is a change
• Review the software benchmarking results (if there is a change) - will be added as comment on PR
• Any added dependencies are included in requirements.txt, setup.py, and dev_guide.rst (this document)
• All warnings from static analysis must be reviewed and resolved - if deemed appropriate.

[kjjarvis]

I think this is a great start. I made a few comments just for clarity/readability. I think you may also want to delete the notebook output. Take a look at the diff and look at some of the long strings that describe images - are those supposed to be there or best to delete and let the user run the notebook? Otherwise, it looks great!

[kjjarvis]

Is there any other word we could use for "Simulation is the process of predicting the evolution of a system's state"? I like this word choice, but I feel like it is a bit confusing in the next few sentences where we say it's the "foundation of prediction" and different than a full "prediction". I don't have a great solution

[kjjarvis]

Suggested change

"The first section introduces simulating to a specific time (e.g., 3 seconds), using the `simulate_to` method. The second section introduces the concept of simulating until a threshold is met rather than a defined time, using `simulate_to_threshold`. The third section makes simulation more concrete with the introduction of [future loading](https://nasa.github.io/progpy/glossary.html#term-future-load). The sections following these introduce various advanced features that can be used in simulation\n",

"The first section introduces simulating to a specific time (e.g., 3 seconds), using the `simulate_to` method. The second section introduces the concept of simulating until a threshold is met rather than a defined time, using `simulate_to_threshold`. The third section makes simulation more concrete with the introduction of [future loading](https://nasa.github.io/progpy/glossary.html#term-future-load). The sections following these introduce various advanced features that can be used in simulation.\n",

[kjjarvis]

Suggested change

	"Let's go through a basic example simulating a model to a time. In this case we are using the ThrownObject model. ThrownObject is a basic model of an object being thrown up into the air (with resistance) and returning to the ground.\n",
	"Let's go through a basic example simulating a model to a specific point in time. In this case we are using the ThrownObject model. ThrownObject is a basic model of an object being thrown up into the air (with resistance) and returning to the ground.\n",

[kjjarvis]

Suggested change

	"* **[states](https://nasa.github.io/progpy/glossary.html#term-state)**: Internal variables (typically hidden states) used to represent the state of the system. Can be same as inputs oroutputs but do not have to be. State is frequently denoted as `x`.\n",
	"* **[states](https://nasa.github.io/progpy/glossary.html#term-state)**: Internal variables (typically hidden states) used to represent the state of the system. Can be same as inputs or outputs but do not have to be. State is frequently denoted as `x`.\n",

[kjjarvis]

Suggested change

"In this case, times are the start and beginning of the simulation ([0, 3]), since we have not yet told the simulator to save intermediate times. The ThrownObject model doesn't have any way of controlling or loading the object, so there are no inputs. The states are position (`x`) and velocity (`v`). This model assumes that you can measure position, so the outputs are just position (`x`). The two events for this model are `falling` (i.e., if the object is falling towards the earth) and `impact` (i.e., the object has impacted the ground). For a real prognostic model events might be failure modes or warning thresholds."

"In this case, times are the start and beginning of the simulation ([0, 3]), since we have not yet told the simulator to save intermediate times. The ThrownObject model doesn't have any way of controlling or loading the object, so there are no inputs. The states are position (`x`) and velocity (`v`). This model assumes that you can measure position, so the outputs are just position (`x`). The two events for this model are `falling` (i.e., if the object is falling towards the earth) and `impact` (i.e., the object has impacted the ground). For a real prognostic model, events might be failure modes or warning thresholds."

[kjjarvis]

Suggested change

	"Next, let's look at the event_states"
	"Next, let's look at the event_states (i.e. 'falling' and 'impact')."