Closed AgustinVallejo closed 1 year ago
From discussion with @AgustinVallejo and @jonathanolson, about possibly using mks.
MKS + adapters may be good enough, but brainstorming one more idea--If we get MKS working, maybe it would be straightforward to migrate that consistently/confidently to our own system of units? Not sure that's a great idea but just wanted to write it down.
Value | Equation | Model | Conversion | View |
---|---|---|---|---|
M | Given | 200 uM | x1e28 kg/uM | 1.99e30 kg |
D | Given | 100 uD | x 0.01 AU/uD | 1AU |
G | Given | 10000 | ||
V | sqrt(GM/R) | ... uD/uT | -> AU/yr -> km/s | 29.8km/s |
T | 2piR/V | ...uT | -> yr / uT | 1yr |
This table briefly summarizes the reasoning behind the value for each conversion multiplier. G value is given by the model, and suppose a single circular orbit around M=200uM and with radius D=100uD for uM and uD arbitrary model units. Kepler's third law can be used to infer T in uT and circular velocity equation for V in uD/uT. From there, it's a matter of unit conversion:
With all those values, G can be calculated with an error on the 5th significant unit, which incidentally is about the same measurement of uncertainty we have for it (Source).
I also asked for external advice from a professor who does this kinds of simulations and he advised us to keep using model units internally and change them at the end, because these numbers in MKS range several orders of magnitude and it's easy for the software to make mistakes:
1-1e-9**2 = 1 (with double precision)
17/03 meeting decision:
@samreid Do you think the unit tests could/should be done for this version of the sim or that's more of a task to be done on par with the PhetIO implementation?
I believe the unit tests don't have to be done for this release.
I'm fine with unit tests being done for the next release.
How about a quick force calculation sanity check and establishing a pattern of how the units are set up and converted?
@samreid I don't know if this is what you mean but now the unit conversions are always calculated at the beggining of the sim; no more seemingly arbitrary numeric constants. It's at the top of SolarSystemCommonConstants.ts
@AgustinVallejo and I wrote a harness for the unit tests, but did not enable the first test yet because we got unexpected values.
This issue is now done for this release. Units are being calculated and we make sure the sim engine and unit conversions are working the same as SI. Leaving on hold because we might want to look at this in the future PhET-IO release.
I converted the unit tests to TypeScript. I also had a question about this part:
const mass1SimUnits = mass1 / MASS_MULTIPLIER;
const mass2SimUnits = mass2 / MASS_MULTIPLIER;
const distanceSimUnits = distance / METERS_IN_AU / POSITION_MULTIPLIER;
There seems to be an asymmetry in that the MASS_MULTIPLIER converts between kg and uM (where the view unit is 1028kg). But the POSITION_MULTIPLIER converts between m and AU (where the view unit is AU)? I'm not saying there is a problem, but maybe good to document it somewhere? Or maybe it is written somewhere I could not find it?
Maybe add a link from https://github.com/phetsims/solar-system-common/blob/670cc9ea98513bf05573646623904c86e524f908/js/SolarSystemCommonConstants.ts#L13-L20 to the appropriate documentation, or mention the units there?
@jonathanolson will take a look at https://github.com/phetsims/my-solar-system/issues/116#issuecomment-1477990090 and determine if anything is needed for this release.
We can defer PhET-iO considerations for now.
Things look good here, the unit test referenced seems to do unit conversion correctly, and the model.md documents the conversions to my satisfaction.
Original flash sim uses unitless values, nice and round. We decided MSS will use AU, km/s and years. This entails a bunch of potential problems.
Here's what we wrote to the teacher: