tmcclintock / frispy Goto Github PK

doesn't do anything

Use the basic sphinx build and host on either RTD or github pages.

Here is the TODO checklist:

• create docs on readthedocs -- done, docs are found here
• link the docs from the readme.rst page
• link readme.rst to the index.rst page
• translate README.md into rst
• add a page describing the mathematics
• add a page on the Model object and how to set your own values to try different flights
• generate figures in a notebook and add them to the docs
• use autoapi to split up the submodules more nicely

The example notebooks suggest you can do something like

>>> from frispy import Disc
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name 'Disc' from 'frispy' (/home/jakeb/development/phase_c/venv/lib/python3.10/site-packages/frispy/__init__.py)

However, as Disc is not imported into the init.py file, this causes an error. Instead, you have to do >>> from frispy.disc import Disc

scipy.integrate.solve_ivp allows for callable "event" objects to be passed to the solver. This is an elegant way to handle the disc hitting the ground, since it can let the integrator terminate early.

This could also let the code support non-flat grounds (e.g. simulating throwing over a hill).

Travis doesn't support open source CI/CD indefinitely now, and they are asking me for money. We should move off of travis and switch to GitHub Actions.

This should be high priority.

This will make FrisPy pip-installable.

EOM should have instantaneous coordinate attributes. Everything can be computed off of setters.

Sara Hummel's original 2003 thesis on the topic (found here) is where I first found the ODEs. I attributed her in the other repo, and in the earlier version of this code, but I need to re-add the attributes in in the README and other places.

This should be straight forward. Things like labels and units should be standardized. Shortcut routines for plotting angles in a circular plot. Automatic rescaling. Etc.

Look into using this: https://github.com/monim67/poetry-bumpversion in order to keep __init__.py and pyproject.toml in lock-step with each other.

Get automatic coverage working.

The initial conditions of the disc are being passed in via a dictionary to the Disc's constructor. This isn't ideal because we can't pass in just a few ICs at a time (for instance just the velocity). This issue proposes implementing the InitialConditions class and making the Disc composed of an optional InitialConditions as an argument.

After gathering some user feedback, instantiating the Disc is annoying, since creating it with one or two initial conditions changed (like z and vx, for instance) requires writing out the whole dict of initial coordinates. This should be streamlined.

Replaces #14 . The coordinates should just be a dataclass, with properties for computing certain quantities (e.g. the rotation matrix) on the fly.

Or RK5. doesn't matter. scipy's solver is slow, so anything will do.

AC:

• let the solver be passable
• demonstrate that our own is faster

Use this action.

This will cut a new release automatically for v2, and solve #22.

Hi,

I've been playing around with some different initial conditions and am a bit confused why when throwing the frisbee vertically upwards with no spin it doesn't fall directly downwards.

Initial conditions:
Disc(vx = 0.00001, vz = 20, dgamma=0))

Output:

I also tried to plot the velocities.

It looks like rather than going straight up and back down again the frisbee has tilted to the right and sped up in that direction which confuses me as I can't understand why the disc would tilt that way. I also don't understand why vz appears to not go below 0 despite the disc appearing to fall in the visualisation.

Do you have any idea what might be causing this? Could it be an error in the underlying model, or is it some sort of artifact from the simulation?

Any help would be appreciated, thanks!

PDS throws many errors. Tackle it in a dedicated PR.

Too busy.

The default settings on the scipy integrator are suuuuper slow to converge. It takes upwards of 30 seconds to do so with the default throw. It is also very dependent on the initial velocity of the disc. Figure this out so that it isn't so crappy. It may be that the calculation has to be rephrased.

Hey Tom it's McCann! Awesome repo. I ran into an issue today adding this module to a CI pipeline.

Steps to reproduce:

1. python -m venv tempvenv
2. source ./tempvenv/Scripts/activate
3. pip install frispy
   Error output
   "ModuleNotFoundError: No module named 'numpy'"
   

This error occurs even if numpy is installed :/

I think the problem is that we have import frispy inside setup.py. Is that intended?

Because markdown can't be read into the docs.

The Environment class contains constants used in computing the forces and torques. These include the disc's "immutable" physical characteristics like its mass, moments of inertia, and area as well as actual environmental factors like air density and force of gravity.

The first group is different than the second group and should be separated, so that Environment really only contains the environment. The former should become attached to the Disc.