Jason Kirk
Jason Kirk
When this component gets updated, if only a few tests break we can update their expected values. If a significant number of tests break, we have a couple options we...
This has been set as a high priority because it prevents us from considering new default values for Aviary, which is a longstanding topic we haven't been able to address...
Seems like this issue has been addressed
This can get started with a simple docs page that has a manual list of required inputs for our built-in Aviary components, which could be later expanded into a utility...
I have a strong preference for `ground_distance` for a couple reasons. Range and distance are definitely distinct concepts that sometimes (but not always) overlap. Range is always discussed in the...
From @erikdolsonva: Problem.model_options can be used to set options at the problem level and have them automatically filter down to any component that needs them. This feature could be used...
This should be investigated further - also need to consider if we want to use `NamedValues` instead of `AviaryValues` to ensure compatibility with variables not in the hierarchy (I believe...
IMO unifying variable names should be sufficient for now. I'd like to keep the Aviary hierarchy as clean as possible with intermediate computations only added if they are commonly needed...
Further investigation of this issue is requested to help set priority
Need investigation on if we would like to pursue this implementation (either picking a single version of the EOM to use, or switching between current and new implementation as needed...