Allow components to call for creation of sub components #445
Conversation
Note that components still aren't setting up any permissions, so there would be runtime errors when executing the transform methods. Furthermore, there are some missing methods I realise I need for GuardedOptions. The unit tests are also failing to compile, although I don't understand what the problem is for them, yet.
Also need to revert a bunch of changes from Options::isSet(std::string) to IS_SET, to avoid creating objects we don't need.
All unit and integration tests pass, but many components are untested. There may be errors in their permissions.
Also added an additional constructor for SpeciesInfo
cmacmackin
force-pushed
the
cmacmackin/create_sub_components
branch
from
00a27c5 to
1d0d823
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #445 +/- ##
==========================================
+ Coverage 26.41% 30.70% +4.28%
==========================================
Files 90 95 +5
Lines 8105 8934 +829
Branches 1133 1262 +129
==========================================
+ Hits 2141 2743 +602
- Misses 5745 5917 +172
- Partials 219 274 +55 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
- Unused arguments in some of the functions for GuardedOptions - Unit tests expecting an exception to be thrown, but this only happens when checking is done.
Note that components still aren't setting up any permissions, so there would be runtime errors when executing the transform methods. Furthermore, there are some missing methods I realise I need for GuardedOptions. The unit tests are also failing to compile, although I don't understand what the problem is for them, yet.
cmacmackin
force-pushed
the
cmacmackin/create_sub_components
branch
from
1d0d823 to
736052b
Compare
|
The I've tried rewriting it slightly so that it will go back to using the order in the input file as its starting point for topological sorting. This makes the test pass, but I'm still concerned by what I'm seeing. It would appear that the permission information I am currently specifying on some components is not adequate to guarantee the same result. Perhaps something hasn't been marked as the final-write that should be. I note that this is the only integration test which has had this problem; all the others worked fine even with a radical reordering of the components. That might give us something to go on. |
|
Here is the order the components are executed when I get the error described above:
@mikekryjak, @bendudson is there anything in this ordering that stands out to you as wrong? |
|
Hi @cmacmackin ! |
|
@bendudson Edit: This is for the integration test |
This PR adds a virtual method to Component classes which lists the names and types of additional components which they might need. This information is used by the ComponentScheduler class to create these additional components automatically. Users can override default values for the configurations of these additional components by adding a named section to their config file, as usual. A
BraginskiiClosurecomponent has been added, which does nothing except call for the creation of all the other Braginskii components.Closes #386