Move FLOPS data files to test folder

[jkirk5]

Desired capability or behavior.

Right now there are 2 kinds of inputs for FLOPS aircraft: csv files (occasionally), and the data files that create AviaryValues objects for inputs and expected outputs. My proposal is that the models folder should contain only input files, so csvs and maybe a "scripted" input file as an example (but every model should also have a csv). The expected outputs, and the specific way they are stored (a giant dict containing both inputs and outputs) are not user-friendly or set up for easy use in the Aviary L2 api. They were specifically designed for modular testing, so that is the folder they should live in.

So, move all the data files to the validation_cases/validation_data folder and make sure that every model still has a csv representation in models. For example purposes, a "scripted" input file is still useful. The existing format of data file inputs are not well suited. I would prefer a new data file is created so there aren't 2 copies of a scripted input floating around in both model and test folders. That points to perhaps a GASP-originating file being a good candidate for this example. An actual new example should be created to demonstrate how to create an AviaryProblem by loading inputs from memory in this way.

Is your feature request related to a problem? Please describe.

No response

Associated Bug Report

No response

[OwenShepherd]

Trying to understand the core issue here. As an example, is "advanced_single_aisle_data.py" within the models folder intended to be the modern translation of the original FLOPS input data, contained in the CSV? I.e. FLOPS CSV -> translator -> Modern Aviary input (.py) file? Thus your issue is one of both maintaining a single source of truth and a general codebase cleanup?

[cmbenne3]

Trying to understand the core issue here. As an example, is "advanced_single_aisle_data.py" within the models folder intended to be the modern translation of the original FLOPS input data, contained in the CSV? I.e. FLOPS CSV -> translator -> Modern Aviary input (.py) file? Thus your issue is one of both maintaining a single source of truth and a general codebase cleanup?

There is an extra layer of complexity within the repo that I think @jkirk5 wants to manage better to make it easier to maintain the examples. The translator function (fortran_to_aviary) is intended to translate a flops input text file (which is in the format the original FLOPS fortran code expects) into an aviary compatible .csv input file. Aviary then reads in the .csv file and creates the Aviaryvalues dictionary that is the input to the aviary problem.
The modern aviary input .py files bypass this and offer an alternative way to just specify the AviaryValues dictionary directly by coding (variable_name = value, units) in a python script, bypassing the Aviary code that reads and processes the input .csv file.

I think your confusion highlights that we should address this issue (clean up the test cases and example models) to clarify this distinction. Please let me know if you have any further questions, and I'll discus with Jason regarding the priority of this issue.

[OwenShepherd]

After your explanation (thank you) and some more experimentation I understand the input params a bit better. Just for some clarification on this:

Right now there are 2 kinds of inputs for FLOPS aircraft: csv files (occasionally), and the data files that create AviaryValues objects for inputs and expected outputs.

By "data files that create AviaryValues objects", @jkirk5 is referring to a file such as the level 3 example py file, correct?

[cmbenne3]

By "data files that create AviaryValues objects", @jkirk5 is referring to a file such as the level 3 example py file, correct?

Not quite - the files that @jkirk is referring to are those such as advanced_single_aisle_data.py
(which is the bypass version of advanced_single_aisle_FLOPS.csv

These .py files also contain the 'results' which we use for our unit tests and were never really meant to be 'example aircraft' for users, and so we plan to move these inside 'test' so they are hidden away.

The run_level3_example.py is a different file altogether that is intended to expose the inner workings of Aviary, specifically the interactions with OpenMDAO and Dymos, in a single script. You may have noticed that this example runs the 'advanced_single_aisle' model (loaded from the .csv file), and should return the same results as the run_level2_example.py and run_level1_example.py.

Hope this makes sense.

[jkirk5]

Hopefully I can further clarify! This issue was written to capture a dev discussion and was written for that audience (most of our internally created issues are like that), so I didn't go into any detail about which specific files.

I am solely talking about files located inside aviary/models. Like @cmbenne3 mentioned, there are often 2 files representing the same aircraft, but the data is formatted in different ways. The csv files are intended to be the example models for users to use and are (hopefully) easy to understand. The python script data files were created solely to help automate testing the code, and were never intended to be user-facing. Not to say users can't use them, just that they weren't designed for that purpose and have some additional scripting, processing, and also contain output values, so you have to know exactly how to interact with those files to get whatever you need out of them. They aren't standardized or intended to represent a recommended way to script input files, so I want to move those out of folders we direct users to in documentation to avoid confusion.

TL:DR: This issue is just suggesting moving some files that were only intended used for testing into the testing-related folders for better organization. No change in functionality or availability of data available to users

[OwenShepherd]

Thank you both for the clarification. With that information, I assume if I'm looking at aviary/models/aircraft/advaned_single_aisle/, the CSV is intended to be a translation of the input txt for the original FLOPS code, created with the fortran_to_aviary function?

[cmbenne3]

That's correct - I believe the advanced_single_aisle_FLOPS.csv was made by converting the N3CC_generic_low_speed_polars_FLOPS.txt original FLOPS input file using the fortran_to_aviary function.