<soapbox>
Dennis, thanks for the nice words about my work. With my new format for
Datcom+ Pro, I'm trying to provide the user with a format that is easy to
follow, since these college kids are new to many things: Datcom, JSBSim,
aerodynamics in general, flight testing, and XML formats just to name a few,
all things that we take for granted because we've been exposed to them for
years. I had trouble understanding the JSBSim stuff when I first came to
this community many years ago, and I still sometimes wonder about some
things. The documentation isn't always there, but I can connect the dots
because I have experience in this stuff. It's just much tougher for the
newbee. I can't imagine throwing in one more factor, doing all of this in a
non-native language. The Datcom manual is hard enough for me to understand,
and I speak English. I have Datcom+ users all over the world, and I hope to
have an explosion of users in the near future, as several university-level
instructors are evaluating my Datcom+ Pro or are writing lessons plans
around it.
I was not trying to impose any 'standard', just trying to demonstrate one
possible format. I am going to adopt this for Datcom+ Pro package, partially
because it's easy to follow, and therefore I have to write less
documentation on it. Maybe that's something that can be considered during
these discussion of a new output format for Aeromatic, making it simple to
understand, since most people are just going to dive into it and not read
any documentation, if it is available. Sure, you can make a lot of
'intrinict' rules on how things are handled internally within the code, but
without documentation, that can lead to confusion and frustration. Been
there, have the scars.
My opinion is stated in my format: Coefficients and derivatives are labeled
as such, so that they can be tracked against what you see in aircraft design
or flight test reports. Coefficients are summed and converted to forces and
moments as shown in classical aerodynamic text books, so that the noob can
follow along. They've only see it one way, and I don't want to or need to
introduct an alternative way, even if it arrives at the same end point.
</soapbox>
Bill
> -----Original Message-----
> From: Dennis J. Linse [mailto:jsbsim@...]
> Sent: Tuesday, July 26, 2011 11:11 AM
> To: Development issues
> Subject: Re: [Jsbsim-devel] Aeromatic v0.95 uploaded to web site
>
>
> On 2011-07-25 9:29 PM, Ron Jensen wrote:
> > This is actually the approach I am very opposed to. What we wind up
> > with is hundreds of lines (rough count 200-300 lines in 20+
> functions)
> > that are not sorted into the individual axis tags, and not divided
> > into channels, just dumped into the function area under the
> main <aerodynamic> tag.
>
> Bill's example, and I've seen other, more complete ones,
> while not putting the coefficients <functions> inside the
> <axis> tags, since that
> *implies* addition, put all of the the "sub"-<function>
> immediately before the <axis> in which they are used: lift
> sub-components followed by the <axis name="LIFT"> element,
> followed by drag sub-components followed by the <axis
> name="DRAG"> element, etc. Thus the only real difference in
> reading the XML file as pure text is the single <axis
> name="LIFT"> line is move up or down however many (100s with a big
> table?) lines. Of course, reading it with an XML-smart
> editor would admittedly allow more nesting/hiding/collapsing,
> but that is the only difference that I see. Validation can
> be made to work either way. Note that the "big" sims, these
> tables are all stored elsewhere since they are *huge*.
>
> If having everything within the <axis> is particularly
> important, one off-the-wall suggestion might be to make a
> <subfunction> available inside the <axis> that is just
> another name for a <function> in all characteristics except
> it isn't automagically added to the other components for the
> final output.
>
> In fact, the whole everything-inside-the-<axis>-tags concept
> is a little confusing (to me at least) when first coming and
> reading a JSBSim XML file. <sum> and <product> are clearer
> in their function due to their mathematical connection, but
> just reading <axis> isn't as clear since, for example,
> everything inside a <channel> isn't automagically added together.
>
> Note that the current JSBSim documentation specifically says
> right after the description of adding everything inside an
> <axis> that one way to write models is to put coefficients in
> functions outside the <axis> and then sum them inside the
> <axis>, just as done in this example.
>
> > We are then
> > stuck with multiplying the whole mess by a single q-bar instead of
> > having the flexibility to use a specialized q-bar that may
> make more sense.
>
> I don't believe that this is a very solid argument. There is
> nothing "stuck" in "the whole mess". Here is the example
> Bill provided from
> Datcom+ Pro:
>
> <function name="aero/force/lift-lbs">
> <description>
> Lift force = ( CL_wbh + CLq*q*cbar/(2*V) +
> CLadot*adot*cbar/(2*V) + dCL_Flap + dCL_Elev + dCL_Power )
> * q_bar * Wing area
> </description>
> <product>
> <sum>
> <property> aero/coefficient/CL_wbh </property>
> <product>
> <property> aero/derivative/CLq-per_rad </property>
> <property> velocities/q-aero-rad_sec </property>
> <property> aero/ci2vel </property>
> </product>
> <product>
> <property> aero/derivative/CLadot-per_rad
> </property>
> <property> aero/alphadot-rad_sec </property>
> <property> aero/ci2vel </property>
> </product>
> <property> aero/coefficient/dCL_Flap </property>
> <property> aero/coefficient/dCL_Elev </property>
> <property> aero/coefficient/dCL_Power </property>
> </sum>
> <property> aero/qbar-psf </property>
> <property> metrics/Sw-sqft </property>
> </product>
> </function>
>
> Change the order of the products and sums in here to your
> heart's content if you need to make some specialized model.
> Or you could replace the single function with a series of
> functions much like you currently have, if have the
> individual forces is particularly important to you.
> Nothing at all prevents you from doing that. In fact, Jon
> (and others) hard work makes that incredibly easy. The above
> output is listed how it is written in any number of textbook
> and NACA reports so that first-time users will recognize the
> standard equations. For those cases where you want to use
> qbar_slipstream, go for it and hand tweak the above.
>
> Remember, the example Bill has offered is intended to cover
> the majority of baseline cases, not every possible aero
> model. Just as Aeromatic is intended to provide a working,
> albeit quite simple, model that can then be adjusted easily.
>
> Bill is doing a commendable service to the JSBSim community by having
> Datcom+ Pro outputting a JSBSim file. He has a number of
> student users
> around the world who are using Datcom for their classes and
> now just logically go to JSBSim for their simulation needs.
> But those same students need to have their hands held and the
> input look like their textbooks. The above models look like
> their textbooks.
>
>
> >> > More descriptive
> >> > comments would also be good. I'm open to anything as long as our
> >> > terminology is correct.
> > I will sit down over the next few days and change the aeromatic
> > descriptions to add the coefficient names into them. My
> goal is to be
> > able to sit down with a NACA report, or a DATCOM raw output, and be
> > able to plug the coefficients in the right place, or
> readily identify
> > that the function for a coefficient is missing and needs to
> be added.
>
> I don't see how Bill's example output changes this at all.
> For example,
>
> <function name="aero/derivative/CLadot-per_rad">
> <description>
> Lift coefficient derivative due to AOA rate, per rad
> Important contributor to short period damping
> </description>
> <table>
> <independentVar lookup="row"> aero/alpha-deg
> </independentVar>
> <tableData>
> -16.0000 1.3112
> 24.0000 .6028
> </tableData>
> </table>
> </function>
>
> It seems pretty straightforward to grab the required data
> from a NACA report or DATCOM and known what needs to go into
> that block. And by having the final Lift <product> be only
> twenty lines of simple summations/products, I can see
> immediately the terms that I'm adding in.
> If I want to eliminate a term, I can comment out a single
> line or two, not have to comment out a 50+ line table that
> scrolls off the top and bottom of my screen. (Of course,
> there are other ways to do this as well.)
>
> Just my 37 cents. (way more than 2 cents these days)
>
> Dennis
>
> --------------------------------------------------------------
> ----------------
> Magic Quadrant for Content-Aware Data Loss Prevention
> Research study explores the data loss prevention market.
> Includes in-depth analysis on the changes within the DLP
> market, and the criteria used to evaluate the strengths and
> weaknesses of these DLP solutions.
> http://www.accelacomm.com/jaw/sfnl/114/51385063/
> _______________________________________________
> Jsbsim-devel mailing list
> Jsbsim-devel@...
> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel
> _______________________________________________
> The JSBSim Flight Dynamics Model project
> http://www.JSBSim.org _______________________________________________
>
|