Pagmo2 user-defined selection and replacement policies how to convey island of origin?

[montanaviking]

I am using the C++ Pagmo2 ver 2.19 optimization library and I need to define a custom i.e. user-defined selection and replacement policies.
My topology is a linear string of island, one island per frequency point, and I want to migrate the optimum values from the two adjacent frequency points (islands) to the island of concern.
Suppose the frequency points in GHz are: 2,3,4,5,6 and I want to perform a migration. For the selection policy I wish to select the two (or more) best members of the population of the island, i.e. pagmo::individuals_group_t, which have the two (or more) lower or optimum values of their objective functions.
My question concerns the replacement policy on the island receiving the migrants.
Namely, I would like the replacement policy to form the average of the best migrants from both adjacent islands replace a member of the population of the receiving island.
For instance, the 4GHz island (island with parameters at 4GHz) will replace one if its individuals with the average of the best individuals from adjacent islands.
My question is:
Is there any way to know the island where migrants come from? In my UDSP (user-defined selection policy) can I design my method:
pagmo::individuals_group_t select(const pagmo::individuals_group_t &inds, const pagmo::vector_double::size_type &nx,
const pagmo::vector_double::size_type &nix, const pagmo::vector_double::size_type &nobj,
const pagmo::vector_double::size_type &nec, const pagmo::vector_double::size_type &nic,
const pagmo::vector_double &constrainttol) const;
to produce a return (selected individuals) which have IDs indicating the island of origin? Can I also set IDs of multiple individuals of those returned by select() to be the same, say the value of frequency associated with the island?
If so, I could design the replacement policy on the other end, to act on the ID's of incoming migrants and my UDRP (user-defined replacement policy) would be aware of the island of origin for the incoming migrants and could apply replacement according to this information.
Is this possible or is there a better way for replacement policy to know the island of origin for incoming migrants?
Thanks and best,
Phil

[montanaviking]

To clarify, my question is: Can I use the individuals' IDs (type pagmo::individuals_group_t) in outgoing migrants to indicate the island of origin. In this case, I would define UDSP (user-defined selection policy) which 1. passes in a pointer to the calling island and 2. sets the outgoing migrants' IDs all to a number which identifies the island with information from the island pointer.
Would this work? Could I set outgoing migrants' (type pagmo::individuals_group_t) IDs (type std::vector) to all one value and is this safe to do so?

Basically, I want my UDRP (user-defined replacement policy) to be able to detect the last island each migrant came from so it can act accordingly, and I propose to do this via the migrant's ID number.
Is there a better way?
Thanks,
Phil

[darioizzo]

I am not 100% sure I understand your exact question, but it seems to me you want to make some decision based on the past migration path taken by individuals (e.g. where did a certain individual originate from).

Inspecting the global migration log (https://esa.github.io/pygmo2/archipelago.html#pygmo.archipelago.get_migration_log) of the archipealgo would maybe provide an answer and inform your decisions?

[montanaviking]

Hi Darioizzo,
Yes, that's correct. For instance, if islands are operating on parameters which vary with, say frequency, and I know that the solution should vary slowly between frequency points, then I might want to migrate between adjacent frequency points. If I want to treat the migration differently depending on whether the dv (decision vector) came from the previous or following frequency point, then I would want the replacement policy end to know the island of origin (in our example one island/frequency point). I have since experimented and it appears that I can do this by setting the outgoing migrants' ID to the frequency or another ID unique to the source island in the island's selection policy to indicate the island of origin. On the replacement (incoming migrant) end, I was able to read the ID and determine the island of origin, using the IDE (in my case Qtcreator) debugger. I don't think this method will have undesired side-effects would it?
Basically to sum it up the following appears to work -> hoping there are no side-effects:

1. In the selection policy: Set the selected migrants' IDs to the island's ID number (in my case, the island's frequency point in Hz). Note that all selected migrants, emitted from a particular island, will have the same ID which implies that multiple migrants share the same ID numbers.
2. In the replacement policy, determine migrants' island of origin using their ID numbers, and act on this as desired.
   Hoping that there are no unexpected effects of setting the migrants' ID numbers in the selection policy?

Thanks again Dariozzo for your hard work on Pagmo2 on our behalf!
Phil

[darioizzo]

side effect will be that the migration log will no longer allow to track the full individual migration history. but if you do not care, it should work. I still do not understand why not using the migration log directly though.

[montanaviking]

Hi Dario, Thanks for your post. That makes sense. I will look into using the full migration history as this sounds like the right way to go. My method was the first thing I thought of. Thanks again, Phil

…

On Wed, Nov 22, 2023 at 10:33 AM Dario Izzo ***@***.***> wrote: side effect will be that the migration log will no longer allow to track the full individual migration history. but if you do not care, it should work. I still do not understand why not using the migration log directly though. — Reply to this email directly, view it on GitHub <#558 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5GXWUPHLAFWRWT3AAWW3DYFYZOVAVCNFSM6AAAAAA6TLKTUCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TMNBUHEYDK> . You are receiving this because you authored the thread.Message ID: ***@***.***>