Methods for level 2 revamp part 1. #651
Conversation
…thods_for_level_2 __init__() and load_inputs() functions. Enums was updated to have a custom input for the problem builder, elements inside load_inpus() were rearranged to simplify the number of additional functions per builder to be only 2. These consist of an initial guesses and defaults function, and a default location to check for phase_info if none is provided.
| f'When using "settings:equations_of_motion,custom", a problem_builder must be specified in load_inputs().') | ||
| else: | ||
| raise ValueError( | ||
| f'settings:equations_of_motion must be one of: height_energy, 2DOF, or custom') |
There was a problem hiding this comment.
SOLVED_2DOF should be added here per line 136
| @@ -551,7 +297,8 @@ def check_and_preprocess_inputs(self): | |||
| elif mission_method is TWO_DEGREES_OF_FREEDOM: | |||
There was a problem hiding this comment.
I don't like that we are setting defaults for the different ODEs in methods4L2. I feel like these should be moved to the individual builders which decreases the number of different locations that a new ODE needs to inject information.
There was a problem hiding this comment.
Yeah, this is one of the areas that is still pretty messy. It makes me wonder if we should move all of the core pre-mission builder setup into the problem builders. Concepts of FLOPS and GASP maybe shouldn't exist at this level.
| # The rest of the phases includes all Height Energy method phases | ||
| # and any 2DOF phases that don't fall into the naming patterns | ||
| # above. | ||
| input_initial = False |
There was a problem hiding this comment.
consolidate with line 139 which also sets input_initial
There was a problem hiding this comment.
Consolidated into input_initial = phase_idx > 0
| elif phase_name == 'descent': # TODO: generalize this logic for all phases | ||
| phase.set_time_options( | ||
| fix_initial=False, fix_duration=False, units=time_units, | ||
| duration_bounds=user_options.get_val("duration_bounds", time_units), |
There was a problem hiding this comment.
The only difference between this elif and the code before it is that if the phase_name is 'descent' then fix_duration is set to False, no matter what the user input. That is a check that should be happening on the phase inputs, not here. That would allow us to delete lines 158 through 165.
Honestly a bit strange to me that we specifically need fix_duration = False in descent.
There was a problem hiding this comment.
Yeah, that is strange too, plus it is the only example where we have to adhere to a naming convention in HE. It looks like fix_duration is always false in our phase_infos, and the ones in MBSAE. If the user sets target_duration in a phase, then fix_duration is automatically set to True (we have so much interaction between these attributes), but in those cases, the phase is named something like "reserve_hold" instead of "descent". I am going to remove this "if" branch and see what happens.
| fix_initial=fix_initial, fix_duration=fix_duration, units=time_units, | ||
| duration_bounds=user_options.get_val("duration_bounds", time_units), | ||
| duration_ref=user_options.get_val("duration_ref", time_units), | ||
| initial_ref=initial_ref, |
There was a problem hiding this comment.
why are we not applying the initial_bounds that the user supplied here??
There was a problem hiding this comment.
It is potentially an oversight. We should treat initial_bounds just like initial_ref -- none unless mpi.
…gine_deck() when no deck is supplied into each of the 3 different builders.
…roblem_builders. left all objective calcs in m4l2 because even if your running shooting, they could be useful and don\t have a large computational cost
…ary into phase_info_revamp
… be calculated no matter the problem. placed them in the add_objective() definition for eas of finding them in the future
…nto builders2, removed extra line
…ing probably isnt quite right in there. alternative_mission was calling mass_methods based on ODE, but add_post_mission_systems was calling based on mass_method!!
Summary
mission_method.This is a first pass at some refactoring that will allow for more customization.
Related Issues
Backwards incompatibilities
None
New Dependencies
None