* Relation Pool Number: Caution

[dbnut]

I've come to rely heavily on RelationPool() e.g. for heavy-duty splitting trees as well as routine maintenance. Splendid tool.
It's also handy for me to show this value in diagram boxes, and that is how I came to notice a curiosity.

Working in a Pool 1 diagram, I added an extra spouse to one person and found she had no Pool Number displayed. That had happened before, but entering a marriage date or place seemed to fix it.

This time, though, nothing obvious (like opening a new diagram on any related person) seemed to trigger a pool number re-calculation. Closing FH and re-starting did the trick.

Technically, I suppose it is a bug, though not normally significant. But it might be as well to re-open FH before running split tree helper if relying on RelationPool?

[johnmorrisoniom]

When you add a connected or unconnected individual, they are not immediately assigned a pool number. That is only assigned when the data is saved.

[tatewise]

I've added a partner in various ways via the Property Box and using drag in a Diagram, and in every case when running the standard Query Search For Orphans the Relationship Pool number is immediately assigned.

The reverse process of unlinking an individual to create a separate pool also immediately reassigns pool numbers.

However, prior to running the Query the Pool number is missing. I wonder what the Query does to cause the assignment.

[dbnut]

When you add a connected or unconnected individual, they are not immediately assigned a pool number. That is only assigned when the data is saved.

I believe that is incorrect. If you watch a diagram (that displays pool number), drag down to create a child, its pool number appears instantly.

[dbnut]

However, prior to running the Query the Pool number is missing. I wonder what the Query does to cause the assignment.

Not quite sure what you're saying here, but the oddity I mention of failure to update instantly is *very* rare. Probably too rare to make a fuss about - so I won't.

[Gowermick]

Paul,
Not too rare an occurence, I’ve suffered from it too. I just go to another screen and come back, and it has updated itself.

[dbnut]

Paul,
Not too rare an occurence, I’ve suffered from it too. I just go to another screen and come back, and it has updated itself.

Good you discovered that, GM

[David Potter]

Does the FH > Window > Refresh tool not help?

[dbnut]

Never tried, but wouldn't expect so - given that opening a brand-new diagram rooted in any of the participants didn't help.

[redvanman]

Each time an individual or a relationship between two individuals is added or deleted, the pool numbers can potentially change.
I would speculate that because it could take FH an appreciable time (in computer terms) to run through all its relationships to update the pool numbers, it does so in the background, letting the user get on with other work in the meantime.

Alyn

[Gowermick]

Alyn,
Surely if an individual is attached to someone, FH gives it the same pool number. If not, it creates a new one.
There is no need for FH to search for a connections to the rest of the individuals, an indivudual is either linked to someone else or not.
Quite simple in computer terms

[LornaCraig]

Gowermick, it's not always that simple. If the new individual links two previously separate pools one of those pools has to be renumbered. And as far as I know there are never any gaps in pool numbers, so other pools with higher numbers also have to be renumbered. Conversely, if an individual is deleted this may split an existing pool into two or more smaller pools which have to be assigned separate numbers.

Also, in general the largest pool is normally assigned number 1 so any change in relative sizes of the largest few pools may result in them all being renumbered.

[davidf]

Also, in general the largest pool is normally assigned number 1 so any change in relative sizes of the largest few pools may result in them all being renumbered.

I need to watch out for that; I'd always assumed that Pool 1 was the one with the file root in it. On reflection, not sure how I formed that assumption.

I do have a box formatting condition for "if not in pool 1" to gently prompt me that I am dealing with a branch not actually connected to "my line"; I guess I need to rewrite it to be "if not in the pool of the file root individual"

[dbnut]

Does the FH > Window > Refresh tool not help?

Well, David, I should have checked before opening my big mouth. Window > Refresh does exactly what is needed, and I never would have believed that.

Many thanks for the suggestion. Kudos!

[tatewise]

I do have a box formatting condition for "if not in pool 1" to gently prompt me that I am dealing with a branch not actually connected to "my line"; I guess I need to rewrite it to be "if not in the pool of the file root individual"

Why not use a variant of the =IsRelativeOf( FileRoot(), %INDI% ) function?
Instead of FileRoot() it is possible to nominate your own Individual record by Record Id.

[David Potter]

You're Welcome Paul.

[dbnut]

Pathological Pools

Being drawn back to this, just a few more observations...

There are apparently 3 equivalent routes to creating an unrelated individual, all starting out with an "empty" pool number (beginning to learn here).

(1) From the Individual Records window (by right-click in the first (expansion button) column).

(2) From the Individual Records window (or, apparently, any other record-type window), via menu Add > Unrelated Individual (which opens the Focus window).

(3) From "essentially any" starting point, via menu Add > Into a Diagram > New Individual. There are 2 cases:

(a) If that is invoked from the Individual Records window (or, apparently, any other record-type window), then a new (otherwise empty) "Relatives of" diagram is created.

(b) If that is invoked from any Diagram window, then a pop-up dialog asks whether to insert into the current diagram or a new one. If "new", then it behaves as in (a); if "current", then the diagram type does not change.

(4) I haven't checked for any further entry points.

For completeness, there is also the menu to Add > Into a Diagram > New Couple. This has an interesting behaviour described below.

Now...

In all the above cases and variants (and it is interesting to speculate why), the pool number is always blank. That persists during/through:

(i) File > Save
(ii) Adding/editing any Individual events/attributes (via Property window or diagram)
(iii) From the Property window, toolbar blue button "Go to Parent" (the "up" arrow)

That last is where it gets interesting. You can keep adding one parent (M or F), through the generations, all with no pool number despite adding properties.

What is sure to trigger a pool update is anything that sets or implies the sex of some individual in the chain. That is bound to happen through the "Please indicate the sex of..." dialog when creating a spouse or adding a child directly, or adding a link to an existing individual as a child.

