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

Fix emigration and immigration propagators in propulator.py and pollinator.py. #60

Open
mcw92 opened this issue Aug 4, 2023 · 1 comment
Assignees
Labels
maintenance Improve code readability and robustness.

Comments

@mcw92
Copy link
Member

mcw92 commented Aug 4, 2023

Currently, emigration and immigration propagators are passed down to the actual propagator and pollinator using the class itself and not an actual instance. The respective propagators are repeatedly instantiated before every new migration step. However, propagators should be instantiated only once (in the __init__).

This is also related to issue #61.

@mcw92 mcw92 added the maintenance Improve code readability and robustness. label Aug 4, 2023
@mcw92 mcw92 self-assigned this Aug 4, 2023
@mcw92
Copy link
Member Author

mcw92 commented Aug 25, 2023

Migration

  • For real migration (cf. Migrator class), copies of individuals are not allowed. Whenever a worker on an island performs migration, we can thus choose all emigrants from the eligible individuals at once, shuffle them, and then send them away to each respective target island according to the migration topology.
  • Thus, we only need one emigration propagator for each island that has the number of overall individuals to emigrate to all other islands as its offspring argument. This number can be calculated by summing over the respective row in the migration topology.
  • It would be possible to instantiate these island-specific emigration propagators on the very top-level in the user script and pass it as a list to the Islands class which assigns each island its specific emigration propagator from this list based on the island index. This has the advantage that the user can set all other arguments required for instantiating the propagator directly.
  • Alternatively, the emigration propagator could be instantiated in the __init__ method of either the Islands or the Migrator class. This would maybe require an additional kwargs attribute to pass down custom arguments for instantiating the propagator.
  • This probably also implies that a sending island does not differentiate between target islands when sending emigrants. If we would like to have that, we would need to pass down a (nested) list of num_islands * (num_islands-1) propagators. This would probably be the most general solution which might also work for pollination. However, if we were to choose the emigrants for each target island separately, we would need to take care of deactivating those that are gone before choosing the next ones. This also implies some kind of hierarchy for the target islands (which one gets to choose first?).

Pollination

  • For pollination, copies of individuals are allowed. To avoid instantiating the emigration propagator for each migration step, we could either instantiate one emigration propagator with the maximum number of emigrants to be sent at once according to the migration topology. However, this again would imply one single selection policy for all islands.
  • Alternatively, we could pass a list of separate emigration propagators from the user script down to the Pollinator.

@mcw92 mcw92 pinned this issue Aug 25, 2023
@mcw92 mcw92 added this to the Propagator rework milestone Aug 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maintenance Improve code readability and robustness.
Projects
None yet
Development

No branches or pull requests

2 participants