Since the first thing that was agreed to is that there would be the ability to deal parts that does not require an implementation to do things via sets (reverse classification), I sure hope we are not getting this issue confused again. As discussed in some technical detail at the boot camp, there are two high level approaches one based on classification (no use of sets) and reverse classification (what sets do well). All the SCOREC tools that are being used for parallel adaptive simulations, and (in the past) for parallel mesh generation, are based on a classification approach. Onkar Sahni wrote:
So again, I go back to asking: what are the core needs that prevent us from using sets as both parts and partitions? The entity set mechanism was designed with this specific usage in mind.
If "sets as both parts and partitions" mean using entity-sets then we have already discussed this in great detail. I think the question in discussion is irrespective of how one implements parts and partitions? If I understood the question right then we need to answer queries which involve a specific part and a specific entity-set (where entity-set may span more than one part, may be local to a process). Now, if it is implied that choosing entity-sets for both parts and partitions allows to use set operations (booleans), outside the interface explicitly by applications, to answer such queries well then applications might as well do it in other equivalent ways (for example, loop over entities in set and ask residence parts to get entities in the entity-sey belonging to a specific part).
- Onkar