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

Save and load atoms #76

Open
minghuaw opened this issue Feb 16, 2022 · 2 comments
Open

Save and load atoms #76

minghuaw opened this issue Feb 16, 2022 · 2 comments

Comments

@minghuaw
Copy link
Contributor

What are the states that must be saved if I were to save and then load the atoms and continue the simulation? I have tried saving OldForce, Force, Position, and Velocity with the "1d_mot" example but the simulation will yield slightly different results starting from the second step after loading. I have also tried saving some of the samplers but found no luck. Is there any other states that should be saved together? Thanks in advance.

@ElliotB256
Copy link
Collaborator

Hey @minghuaw, sorry for the delay in replying to this.

In order to know how to save the state of an entity, you need to know what components belong to that entity. So it's worth discussing 'given an entity, what components are on it' first. It's worth highlighting that ECS implementations tend to be either archetypical implementations (e.g. Unity DOTS), which store entities with similar component composition together, or the kind of vector ECS (e.g. specs) which store different components as separate arrays.

An important practical distinction is that archetypical implementations have a very easy time figuring out what components belong to an entity, because it is enshrined in the archetype itself. This also makes copying entities very easy - take a look at Unity's Instantiate function, which produces a copy of a specified entity. In the vector ECS implementation, the only way to determine the composition of an entity is to loop through all of the tables checking if the entity is inserted there. That gives worse performance and also requires all tables to be known (which is the problem you are having here - how to define a list of all tables to check). To save the simulation, I would enumerate all storages in specs and save all of their contents (this would also capture lasers, ovens, magnetic fields, etc).

specs also has some innate saving/loading functionality, but I have not looked at this in detail yet: https://specs.amethyst.rs/docs/tutorials/13_saveload.html

At the moment, the plan is to migrate to bevy once the parallel performance reaches parity with specs - the bevy syntax is much nicer, the ECS is faster, and more feature rich. It's probably not worth making large changes to atomecs on the ECS side until that migration is performed, as the changes wont be long lived.

PS: As an aside, the instantiate functionality allows for some very convenient patterns. For instance, we currently must define atoms emitted from an atom source programmatically, which is quite a rigid way to work. With an instantiate function, we would be able to just define an oven and give it an entity to emit - and the entity composition could then be left very general and open to the user to define.

@minghuaw
Copy link
Contributor Author

minghuaw commented Mar 2, 2022

Thanks for the reply. I am actually just looking for saving the Atom''s states not the entire simulation. The remaining simulations setups will be kept the same.

I have followed specs saveload example and saved four states, Position, Velocity, Force, and OldForce, which doesn't give me the same position/velocity one step after loaded into a new simulation with the same setup.

Do you have any recommendations on what states must be saved/loaded in order to have consistent positions/velocities comparing to a simulation that is run continuously?

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

No branches or pull requests

2 participants