Desired capability or behavior.
I have debugged a few different Aviary models where options were not getting set to the values requested in the csv file. It turned out that they weren't set because they were user-added options in the Extended Metadata, but the aviary problem/model only had access to the default metadata. In these cases, the user forgot to pass their extended metadata dictionary into the AviaryProblem constructor.
Suggested implementation.
At the end of setup, we could loop over our external subsystems and search for any aircraft:* or mission:* variables and options that aren't in the aviary group's metadata, and raise an error.
Alternatively, we could raise an error if the csv file encounters an aircraft:* or mission:* key that isn't in prob.metdata while it is looping in set_input_defaults or model_options. This would be easier to implement, but it would miss vars/options that aren't in the csv (though, in theory those wouldn't matter).
Desired capability or behavior.
I have debugged a few different Aviary models where options were not getting set to the values requested in the csv file. It turned out that they weren't set because they were user-added options in the Extended Metadata, but the aviary problem/model only had access to the default metadata. In these cases, the user forgot to pass their extended metadata dictionary into the AviaryProblem constructor.
Suggested implementation.
At the end of setup, we could loop over our external subsystems and search for any aircraft:* or mission:* variables and options that aren't in the aviary group's metadata, and raise an error.
Alternatively, we could raise an error if the csv file encounters an aircraft:* or mission:* key that isn't in prob.metdata while it is looping in set_input_defaults or model_options. This would be easier to implement, but it would miss vars/options that aren't in the csv (though, in theory those wouldn't matter).