That "event" seems to be when an appropriate Family record is created - which, of course, is the only way to provide pool continuity through "marriages".

Looking in the Property window "All" tab, all of the links to parent or child (and, of course, spouse) are empty. However any parent's Record ID & name are shown, even in the absence of a Family ID. The same is true for children (where they also show up in the Main tab).

Coming back to "Add > Into a Diagram > New Couple"... this seems to be the only way of introducing a "ready-made" couple (with no Sex defined for either). The Property window "All" shows spouse ID, again without Family ID.

Well, there is probably more to discover, if anyone can be bothered. For me, it's all a bit "pathological". And, thanks to David Potter, I now know a one-click solution (and several other ways) to trigger pool number updates.

It leaves me unenlightened as to how/why the magic Window > Refresh works (maybe that's in Help).

It leaves me puzzled how I managed to get more "relatedness"/complexity in a group without pool number (maybe I mis-remembered, or maybe there really is a little bug hiding out somewhere).

It leaves me thinking Calico might tighten up "completeness" a bit, e.g.:

Always create a GEDCOM family record in that explicit last example, and the implicit case of creating a parent. That could also apply to creating a child, without the need to specify parent(s) sex. Isn't that a step forward, anyway?

Hope that wasn't too boring!

BTW I am continually irritated that, in a Diagram, there is no "right-click" (context) menu item to add an unrelated individual. Many other operations here are mouse-orientated).

[davidf]

Why not use a variant of the =IsRelativeOf( FileRoot(), %INDI% ) function?
Instead of FileRoot() it is possible to nominate your own Individual record by Record Id.

Hm, I'd always thought that IsRelativeOf would fall at indirect relationships (e.g. is brother of spouse of cousin of stepchild of sister in law's father's first wife's first husband). They would be in the same pool (not so much a family tree as a family shrubbery) - but are they relatives? Bit of experimentation to put on the todo list!

[Gowermick]

Gowermick, it's not always that simple. If the new individual links two previously separate pools one of those pools has to be renumbered. And as far as I know there are never any gaps in pool numbers, so other pools with higher numbers also have to be renumbered. Conversely, if an individual is deleted this may split an existing pool into two or more smaller pools which have to be assigned separate numbers.

Also, in general the largest pool is normally assigned number 1 so any change in relative sizes of the largest few pools may result in them all being renumbered.

Lorna,
I think pool numbers are a recordset of their own, and the recordset will have as many records as there are pools. Removing the lone individual in a pool, makes that pool number redundant (link count drops to zero) so you only have to renumber pool records to fill in the gap, and it will automatically change the pool numbers of all the people linked to those pools.
Sorting a few pool numbers is not the same as searching through 1000’s of individual records ! That was what I was trying to say.

[tatewise]

I have to admit I thought =IsRelativeOf(...) included all indirect relatives via marriage, i.e. in same Pool, but I was wrong.
It is not the same as the Relationship Pool number

[paultt]

Also, in general the largest pool is normally assigned number 1 so any change in relative sizes of the largest few pools may result in them all being renumbered.

I believe the first 'tree' you build in that project is assigned Pool #1. My Pool 1 has 42 indi's ; Pool 2 has over 2000; Pool 3 about 1500; Pool 4 has 107......currently at Pool 18 with 75. These are trees I am building are in a separate project for each of the dna matches I found, and where I find the match and merge the same persons from a different pool, they merge into the lower Pool number.

[LornaCraig]

Paul, yes you are right. The first pool created is number 1, regardless of size. In any project I have created the first pool has always been the largest, so I had previously thought it was done by size. Oddly the FH help file just says "Family Historian calculates how many such pools there are in a given file, and arbitrarily assigns a number to each one" which suggests the pool numbers are random!

[davidf]

I doubt that pool numbers are really random - otherwise we will get some occasional really high pool numbers! I suspect that there is some process to ensure that pool numbers are always a continuous list starting at one. If they were not I suspect plug-in authors would be raising the issue!

Trying to think through how FH may handle this (which is speculation in the absence of a definitive statement from CP), the logic would seem to me to say:

• 1st individual goes into Pool 1
• Next unconnected individual goes into Pool 2, etc,

On splitting a pool (by deletion of a family relationship), one part of the pool has to acquire a new number being the number of pools + 1. The algorithm for choosing which part is renumbered is not that important - could just be the part which has the current focused individual (although that could move the root individual to a new pool).

Pools can "become vacant" due to:

• Linking of two pools (tested at time of linking - then all in the combined pool are re-numbered to the lowest pool) leaving the higher pool number vacant
• Deletion of the final member of a pool (tested at the time of deletion) leaving a pool number vacant

A routine to find vacant pools:

• For all pools (i) from 1 to p
  • check how many members,
  • if not zero
    • repeat for i+1,
  • if vacant
    • renumber p(i+1) to p(i),
• iterate for all p

is relatively simple, and can be triggered by either of the above vacancy creation events rather than being an "occasional background job".

So unless all members of pool 1 are deleted, members of pool 1 can not have their pool renumbered - unless they are split away from it. (If you get what I mean!)

[peterbel]

I read this thread because I knew nothing about Pool Numbers
I can see the usefulness of it and wondered if it was another thing I have overlooked so here it my 'stupid question'.
Is it displayed in any of the standard windows, or does it only get displayed after running certain reports/queries?
Thanks

[tatewise]

Peter, the Relationship Pool number is displayed by the =RelationPool() function in the same way that a Record Id is displayed by the =RecordId() function or the File Root is displayed by the =FileRoot() function.

They can be displayed anywhere that a function can be used in an expression. So they can appear in a Records Window column, a Property Box caption, a Diagram box, a Report item, a Query column, etc.