Fuel Variable Accounting - Issue 1012#1027
Conversation
…esents extra wing tank volume, not the fuel in the aircraft. Removed FUEL_MASS_REQUIRED and FUEL_MASS from variable_meta_data and as they were internal variables to GASP fuel tank sizing and were not needed by any other processes. They are now local variables in fuel.py fuel_mass_reqired and fuel_mass. Removed VOLUME_MARGIN for calculation of Mission.Summary.TOTAL_FUEL_MASS, the latter is now only made up of FUEL_BURNED + RESERVE_FUEL. Changed name of RESERVE_FUEL_FRACTION to RESERVE_FUEL_MARGIN and changed it from fraction to percentage. Changes across the rest of the repo are not yet complete.
…l.FUEL_MASS and Aircraft.Fuel.FUEL_MASS_REQUIRED. These varaibles have been removed from the variable hirearchy already and are no longer accessible for asserts.`
…no longer needed as input
… reserves. Attempted to leave it as 22.22 but this was importing as 22.220000000000002 so switchied it to 22.2
…em is using CS derivatives meaning we cant also check the results using CS derivatives, we have to use a different method
…in pre-mission. added in reference to fuel.ipynb to reference fuel mass calc page
… mass not design gross mass
…ling initial mass value from Mission.Summary.GROSS_MASS. In the past we only did this sometimes and only when takeoff=true, in other cases we pulled from the first point of the first phase.
… pep8 in internal assignments and calcs in aviary_group
| ) | ||
| if RESERVE_FUEL_FRACTION != 0: | ||
| if reserve_fuel_margin != 0: | ||
| # Originally tried to reference Mission.Summary.FUEL_BURNED for fuel burn but in some tests this led to errors |
There was a problem hiding this comment.
Which tests, and what error? I'm guessing that happens because 95% of tests don't run a mission, so FUEL_BURNED simply never gets calculated
There was a problem hiding this comment.
I think this was more of a note to myself that when I tried to use Mission.Summary.FUEL_BURNED instead of (initial_mass - final_mass), some tests broke. I'm hoping I can revise how the fuel-burn is calculated in my follow-on PR.
| outputs.set_val(Mission.Summary.USEFUL_LOAD, 5100, 'lbm') | ||
| outputs.set_val(Aircraft.Design.TOTAL_WETTED_AREA, 7956.515738, 'ft**2') | ||
| outputs.set_val(Mission.Summary.ZERO_FUEL_MASS, 103442.0, 'lbm') | ||
| outputs.set_val(Mission.Summary.FUEL_MASS, 26292.0, 'lbm') |
There was a problem hiding this comment.
Should this be changed to FUEL_BURNED? This prevents us from checking the mission fuel in tests
There was a problem hiding this comment.
Mission.Summary.FUEL_MASS is no longer calculated by aviary. It's one of those masses that we removed because it was just internal to a GASP calculation. Now that's it's an internal variable we could potentially check it by reaching into that subsystem and examining it's local assignment. But again, this is just meant to size the fuel tanks and fuel systems and never represented the actual fuel going onto the system.
4 participants
Summary
This PR includes a revamp and simplification of fuel mass variables to prevent users from incorrectly selecting variables that don't actually represent mission fuel burn. This included fixes to GASP to Aviary file conversion. As well as an additional doc page on how fuel is summed up. Also fixed some reports that were showing incorrect fuel burn values when takeoff was enabled.
Details
Name and Reference Changes
Renamed for clarity
Mission.fuel.FUEL_MARGIN->Mission.Fuel.VOLUME_MARGINthis is a fuel margin and has little to do with fuel massAircraft.Design.RESERVE_FUEL_FRACTION->Aircraft.Design.RESERVE_FUEL_MARGINwe are tracking this as a % nowRemoved from aviary variable hierarchy because they were internal variables in GASP and did not need to be set by the user:
Mission.Summary.FUEL_MASSMission.Summary.FUEL_MASS_REQUIREDUpdated OAS builder tests to refer to
Aircraft.Fuel.WING_FUEL_CAPACITYrather thanMission.Summary.FUEL_MASSwhich was the mass of ALL fuel for the mission including in the fuselage and aux tanks!!The initial mass used to calculate
Mission.Summary.FUEL_BURNEDis now alwaysMission.Summary.GROSS_MASSwhereas before it was sometimes this and sometimes the first point in the first dymos phase.Calculations Updates
Changed the way
Mission.Summary.TOTAL_FUEL_MASSis calculated to remove incorrect addition ofMission.fuel.FUEL_MARGIN.Updates to GASP to Aviary conversion factors
INGASP.FVOL_MRG ->
Mission.Fuel.VOLUME_MARGINDepending on the value for
FRESF:INGASP.FRESF ->
Aircraft.Design.RESERVE_FUEL_ADDITIONALINGASP.FRESF ->
Aircraft.Design.RESERVE_FUEL_MARGINTest updates
A number of
FRESFvalues were listed as small numbers (0.15 to 0.22) and were being converted toRESERVE_FUEL_ADDITIONALin lbm. However, with the updates toVOLUME_MARGIN, this caused some BWB missions to stop converging so we modified the source .dat and .csv files for those examples toFRESF = -.1which kept the gross mass of the concept the same as the test values.reserve_fuel_margin_masscalculation was updated to not useMission.Landing.TOUCHDOWN_MASSsince that is only calculated if Landing=True. This was swapped with the typical way of calculating fuel-burn by taking final mass - initial miss.A number of tests had ridiculously small tolerances (1e-9) that were being violated. These were relaxed to 1e-8.
The multi-mission test needed a few more iterations to converge with the change in
Mission.Summary.FUEL_BURNEDcalculations so I bumped the iterations from 75 to 150.Report updates
The reports for mass summation from pre-mission located in mass_builder.py were changed to display
Mission.Summary.GROSS_MASSrather than design gross mass. This was important because all the values in that section were mission specific aircraft details.Fuel reports in
reports.pywere updated to properly include fuel burned in takeoff, which was not correctly being added wheninclude_takeoff=True. This was done by referencingmission:summary:fuel_burneddirectly instead of trying to calculate initial mass - final mass again.Related Issues
Backwards incompatibilities
None
New Dependencies
None