aerodynamics_2_graphviz

[yanzixiang]

#1125

[seanmcleod]

Where the description of what you're trying to achieve with this pull request?

[seanmcleod]

Ah, I see you have a link to an issue, I missed that, I was looking for some explanation and a single blue link with a number wasn't obvious to me initially.

[bcoconni]

Hmm… The purpose of JSBSim is certainly not to support every output file format under the sun:

• Output data can currently be directed to a CSV file or a network socket and from there utilities can be written to convert these formats to whatever a user needs.
• XML data can be converted to other formats as well. There are Python libraries that can read XML and produce graphviz files or similar things. As @seanmcleod has explained in aerodynamics_2_graphviz #1125 there are already similar utilities such as https://github.com/NikolaiVChr/jsb-to-png and I don't see why this one should be part of the JSBSim project.

So this PR will increase the maintenance burden with no, or very few, added value in return. And, unless someone explains me that I've completely missed the purpose of this PR, I'm downvoting it and suggesting to close it.

[seanmcleod]

Yep, I guess I see 2 questions/issues.

Do we want to include a specific utility tool in the repo or not. For example at the moment we only have a single one, Aeromatic++.

Then secondly, is the tool standalone, i.e. simply reads FDM XML files, uses C++/Python API or does it require a number of source code changes specifically for the tool in the core JSBSim source code?

[agodemar]

@seanmcleod @bcoconni I see this as an additional utility. It should not be part of the JSBSim codebase.

[yanzixiang]

Yep, I guess I see 2 questions/issues.

Do we want to include a specific utility tool in the repo or not. For example at the moment we only have a single one, Aeromatic++.

Then secondly, is the tool standalone, i.e. simply reads FDM XML files, uses C++/Python API or does it require a number of source code changes specifically for the tool in the core JSBSim source code?

I see this as an additional utility. It should not be part of the JSBSim codebase.

@agodemar @bcoconni @seanmcleod

ok,i know that, maybe i should use python to read the FDM XML files by myself, and write write the dot file by myself,
and DO NOT touch the code of JSBSim.
just as i said, jsbsim sames have NOT export this kind of information out,
because of jsbsim DO NOT want to do this kind of work.

[agodemar]

@agodemar @bcoconni @seanmcleod

ok,i know that, maybe i should use python to read the FDM XML files by myself, and write write the dot file by myself, and DO NOT touch the code of JSBSim. just as i said, jsbsim sames have NOT export this kind of information out, because of jsbsim DO NOT want to do this kind of work.

@yanzixiang as you see, JSBSim as a software library has a clear purpose: being a physical-mathematical kernel for engineering flight simulations. The feature you propose is handy and volunteer work in this direction is welcome. Yet, it comes into play when the analysts want to pre- or post-process their FDM data.

I don't think "JSBSim DO NOT want to do this work." On the contrary, this work should be kept in a proper place and should nicely cope with the general purpose of the core software library.

[seanmcleod]

@yanzixiang I wrote the following Python code to parse the FDM XML, which you could potentially use as a starting point for generating dot files etc.

import xml.etree.ElementTree as ET
from dataclasses import dataclass, field

@dataclass
class Function:
    name: str
    description: str = None
    parameters: list[tuple] = field(default_factory=list)

    def dump(self):
        print(f'{self.name} - {self.description}')
        for param in self.parameters:
            if param[0] == 'table':
                print('   Table:')
                for var in param[1]:
                    print(f'      {var}')
            else:
                print(f'   {param[1]}')

@dataclass
class Axis:
    name: str
    functions: list[Function] = field(default_factory=list)
    
    def dump(self):
        print(f'Axis: {self.name}')
        print('')
        for function in self.functions:
            function.dump()
            print('')
    
@dataclass
class Aerodynamics:
    axes: list[Axis] = field(default_factory=list)
    functions: list[Function] = field(default_factory=list)

    def dump(self):
        print('Aerodynamics:')
        for function in self.functions:
            function.dump()
        print('')
        for axis in self.axes:
            axis.dump()
        print('')


def process_table(table_elem):
    independent_vars = []
    for independent_var in table_elem.iter('independentVar'):
        independent_vars.append(independent_var.text)
    return ('table', independent_vars)

def process_functions(parent, container):
    for function in parent.findall('function'):
        container.functions.append(process_function(function))

