Defining a state cache standard about vesseljs HOT 5 OPEN

I think you have some good ideas on one way to proceed. It is very valuable for the project that you are actually using it for something.

The memoization is sort of elegant, in that everything is calculated lazily. (Caching is not always beneficial, though. There is some lower limit where recalculating things is faster. Of course they can be combined too.)
Instead of "guessing" the dependent objects, they could be supplied in an array as second parameter to the memoize method. Simpler and more generally applicable.

There is a misconception about Ship.designState that it is supposed to be a dynamic object representing the actual state of the ship. My intention is that the design state is part of the ship specification, representing a "typical" setup (typical load configuration etc.), suited for some calculations/considerations (the role of certain given calculationParameters like draft and cb is a bit unclear, as they can be calculated from the hull and loads). For simulation scenarios, on the other hand, we should use one or more actual states.

I admit that I have not been great at marking the lines properly. I was the one to put object positions and "existence" in the ShipState class. Logically, some objects should be tightly bound to the ship itself, and I really think we need to solve that.

Regarding state properties that may change often, we must make sure that the amount of recalculation (of expensive calculations) is kept at a minimal, sufficient level.
(This potentially also applies to weight and Cg calculation on the ship, and some others which could conceivably be modified incrementally upon position/mass changes of parts. This becomes an issue once the number of parts grows, and could certainly be alleviated by a tree structure (which we have intentionally avoided to not lock ourselves to one so-called "taxonomy").)

I think we can have a type of simulation setup where a "ship simulation entity" is added to a simulation with an initial state, that could in some cases even be the design state (maybe by default). Then the simulation keeps the actual state separate from the ship object, and supplies it as parameter for calculations. This is the way I have intended the ship object calculations to be used. Calculations of interaction with the environment belong naturally on the "ship simulation entity". I also believe that fast-changing variables belong in that object. The "ship simulation entity" may well be an instance of an extended ShipState class.

I have not looked at all the code in your marsim project, or tested it. it looks really interesting, though. if you can get rid of the cluttering of the design state, and instead operate on an "actual state", it will be easier to convince me that you are doing the right thing.

from vesseljs.

getFuelMass should take a shipState parameter, and use that rather than the design state. I leave to you to correct that, because you are working on dependent code.

from vesseljs.

And maybe we should move the "design speed" and some other properties that don't make sense in a dynamical state to a separate object within the ship object. Maybe something like "design assumptions".

from vesseljs.

The design assumptions/criteria could also be separate from the ship specification and ship object. Then they could even be used (e.g.) as target for an optimizer that modifies the ship object to approach the given properties.

Keeping them separate from the specification is cleaner, and facilitates doing calculations with different assumptions without really modifying the design.

from vesseljs.

@icarofonseca It's about time for you to establish a good standard for the state / cache, specially if you are going to play with real time data from digital twins. A simple and efficient example would be good (e.g. parsing and recording data from the camera to the vessel).

from vesseljs.