remap_subdomain_ids capability in stitch_meshes #3613
Conversation
roystgnr
force-pushed
the
remap_subdomain_ids
branch
from
81303ec to
28631dc
Compare
|
Job Coverage on ce4b2e1 wanted to post the following: Coverage
Warnings
This comment will be updated on new commits. |
||||||||||||||||||||||||||
|
Well this is looking nice so far. CI only has the 14 failures I could reproduce locally, and 13 of those failures turn out to be due to a bug in this PR. If I can figure out the 14th then we're in business. |
libMesh stitch_meshes is going to start handling MOOSE "subdomain names are first-class objects, ids might be just autogenerated" behavior safely, in addition to the old libMesh "subdomain ids are first-class objects, names are just expected to be matching" behavior. But in between those categories of case is "one submesh may be treating names as first-class objects, another submesh has a matching id without any name", and we can't figure out any safe thing to do there, so by default now we'll scream and die when we see it. So we definitely don't want to see it in CI. This is all in service of catching bugs like in idaholab#25070, via libMesh/libmesh#3613
roystgnr
force-pushed
the
remap_subdomain_ids
branch
from
28631dc to
16d3119
Compare
|
Two steps forward, one step back. But those are more than just "we renumbered subdomain ids" exodiffs; in dbg mode we're actually exceeding max subdomain_id_type somehow... looks like that's a test I need to be doing in opt too, whatever the resolution is. |
Okay, no "somehow" about it. idaholab/moose#19950 is the culprit. Pinging @shikhar413 - is there any way we can just stop using hard coded subdomain ids, and instead get auto allocated ids for these sorts of purposes? There's just not a big enough namespace for every mesh generator to pick its own magic numbers and pray there will be no conflicts. |
|
Possibly, I remember there was a lot of contention over this with @GiudGiud when we were originally developing this capability since we wanted a way to be able to tag elements with a unique subdomain ID to reference where they were in the mesh later on in |
In the long run we need to be using subdomain names here, from the nice big ~50^32 sized namespace available there, not picking from 2^16 ids and hoping to avoid conflicts. In the short run, this at least gives us a little breathing room in between the hard-coded ids and the default maximum subdomain_id_type value, so we can autogenerate subsequent ids safely. I regenerated the gold exodus files by manually search-and-replacing saved ids in ncdump output, then ncgen'ing the result, to make sure there weren't any unwanted changes inadvertently slipped in. Refs idaholab#19950 This isn't quite enough to make MOOSE compatible with libMesh/libmesh#3613 but it fixes most of the conflicts for me.
libMesh stitch_meshes is going to start handling MOOSE "subdomain names are first-class objects, ids might be just autogenerated" behavior safely, in addition to the old libMesh "subdomain ids are first-class objects, names are just expected to be matching" behavior. But in between those categories of case is "one submesh may be treating names as first-class objects, another submesh has a matching id without any name", and we can't figure out any safe thing to do there, so by default now we'll scream and die when we see it. So we definitely don't want to see it in CI. This is all in service of catching bugs like in idaholab#25070, via libMesh/libmesh#3613
In the long run we need to be using subdomain names here, from the nice big ~50^32 sized namespace available there, not picking from 2^16 ids and hoping to avoid conflicts. In the short run, this at least gives us a little breathing room in between the hard-coded ids and the default maximum subdomain_id_type value, so we can autogenerate subsequent ids safely. I regenerated the gold exodus files by manually search-and-replacing saved ids in ncdump output, then ncgen'ing the result, to make sure there weren't any unwanted changes inadvertently slipped in. Refs idaholab#19950 This isn't quite enough to make MOOSE compatible with libMesh/libmesh#3613 but it fixes most of the conflicts for me.
I'm going to try to default it to "true", on the theory that if we don't see a lot of CI failures then this will be a cheap feature to enable by default, whereas if we do see a lot of CI failures then this will be an important feature to enable by default.
There are still a couple reactor module tests in MOOSE that are failing with it true, so we'll need to experiment from that end a bit.
roystgnr
force-pushed
the
remap_subdomain_ids
branch
from
5aaa390 to
ce4b2e1
Compare
I somehow missed getting this commit into libMesh#3613
I'm going to try to default it to "true", on the theory that if we don't see a lot of CI failures then this will be a cheap feature to enable by default whereas if we do see a lot of CI failures then this will be an important feature to enable by default.
This catches the failure cases in idaholab/moose#25070 for me. Shame that it also catches cases in MOOSE for me; I'm going to let it rip here to see what the full CI damage is.