def process_function(function):
    func = Function(function.attrib['name'])

    for child in function:
        if child.tag == 'description':
            func.description = child.text
        elif child.tag == 'table':
            func.parameters.append(process_table(child))
        else:
            for grand_child in child:
                if grand_child.tag == 'property':
                    func.parameters.append(('property', grand_child.text))
                elif grand_child.tag == 'value':
                    func.parameters.append(('value', grand_child.text))
                elif grand_child.tag == 'table':
                    func.parameters.append(process_table(grand_child))
                else:
                    print(f'Unknown product child element: {grand_child.tag}')
            
    return func

def process_axes(parent, container):
    for axis_element in parent.findall('axis'):
        axis = Axis(axis_element.attrib['name'])
        process_functions(axis_element, axis)
        container.axes.append(axis)


fdm = ET.parse('..\\aircraft\\f16\\f16.xml')

aero_element = fdm.getroot().find('aerodynamics')

aero = Aerodynamics()

process_functions(aero_element, aero)
process_axes(aero_element, aero)

aero.dump()

With a snippet of some sample output.

Aerodynamics:
aero/function/kCLge - Change_in_lift_due_to_ground_effect
   Table:
      aero/h_b-mac-ft

Axis: DRAG

aero/coefficient/CDDh - Drag_due_to_horizontal_tail_deflection
   aero/qbar-psf
   metrics/Sw-sqft
   Table:
      aero/alpha-rad
      fcs/elevator-pos-rad

aero/coefficient/CDmach - Drag_due_to_mach
   aero/qbar-psf
   metrics/Sw-sqft
   Table:
      velocities/mach

aero/coefficient/CDDlef - Drag_due_to_leading_edge_flap_deflection
   aero/qbar-psf
   metrics/Sw-sqft
   fcs/lef-pos-rad
   Table:
      aero/alpha-rad

aero/coefficient/CDDflaps - Drag_due_to_trailing_edge_flaps
   aero/qbar-psf
   metrics/Sw-sqft
   fcs/flaperon-mix-rad
   0.0800

aero/coefficient/CDgear - Drag_due_to_gear
   aero/qbar-psf
   metrics/Sw-sqft
   gear/gear-pos-norm
   0.0270

aero/coefficient/CDDsb - Drag_due_to_speedbrake_deflection
   aero/qbar-psf
   metrics/Sw-sqft
   fcs/speedbrake-pos-rad
   Table:
      aero/alpha-rad

aero/coefficient/CDq - Drag_due_to_pitch_rate
   aero/qbar-psf
   metrics/Sw-sqft
   velocities/q-aero-rad_sec
   aero/ci2vel
   Table:
      aero/alpha-rad

aero/coefficient/CDq_Dlef - Drag_due_to_pitch_rate_and_leading_edge_flap_deflection
   aero/qbar-psf
   metrics/Sw-sqft
   velocities/q-aero-rad_sec
   aero/ci2vel
   fcs/lef-pos-rad
   Table:
      aero/alpha-rad

Axis: SIDE

aero/coefficient/CYb - Side_force_due_to_beta
   aero/qbar-psf
   metrics/Sw-sqft
   aero/beta-rad
   -1.1460

[bcoconni]

I don't think "JSBSim DO NOT want to do this work." On the contrary, this work should be kept in a proper place and should nicely cope with the general purpose of the core software library.

I agree: this could be a separate project from JSBSim similar to https://github.com/NikolaiVChr/jsb-to-png.

The problem with including this work in JSBSim is that @yanzixiang has no track record regarding JSBSim and, from experience, the maintenance of PRs issued by newcomers falls back in most cases to the core team (i.e. @seanmcleod, @agodemar and myself) since the original authors generally lose interest in their contribution after some time. Exceptions can be made when the PR brings a significant improvement to JSBSim itself (PR #574 comes to my mind).

This PR could be a significant improvement to the JSBSim ecosystem while being maintained as a separate project. As @seanmcleod examplified, the C++ code of JSBSim needs not to be modified to reach the purpose of this PR.

[bcoconni]

Do we want to include a specific utility tool in the repo or not. For example at the moment we only have a single one, Aeromatic++.

Regarding aeromatic++, the situation is quite different as @ermarch has been contributing to JSBSim for years and he has proven his involvement by fixing bugs.

Also aeromatic++ is a completely independent piece of software so, even in the case where @ermarch would decide he no longer wants to maintain it, we could either let the code rot or move it to a separate independent project with no impact to JSBSim until someone volunteers to take over the maintenance of aeromatic++.