-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rework Material Data Structures #109
Conversation
… arbitrary ManagedGroup. Allocated material data off of CellBlockSubRegions.
8502a99
to
0bf1890
Compare
…directly to a ManagedGroup
… at the top level constitutive relation level
…accessor for constitutive models
…Manager::ApplyBC functions with a single function
… old unused files
@klevzoff can you update the single phase flow solver to use the auto-generated fields from the materials, and update single phase flow solver inputs to evaluate? |
{ | ||
dataRepository::ManagedGroup const * const | ||
constitutiveRelation = constitutiveGroup->GetGroup(matIndex); | ||
accessor[kReg][kSubReg][matIndex].set(constitutiveRelation->getReference<VIEWTYPE>(viewName)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here matIndex
is determined by relative ordering of constitutive models in a (sub)region. Does that mean the material index for the same model (e.g. water) can be different between (sub)regions? If so, I can't use this accessor in a solver, since I can't reliably figure out the material index of interest (or I'd have to search for it in every (sub)region whenever I use it). I'd rather grab the field view wrapper directly by its name using the defined naming convention modelName + "_" + fieldName
, since modelName
is something the solver will know (provided via input).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@klevzoff good point. i can fix the accessor to enforce constant index across all regions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rrsettgast I also just realized, the accessor will likely carry a lot of null pointers wrapped as references. E.g. if I have a fluid model with "fluidDensity" field and a solid model with a "porosity" field, and I request a material accessor for "fluidDensity", which the second model does not have, but it will still be extracted as a nullptr. I'm not going to access that null reference, but the very fact that it exists seems like a trouble waiting to happen. Or technically it's UB i guess.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I suspected, in debug mode this throws SIGSEGV when trying to dereference a nullptr, even though I'm never using the returned reference
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@klevzoff for what problem does this SIGSEGV?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rrsettgast this was before your commit 3451419
I was working on some changes in parallel (which are now merged with yours and pushed), this particular line was segfaulting on any 2-material test. I don't know if still does, because since today's updates I'm getting errors from ChaiVector (munmap_chunk(): invalid pointer
and SIGABRT) during ManagedGroup::Initialize()
, so I can't run anything atm. I'll try to debug and document it separately.
…the entire problem to enforce consistent indexing across regions
…imple pore compressibility model from single phase fluid model.
…what material is the fluid
@klevzoff It looks like you are doing some rework of the actual constitutive hierarchy...not that there is much of a hierarchy to start with. We should do the actual rework of the constitutive class hierarchy in another PR after this. This really became a PR centered around the interface to the material data, and the application of boundary conditions. |
…alViewAccessor. fixed test file
@klevzoff when you move or rename a file, please do a "git mv". https://stackoverflow.com/questions/2641146/handling-file-renames-in-git |
@rrsettgast The hierarchy change was just a way to test having two meaningful constitutive models (i.e. such that both are actually used by the solver). The main change was about how the solver interacts with the models: it's now actually making use of the state update function, rather than just extracting the state data and operating it manually. |
@rrsettgast noted. The IDE is supposed to take care of using appropriate git commands when I do automated refactoring (such as renaming a class), but it seems to miss sometimes. |
@klevzoff |
…ize mixed zones properly
@klevzoff never mind about the rebase. I can't do it. The histories are too divergent to get a successful rebase. |
@rrsettgast I'm getting SIGESGV from here (when running
At a first glance, seems to be nothing wrong with data that goes in. I can't see into silo functions though. Anyway, if you merge |
…into feature/multiMaterial
resolves #63 |
resolves #80 |
No description provided.