Use of Unit ID, Scientific Study

[bevans2000]

Why do some of the classes use the Unit identifier instead of keeping a reference to the real Unit object?
For example in ScientificStudy collaborators are managed by their identifiers which means an expensive lookup in the UnitManager to convert it to a object. It is so that they can be used as keys in Map objects? The real Unit object can be used just as easily if they have a correctly implement equals & hashCode method.

[mokun]

Why do some of the classes use the Unit identifier instead of keeping a reference to the real Unit object?

I recall having issues when de-serializing those object references in the past.

That's why we switch to saving a person's id instead of its problematic object reference.

[bevans2000]

It certainly makes the code slower because of the lookups. Also there us a difference in approaches in different areas which is never good.Worth addressing as a future task.On 17 Dec 2020 17:47, manny kung <notifications@github.com> wrote: Why do some of the classes use the Unit identifier instead of keeping a reference to the real Unit object? I recall having issues when de-serializing those object references in the past. That's why we switch to saving a person's id instead of its problematic object reference. —You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.

[Urwumpe]

The ID could make sense for storing historical data and separating it, but then we should use it consequently, where it applies: If the actual simulated person is not needed, but actually just a bureaucratic record of its past existence, an ID to this record should be used, while in present actions, the actual person should be used as subject or object of the action/verb.

Looking up if the person still exists and fetch its current data, is no performance concern, if this happens only rarely, like by a user browsing historic data or some AI action taking place to specifically locate the person mentioned.

This could also simplify a migration of Mars Sim to clusters, since the full data of a Person would no longer be required everywhere, just its global reference.

[bevans2000]

Yes that makes sense. So "active" processes/instance should use the Unit object.
Clusters is an interesting idea. I think a Settlement would form the basis for a single isolated cluster. Obviously global singletons like ScientificStudyManager has a problem because it would cross cluster boundaries. And such classes certainly cause a problem with the new concurrent pulse application across Settlements.

[Urwumpe]

Exactly that is what I think there, the settlements and the vehicles form nearly perfect islands with only very limited communication channels between them. The perfect case for scientific computing partitioning.

We could easily distribute such islands between the nodes of a cluster. The big technical issues would be:

• How to synchronize the clocks of nodes?
• How to partition Mars itself?
• What is Earth in our model?

Also, with some clearup, we could separate current agent simulation actions from an historic data repository recording events and "documents" and a browser for this historic data for the user.

[mokun]

Obviously global singletons like ScientificStudyManager has a problem because it would cross cluster boundaries.

So, let's break it apart and have a ScientificStudyManager in each settlement, shall we ?

[Urwumpe]

What is this class originally planned do?

I ask, because maybe, its job can be specified better and decentral work moved away from it into local classes or even into parts of the agent simulation, like having a science coordination type administration job for Settlers.

[mokun]

Yes. Exactly, scientific attributes should follow a person.

[bevans2000]

Let's rework it and split into Settlement focused. It also makes the code more thread safe as these global objects can be updated by multiple simulation tasks.

[bevans2000]

I have some spare time before going back to work so I will start o spltting the ScientificStudyManager into a Settlement orientated implementation.

[mokun]

Question : while we will be tracking Scientific Studies by settlement, can we also start creating the concept of a "scientific skill" ?

Each settler have his own natural attributes, personality traits and skills.

Why should we exclude or separate the scientific achievement out of the Person class?

Logically speaking, it should be a part of a person's Mind or at least a "memory map" of some sort, right ?

This may come in handy in future when we begin to experiment with serializing and deserializing a person across different simulation.

It will be very interesting to extract a person from an old simulation into a JSON file and reinsert him/her into another virtual Mars world.

Right now of course, it's not possible, with the exception of creating and saving the super basic profile of a commander prior to the start of a brand new simulation.

[bevans2000]

So here's the approach to the ScientificStudyManager

1. Move the ScientificStudy focused methods from the ScientificStudyManager to the study class. This will simplify the dependency and make the path of updates clearer. This mainly involves making the ScientificStudy class Temporal so it becomes aware of time passing.
2. Move the responsibility of updating via the time pulse from the manager to the primary researcher. This means the Scientific Study is updated in the context of the associated Settlement; hence improving the thread updates.
3. Move the Settlement orientated methods from the manager into the Settlementclass.
4. The manager is then left with the overall searching/read only methods which are safe to be called via a client thread (either console or UI).
   Quite a few changes so obviously branching the changes.

[bevans2000]

I have committed a rework of the Science classes. The goal was to remove the updates from teh Scientific Study manager so the studies can be updated in align with the associated Settlement. The Scientific Study instances are now "owned" by the lead researcher and hence updated as part of their update.
Also some methods have been moved into the Scientific Study class out of the manager; leaving the manager a read-only aggregator now.