As subobject groups are kept in separate fields, they have a link back to their owning group field and have independent access counts.
If the owning group field is destroyed (last deaccess called) then a limbo situation occurs with the still-existing subobjectt group pointing to the former owner field in the destroyed list.
If change caching is on and another same-named group is created and the existing subobject groups discovered by getFieldElementGroup/getFieldNodeGroup behaviour, then the owner group pointer is cleared when the original owner group is finally cleaned up, which will eventually cause a crash with certain group API.
Expectation is that if a field is destroyed it instantly relinquishes its holds on other resources, particularly these subobject groups so they remove their pointer to the owner group.
At the same time there are inconsistencies in the way get/create FieldElementGroup and SubregionGroup work.
Plan is for get() to find any subregion or subobject group of the appropriate name and keeping its current contents, and for create() to only create a new empty field if non exists.
This behaviour is consistent with my intention to make have a single FieldGroup object so there's no such thing as FieldElementGroup or FieldNodeGroup objects; these would just be the MeshGroup and NodesetGroup domains held privately in the FieldGroup. This reduces the number of fields and eliminates a lot of pain when coordinating subobject groups such as adding/removing faces/lines/nodes, and eliminates the issue that independent element/node groups cannot be serialised.
As subobject groups are kept in separate fields, they have a link back to their owning group field and have independent access counts. If the owning group field is destroyed (last deaccess called) then a limbo situation occurs with the still-existing subobjectt group pointing to the former owner field in the destroyed list. If change caching is on and another same-named group is created and the existing subobject groups discovered by getFieldElementGroup/getFieldNodeGroup behaviour, then the owner group pointer is cleared when the original owner group is finally cleaned up, which will eventually cause a crash with certain group API. Expectation is that if a field is destroyed it instantly relinquishes its holds on other resources, particularly these subobject groups so they remove their pointer to the owner group.
At the same time there are inconsistencies in the way get/create FieldElementGroup and SubregionGroup work. Plan is for get() to find any subregion or subobject group of the appropriate name and keeping its current contents, and for create() to only create a new empty field if non exists. This behaviour is consistent with my intention to make have a single FieldGroup object so there's no such thing as FieldElementGroup or FieldNodeGroup objects; these would just be the MeshGroup and NodesetGroup domains held privately in the FieldGroup. This reduces the number of fields and eliminates a lot of pain when coordinating subobject groups such as adding/removing faces/lines/nodes, and eliminates the issue that independent element/node groups cannot be serialised.