Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Orbits seem more likely to be stable? #333

Closed
KatieWoe opened this issue Jun 1, 2020 · 6 comments
Closed

Orbits seem more likely to be stable? #333

KatieWoe opened this issue Jun 1, 2020 · 6 comments
Assignees
Labels

Comments

@KatieWoe
Copy link
Contributor

KatieWoe commented Jun 1, 2020

Test device
Dell
Operating System
Win 10
Browser
Chromium Edge
Problem description
For phetsims/qa#505. May not be a concern, but it is a difference I have noticed.
In the new dev version, orbits made by placing the orbiting object in non-default settings seem to be more likely to be stable than in the published version. This is hard to tell for certain, as small differences in starting variables that can't really be controlled can throw off the result, but the difference seemed consistent enough to report.
Steps to reproduce

  1. Go to the second screen in both dev and published version
  2. Turn on grid
  3. Turn on path
  4. Move the orbiting object closer
  5. Press play and observe both orbiting paths.

Visuals
orbitmorestablenow

Troubleshooting information:

!!!!! DO NOT EDIT !!!!!
Name: ‪Gravity and Orbits‬
URL: https://phet-dev.colorado.edu/html/gravity-and-orbits/1.2.0-dev.10/phet/gravity-and-orbits_en_phet.html
Version: 1.2.0-dev.10 2020-05-26 17:36:54 UTC
Features missing: touch
Flags: pixelRatioScaling
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.61 Safari/537.36 Edg/83.0.478.37
Language: en-US
Window: 1536x754
Pixel Ratio: 2.5/1
WebGL: WebGL 1.0 (OpenGL ES 2.0 Chromium)
GLSL: WebGL GLSL ES 1.0 (OpenGL ES GLSL ES 1.0 Chromium)
Vendor: WebKit (WebKit WebGL)
Vertex: attribs: 16 varying: 30 uniform: 4096
Texture: size: 16384 imageUnits: 16 (vertex: 16, combined: 32)
Max viewport: 32767x32767
OES_texture_float: true
Dependencies JSON: {}

@KatieWoe
Copy link
Contributor Author

KatieWoe commented Jun 1, 2020

Even when both orbits are stable, the paths still seem different.
Dev:
devdifferent
Published:
pubdifferent

@samreid
Copy link
Member

samreid commented Jun 2, 2020

@arouinfar do you think this could be explained by the model changes we made in #302 ?

@samreid samreid assigned arouinfar and unassigned samreid Jun 2, 2020
@arouinfar
Copy link
Contributor

In the new dev version, orbits made by placing the orbiting object in non-default settings seem to be more likely to be stable than in the published version.

I tested this with a few configurations, using this general procedure:

  1. To Scale screen, Star/Planet scene, grid/path on
  2. Pause at some number of Earth days (to ensure position/velocities are equivalent)
  3. Adjust velocity and/or position using some common landmark (e.g. moving Earth or tip of velocity vector to nearest grid intersection)
  4. Compare resulting orbits in dev and latest.

In all cases I found the orbits to be very similar and equally stable.

Even when both orbits are stable, the paths still seem different.

@KatieWoe can you describe your method? I'm seeing very similar looking orbits on my end.

For example

  1. To Scale screen, Star/Planet scene, grid/path on
  2. While paused, drag planet one grid to the left (now just one square away from the star).
  3. Play and compare paths

Dev:
image

Latest:
image

@arouinfar arouinfar assigned KatieWoe and unassigned arouinfar Jun 4, 2020
@KatieWoe
Copy link
Contributor Author

KatieWoe commented Jun 4, 2020

@arouinfar I may be wrong about the different paths, since I found it a bit difficult to make sure everything was in the same starting position. If you aren't seeing differences I'm willing to let this go.

@arouinfar
Copy link
Contributor

Thanks @KatieWoe.

I find it incredibly difficult to repeatably alter the orbit without first pausing the sim. If you were dragging things around while the sim was playing, I think there is a pretty good chance that the adjustments were dissimilar enough to create the behavior you observed.

@KatieWoe
Copy link
Contributor Author

KatieWoe commented Jun 4, 2020

I did have the sim paused at first, but was still finding it difficult.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants