Enable different boundary conditions for different fields on different boundaries#6970
Enable different boundary conditions for different fields on different boundaries#6970anne-glerum wants to merge 31 commits into
Conversation
| get_fixed_fields_on_boundary (const types::boundary_id boundary_id) const; | ||
|
|
||
| std::set<types::boundary_id> | ||
| get_fixed_boundaries_for_field (const unsigned int compositional_field) const; |
There was a problem hiding this comment.
We often use "prescribed" instead of "fixed" I think. Think about which one makes more sense?
There was a problem hiding this comment.
I like prescribed more, but in the prm file and in the original plugin interface, fixed is used, e.g. Fixed composition boundary indicators and fixed_composition_boundary_indicators, so I stuck with that.
9ee13ea to
d4660ba
Compare
|
Hi @gassmoeller, before I continue with this PR, I'd like your input. Does the PR go in the right direction? If so, what is specifically bothering me is:
|
|
After discussing with @gassmoeller, I have updated the input format. In addition, all the boundary composition plugins now take into account how many compositional fields they are supposed to prescribe on each boundary (a test is added for each changed plugin). The only allowed operator for the new format is still I think this is now ready for review. I have one question though: What to do with the old old input parameter EDIT: it seems I broke something today, let me fix that first. |
|
/rebuild |
20ea6d1 to
6d6e9e2
Compare
6d6e9e2 to
2e09539
Compare
|
Okay @gassmoeller, this is now ready for review. |
To address #1560. No need to look yet, I just want to see what the testers say.
Notes to self:
addis only option allowed in new formatFor all pull requests:
For new features/models or changes of existing features: