From: Scott <sco...@pl...> - 2011-01-12 09:47:24
|
Hello, I am looking to see how difficult it would be to model the effect of bleed air extraction on engine thrust, fuel consumption and EGT for a jsbsim turbine engine in FlightGear. There are two problems; the first is finding figures for the amount of bleed air extracted at different points for different use (I'm mainly thinking of external use such as for pressurisation, anti-ice etc, and then secondly for internal use, ie: for cooling) and the second problem of how to implement that in jsbsim and FlightGear for the RR Trent series and CF6 (the aircraft being simulated are the A380 first, then A340-300 and the A330-300 if everything goes well). Thanks to Jon Berndt the following link seems to indicate that the relationship is not too complex, and I've found EASA Type Certification documents for the CF6-80E1 and Trent 900 (RB211) engines which gives some figures on bleed extraction percentages, however the mathematics elude me and my knowledge of any of these areas is very limited (I'm a software coder not an aeronautical engineer). If anyone has any ideas of how this could be incorporated into a engine definition I'd be interested to hear your thoughts. cheers Scott. Link references: http://www.nasa.gov/centers/dryden/pdf/88218main_H-1679.pdf http://www.easa.europa.eu/certification/type-certificates/docs/engines/EASA-TCDS-E.012_Rolls--Royce_plc._RB211_Trent_900_Series_engines-04-24052007.pdf http://www.easa.europa.eu/certification/type-certificates/docs/engines/EASA-TCDS-E.007_(IM)_General_Electric_CF6--80E1_Series_engines-01-14062004.pdf (there is quite a list at http://www.easa.europa.eu/certification/type-certificates/engines.php ) And a rather interesting document on something altogether different, but does include calculations of different pressures and shaft rotations; http://dspace.lib.cranfield.ac.uk/bitstream/1826/3327/1/Engine%20bleed% 20on%20performance%20of%20a%20single-spool%20turbojet%20engine-2008.pdf |
From: Ron J. <wi...@je...> - 2011-01-12 16:15:42
|
On Wednesday 12 January 2011 02:30:50 Scott wrote: > Hello, > > > I am looking to see how difficult it would be to model the effect of > bleed air extraction on engine thrust, fuel consumption and EGT for a > jsbsim turbine engine in FlightGear. > > There are two problems; the first is finding figures for the amount > of bleed air extracted at different points for different use (I'm mainly > thinking of external use such as for pressurisation, anti-ice etc, and > then secondly for internal use, ie: for cooling) and the second problem > of how to implement that in jsbsim and FlightGear for the RR Trent > series and CF6 (the aircraft being simulated are the A380 first, then > A340-300 and the A330-300 if everything goes well). > > Thanks to Jon Berndt the following link seems to indicate that the > relationship is not too complex, and I've found EASA Type Certification > documents for the CF6-80E1 and Trent 900 (RB211) engines which gives > some figures on bleed extraction percentages, however the mathematics > elude me and my knowledge of any of these areas is very limited (I'm a > software coder not an aeronautical engineer). > > If anyone has any ideas of how this could be incorporated into a > engine definition I'd be interested to hear your thoughts. > > > cheers > Scott. > > > Link references: > http://www.nasa.gov/centers/dryden/pdf/88218main_H-1679.pdf > > http://www.easa.europa.eu/certification/type-certificates/docs/engines/EASA >-TCDS-E.012_Rolls--Royce_plc._RB211_Trent_900_Series_engines-04-24052007.pdf > http://www.easa.europa.eu/certification/type-certificates/docs/engines/EASA >-TCDS-E.007_(IM)_General_Electric_CF6--80E1_Series_engines-01-14062004.pdf > > (there is quite a list at > http://www.easa.europa.eu/certification/type-certificates/engines.php ) > > And a rather interesting document on something altogether different, but > does include calculations of different pressures and shaft rotations; > http://dspace.lib.cranfield.ac.uk/bitstream/1826/3327/1/Engine%20bleed% > 20on%20performance%20of%20a%20single-spool%20turbojet%20engine-2008.pdf The current code includes a BleedDemand variable that reduces thrust. See line 232 of FGTurbine.cpp: http://jsbsim.cvs.sourceforge.net/viewvc/jsbsim/JSBSim/src/models/propulsion/FGTurbine.cpp?revision=1.29&view=markup There is a getter/setter pair for this variable in FGTurbine.h http://jsbsim.cvs.sourceforge.net/viewvc/jsbsim/JSBSim/src/models/propulsion/FGTurbine.h?revision=1.19&view=markup but it appears to me to be unused. So in the current releases it is probably a fixed value set by the configuration <bleed/> tag and defaulting to zero. Ron |
From: David C. <dav...@co...> - 2011-01-12 18:45:46
|
On Wed, 12 Jan 2011 20:30:50 +1100 Scott <sco...@pl...> wrote: > I am looking to see how difficult it would be to model the effect of > bleed air extraction on engine thrust, fuel consumption and EGT for a > jsbsim turbine engine in FlightGear. Hello Scott, The turbine model currently provides a parameter that can be used to reduce thrust. At load-time the configuration parameter "bleed" can be specified to establish a thrust loss due to any cause. From the documentation in FGTurbine.h: The bleed factor is multiplied by thrust to give a resulting thrust after losses. This can represent losses due to bleed, or any other cause. Default value is 0. A common value would be 0.04. As Ron mentioned, during run-time the bleed value can be altered with the function FGTurbine::SetBleedDemand(). The value simply reduces thrust: thrust = thrust * (1.0 - BleedDemand); Effect of bleed on hot section temperatures and TSFC is not modeled, however if you assume that the throttle must be advanced to maintain a given thrust after an increase in bleed demand, then you'll get higher EGT and higher effective TSFC. The turbine models mentioned in the documents you linked to are vastly different from FGTurbine. FGTurbine is not a Component Level Model (CLM) of an engine, thus the thermodynamics are not modeled. Also, there is no EEC, or even a fuel controller of any kind, modeled. Thanks for the links! John Wronowski wrote a CLM for the CFM-56 a few years back, and it looked great, however I have always had concerns about how adaptable a CLM would be for all types of turbine engines, and how feasible it would be for users to gather the data needed to model any particular engine. OTOH, I'd love to be proven wrong. I wonder if C-MAPSS could be adapted for us? http://sr.grc.nasa.gov/public/project/54/ Dave Culp |
From: Scott <sco...@pl...> - 2011-01-13 00:23:46
|
Thanks Ron and Dave, I had noticed the load-time <bleed> configuration element a long time ago but obviously forgot about it, this makes things much easier, I just need to normalise a value between 0 - 1 this is all good. Having a quick read through FGTurbine, (C++ is not my primary language, Java is, but this does read more like C code which I can understand better), if one wanted to allow run-time modification of the bleedDemand value from within FlightGear, I would need to add two new lines; tmp = CreateIndexedPropertyName("fcs/bleed-demand-pos-norm", num); PropertyManager->Tie( tmp.c_str(), this, num, &FGFCS::GetBleedPos, &FGFCS::SetBleedPos); in the method void FGFCS::bindThrottle(unsigned int num) and then the corresponding double FGFCS::GetBleedPos(int engineNum) const void FGFCS::SetThrottlePos(int engineNum, double setting) and the vector data structure in FGFCS.h and then update the two methods; double FGTurbine::Run() double FGTurbine::Trim() to get the value from FCS->GetBleedPos(unit) instead, and set the initial value in bool FGTurbine::Load(FGFDMExec* exec, Element *el) I assume this arrives at the FlightGear codebase directly from JSBsim codebase, so to do this I would need to make a patch here rather than in FG? If I do that I might see if I can work out how to keep track of total fuel used by each engine (just cumulative of the fuel flow, I guess), it's a common monitoring value in modern glass cockpits. On Generic versus CLM, I think FGTurbine has provided us well, while it is interesting to model every aspect, to be honest I think a lot would be lost for FlightGear and gaining enough data on every engine model could prove difficult, the abstract model we have is sufficient for most purposes, though I'd imagine some folks would like to see a more detailed, controllable engine, but not everyone would or could model them correctly. I notice you mention the value 0.04 as a common value, looking at the EASA Type Certification data sheets, they mention bleed values of 5%, that would give a value of 0.2 (normalised) that seems much higher, is that an unrealistic number? cheers S. On Wed, 2011-01-12 at 10:46 -0800, David Culp wrote: > On Wed, 12 Jan 2011 20:30:50 +1100 > Scott <sco...@pl...> wrote: > > > I am looking to see how difficult it would be to model the effect of > > bleed air extraction on engine thrust, fuel consumption and EGT for a > > jsbsim turbine engine in FlightGear. > > > Hello Scott, > > The turbine model currently provides a parameter that can be used to reduce thrust. At load-time the configuration parameter "bleed" can be specified to establish a thrust loss due to any cause. From the documentation in FGTurbine.h: > > The bleed factor is multiplied by thrust to give a resulting thrust > after losses. This can represent losses due to bleed, or any other cause. > Default value is 0. A common value would be 0.04. > > > As Ron mentioned, during run-time the bleed value can be altered with the function FGTurbine::SetBleedDemand(). > > The value simply reduces thrust: > thrust = thrust * (1.0 - BleedDemand); > > > Effect of bleed on hot section temperatures and TSFC is not modeled, however if you assume that the throttle must be advanced to maintain a given thrust after an increase in bleed demand, then you'll get higher EGT and higher effective TSFC. > > The turbine models mentioned in the documents you linked to are vastly different from FGTurbine. FGTurbine is not a Component Level Model (CLM) of an engine, thus the thermodynamics are not modeled. Also, there is no EEC, or even a fuel controller of any kind, modeled. > > Thanks for the links! John Wronowski wrote a CLM for the CFM-56 a few years back, and it looked great, however I have always had concerns about how adaptable a CLM would be for all types of turbine engines, and how feasible it would be for users to gather the data needed to model any particular engine. OTOH, I'd love to be proven wrong. I wonder if C-MAPSS could be adapted for us? > http://sr.grc.nasa.gov/public/project/54/ > > > Dave Culp > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Jsbsim-devel mailing list > Jsb...@li... > https://lists.sourceforge.net/lists/listinfo/jsbsim-devel > _______________________________________________ > The JSBSim Flight Dynamics Model project > http://www.JSBSim.org > _______________________________________________ > |
From: David C. <dav...@co...> - 2011-01-13 21:56:34
|
On Thu, 13 Jan 2011 11:23:09 +1100 Scott <sco...@pl...> wrote: > ... if one wanted to allow run-time modification of the > bleedDemand value from within FlightGear ... In this case all that's needed is to expose the bleed variable to the property tree from within FGTurbine, resulting in a property such as: propulsion/engine[n]/bleed-factor, which would be fdm/jsbsim/propulsion/engine[n]/bleed-factor from within FlightGear. I'm all for this, but I won't be able to get to it for a couple weeks. > I assume this arrives at the FlightGear codebase directly from JSBsim > codebase, so to do this I would need to make a patch here rather than in > FG? Erik Hofman periodically cuts over the latest JSBSim code to FlightGear. > If I do that I might see if I can work out how to keep track of total > fuel used by each engine (just cumulative of the fuel flow, I guess), > it's a common monitoring value in modern glass cockpits. That's also a good idea. This could easily be added to FGEngine::ConsumeFuel(), and the fuel_used value exposed to the property tree by FGEngine. I'll work on it in a couple weeks, unless someone beats me to it. > I notice you mention the value 0.04 as a common value, looking at the > EASA Type Certification data sheets, they mention bleed values of 5%, > that would give a value of 0.2 (normalised) that seems much higher, is > that an unrealistic number? In FGTurbine, 0.04 is treated as 4%, i.e. the resulting thrust factor would be 1 - 0.04, or 96%. Dave |
From: Scott <sco...@pl...> - 2011-01-14 02:49:34
Attachments:
jsbsim-turbine.patch
|
Hi ya Dave, Having never made a source-code patch (or written a line of C++) I decided to give this a try, since it seemed simple enough. The attached file seems to compile OK, and given it's small size and simplicity gives me high hopes that it would actually work, but I'm not sure how to test it... If the attached file is in the proper patch format, where should it go next? Cheers Scott. On Thu, 13 Jan 2011 13:57:25 -0800, David Culp <dav...@co...> wrote: > On Thu, 13 Jan 2011 11:23:09 +1100 > Scott <sco...@pl...> wrote: > >> ... if one wanted to allow run-time modification of the >> bleedDemand value from within FlightGear ... > > > In this case all that's needed is to expose the bleed variable to the > property tree from within FGTurbine, resulting in a property such as: > propulsion/engine[n]/bleed-factor, which would be > fdm/jsbsim/propulsion/engine[n]/bleed-factor from within FlightGear. > > I'm all for this, but I won't be able to get to it for a couple weeks. > > > >> I assume this arrives at the FlightGear codebase directly from JSBsim >> codebase, so to do this I would need to make a patch here rather than in >> FG? > > Erik Hofman periodically cuts over the latest JSBSim code to FlightGear. > > >> If I do that I might see if I can work out how to keep track of total >> fuel used by each engine (just cumulative of the fuel flow, I guess), >> it's a common monitoring value in modern glass cockpits. > > That's also a good idea. This could easily be added to > FGEngine::ConsumeFuel(), and the fuel_used value exposed to the property > tree by FGEngine. I'll work on it in a couple weeks, unless someone beats > me to it. > > >> I notice you mention the value 0.04 as a common value, looking at the >> EASA Type Certification data sheets, they mention bleed values of 5%, >> that would give a value of 0.2 (normalised) that seems much higher, is >> that an unrealistic number? > > In FGTurbine, 0.04 is treated as 4%, i.e. the resulting thrust factor > would be 1 - 0.04, or 96%. > > > Dave > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Jsbsim-devel mailing list > Jsb...@li... > https://lists.sourceforge.net/lists/listinfo/jsbsim-devel > _______________________________________________ > The JSBSim Flight Dynamics Model project > http://www.JSBSim.org > _______________________________________________ |
From: Dennis J. L. <js...@li...> - 2011-01-14 03:44:21
|
Scott, There are those of use out here that might be able to apply your patch to our local copy and try it. And there are the big, important guys ;-) that can apply it and commit it to the CVS repository. Just looking at your patch and the current code generates a couple of questions, one partially under your control, and one that I noticed while following how your change might work: 1) I think it would be a good idea if your patch set the value of TotalFuelUsed to zero at initialization (or reset). I think that this might be best accomplished in ResetToIC(). Otherwise TotalFuelUsed would accumulate across different runs of the same instance, even if everything else reset. 2) While looking how RestToIC() is used in FGEngine, I see it is overridden in FGPiston and FGTurbine. Fair enough. What I also see is that in FGPiston the FGEngine::ResetToIC() is called. This is *not* done in FGTurbine::ResetToIC(). I think this is a potential mistake. If you redo your patch, could you add that as well? Oh, and one other thing: patch files should be made relative to the top of the JSBSim directory so that they can be applied with a single command like this: cd where/I/keep/JSBSim patch -p0 <a_better_mousetrap.patch Your patch wouldn't have lines like this: --- FGTurbine.cpp 31 Aug 2010 04:01:32 -0000 1.29 +++ FGTurbine.cpp 14 Jan 2011 02:32:26 -0000 but rather like this: --- src/models/propulsion/FGTurbine.cpp 31 Aug 2010 04:01:32 -0000 1.29 +++ src/models/propulsion/FGTurbine.cpp 14 Jan 2011 02:32:26 -0000 Dennis On 2011-01-13 8:48 PM, Scott wrote: > Hi ya Dave, > > > Having never made a source-code patch (or written a line of C++) I > decided to give this a try, since it seemed simple enough. > The attached file seems to compile OK, and given it's small size and > simplicity gives me high hopes that it would actually work, but I'm not > sure how to test it... > If the attached file is in the proper patch format, where should it go > next? > > > Cheers > Scott. > > > > > > > On Thu, 13 Jan 2011 13:57:25 -0800, David Culp <dav...@co...> wrote: >> On Thu, 13 Jan 2011 11:23:09 +1100 >> Scott <sco...@pl...> wrote: >> >>> ... if one wanted to allow run-time modification of the >>> bleedDemand value from within FlightGear ... >> >> >> In this case all that's needed is to expose the bleed variable to the >> property tree from within FGTurbine, resulting in a property such as: >> propulsion/engine[n]/bleed-factor, which would be >> fdm/jsbsim/propulsion/engine[n]/bleed-factor from within FlightGear. >> >> I'm all for this, but I won't be able to get to it for a couple weeks. >> >> >> >>> I assume this arrives at the FlightGear codebase directly from > JSBsim >>> codebase, so to do this I would need to make a patch here rather than > in >>> FG? >> >> Erik Hofman periodically cuts over the latest JSBSim code to FlightGear. >> >> >>> If I do that I might see if I can work out how to keep track of > total >>> fuel used by each engine (just cumulative of the fuel flow, I guess), >>> it's a common monitoring value in modern glass cockpits. >> >> That's also a good idea. This could easily be added to >> FGEngine::ConsumeFuel(), and the fuel_used value exposed to the property >> tree by FGEngine. I'll work on it in a couple weeks, unless someone > beats >> me to it. >> >> >>> I notice you mention the value 0.04 as a common value, looking at the >>> EASA Type Certification data sheets, they mention bleed values of 5%, >>> that would give a value of 0.2 (normalised) that seems much higher, is >>> that an unrealistic number? >> >> In FGTurbine, 0.04 is treated as 4%, i.e. the resulting thrust factor >> would be 1 - 0.04, or 96%. >> >> >> Dave >> >> >> > ------------------------------------------------------------------------------ >> Protect Your Site and Customers from Malware Attacks >> Learn about various malware tactics and how to avoid them. Understand >> malware threats, the impact they can have on your business, and how you >> can protect your company and customers by using code signing. >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Jsbsim-devel mailing list >> Jsb...@li... >> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel >> _______________________________________________ >> The JSBSim Flight Dynamics Model project >> http://www.JSBSim.org >> _______________________________________________ >> >> >> ------------------------------------------------------------------------------ >> Protect Your Site and Customers from Malware Attacks >> Learn about various malware tactics and how to avoid them. Understand >> malware threats, the impact they can have on your business, and how you >> can protect your company and customers by using code signing. >> http://p.sf.net/sfu/oracle-sfdevnl >> >> >> _______________________________________________ >> Jsbsim-devel mailing list >> Jsb...@li... >> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel >> _______________________________________________ >> The JSBSim Flight Dynamics Model project >> http://www.JSBSim.org >> _______________________________________________ >> |
From: Scott <sco...@pl...> - 2011-01-14 04:46:45
Attachments:
jsbsim-turbine_2010-01-14_02.patch
|
Many thanks Dennis. I've redone the patch taking into account all your good suggestions. I should have added to the ResetToIC() method, but in my haste I didn't stop to think about it... If anyone can do a sanity check on it, I'd be pleased to hear back from them. cheers Scott. On Thu, 13 Jan 2011 21:44:14 -0600, "Dennis J. Linse" <js...@li...> wrote: > Scott, > > There are those of use out here that might be able to apply your patch > to our local copy and try it. And there are the big, important guys ;-) > that can apply it and commit it to the CVS repository. > > Just looking at your patch and the current code generates a couple of > questions, one partially under your control, and one that I noticed > while following how your change might work: > > 1) I think it would be a good idea if your patch set the value of > TotalFuelUsed to zero at initialization (or reset). I think that this > might be best accomplished in ResetToIC(). Otherwise TotalFuelUsed > would accumulate across different runs of the same instance, even if > everything else reset. > > 2) While looking how RestToIC() is used in FGEngine, I see it is > overridden in FGPiston and FGTurbine. Fair enough. What I also see is > that in FGPiston the FGEngine::ResetToIC() is called. This is *not* > done in FGTurbine::ResetToIC(). I think this is a potential mistake. > > If you redo your patch, could you add that as well? > > Oh, and one other thing: patch files should be made relative to the top > of the JSBSim directory so that they can be applied with a single > command like this: > > cd where/I/keep/JSBSim > patch -p0 <a_better_mousetrap.patch > > > Your patch wouldn't have lines like this: > > --- FGTurbine.cpp 31 Aug 2010 04:01:32 -0000 1.29 > +++ FGTurbine.cpp 14 Jan 2011 02:32:26 -0000 > > > but rather like this: > > --- src/models/propulsion/FGTurbine.cpp 31 Aug 2010 04:01:32 -0000 > 1.29 > +++ src/models/propulsion/FGTurbine.cpp 14 Jan 2011 02:32:26 -0000 > > > Dennis > > On 2011-01-13 8:48 PM, Scott wrote: >> Hi ya Dave, >> >> >> Having never made a source-code patch (or written a line of C++) I >> decided to give this a try, since it seemed simple enough. >> The attached file seems to compile OK, and given it's small size and >> simplicity gives me high hopes that it would actually work, but I'm not >> sure how to test it... >> If the attached file is in the proper patch format, where should it go >> next? >> >> >> Cheers >> Scott. >> >> >> >> >> >> >> On Thu, 13 Jan 2011 13:57:25 -0800, David Culp <dav...@co...> wrote: >>> On Thu, 13 Jan 2011 11:23:09 +1100 >>> Scott <sco...@pl...> wrote: >>> >>>> ... if one wanted to allow run-time modification of the >>>> bleedDemand value from within FlightGear ... >>> >>> >>> In this case all that's needed is to expose the bleed variable to the >>> property tree from within FGTurbine, resulting in a property such as: >>> propulsion/engine[n]/bleed-factor, which would be >>> fdm/jsbsim/propulsion/engine[n]/bleed-factor from within FlightGear. >>> >>> I'm all for this, but I won't be able to get to it for a couple weeks. >>> >>> >>> >>>> I assume this arrives at the FlightGear codebase directly from >> JSBsim >>>> codebase, so to do this I would need to make a patch here rather than >> in >>>> FG? >>> >>> Erik Hofman periodically cuts over the latest JSBSim code to FlightGear. >>> >>> >>>> If I do that I might see if I can work out how to keep track of >> total >>>> fuel used by each engine (just cumulative of the fuel flow, I guess), >>>> it's a common monitoring value in modern glass cockpits. >>> >>> That's also a good idea. This could easily be added to >>> FGEngine::ConsumeFuel(), and the fuel_used value exposed to the property >>> tree by FGEngine. I'll work on it in a couple weeks, unless someone >> beats >>> me to it. >>> >>> >>>> I notice you mention the value 0.04 as a common value, looking at the >>>> EASA Type Certification data sheets, they mention bleed values of 5%, >>>> that would give a value of 0.2 (normalised) that seems much higher, is >>>> that an unrealistic number? >>> >>> In FGTurbine, 0.04 is treated as 4%, i.e. the resulting thrust factor >>> would be 1 - 0.04, or 96%. >>> >>> >>> Dave >>> >>> >>> >> ------------------------------------------------------------------------------ >>> Protect Your Site and Customers from Malware Attacks >>> Learn about various malware tactics and how to avoid them. Understand >>> malware threats, the impact they can have on your business, and how you >>> can protect your company and customers by using code signing. >>> http://p.sf.net/sfu/oracle-sfdevnl >>> _______________________________________________ >>> Jsbsim-devel mailing list >>> Jsb...@li... >>> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel >>> _______________________________________________ >>> The JSBSim Flight Dynamics Model project >>> http://www.JSBSim.org >>> _______________________________________________ >>> >>> >>> ------------------------------------------------------------------------------ >>> Protect Your Site and Customers from Malware Attacks >>> Learn about various malware tactics and how to avoid them. Understand >>> malware threats, the impact they can have on your business, and how you >>> can protect your company and customers by using code signing. >>> http://p.sf.net/sfu/oracle-sfdevnl >>> >>> >>> _______________________________________________ >>> Jsbsim-devel mailing list >>> Jsb...@li... >>> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel >>> _______________________________________________ >>> The JSBSim Flight Dynamics Model project >>> http://www.JSBSim.org >>> _______________________________________________ >>> > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Jsbsim-devel mailing list > Jsb...@li... > https://lists.sourceforge.net/lists/listinfo/jsbsim-devel > _______________________________________________ > The JSBSim Flight Dynamics Model project > http://www.JSBSim.org > _______________________________________________ |
From: dpculp <dp...@gm...> - 2011-01-14 12:26:07
|
I think the "Total" part of TotalFuelUsed is superfluous. Can we go with just "FuelUsed"? Dave Sent from my iPhone On Jan 13, 2011, at 8:45 PM, Scott <sco...@pl...> wrote: > > > Many thanks Dennis. I've redone the patch taking into account all > your > good suggestions. > I should have added to the ResetToIC() method, but in my haste I > didn't > stop to think about it... > If anyone can do a sanity check on it, I'd be pleased to hear back > from > them. > > > cheers > Scott. > > > > > > On Thu, 13 Jan 2011 21:44:14 -0600, "Dennis J. Linse" > <js...@li...> > wrote: >> Scott, >> >> There are those of use out here that might be able to apply your >> patch >> to our local copy and try it. And there are the big, important >> guys ;-) >> that can apply it and commit it to the CVS repository. >> >> Just looking at your patch and the current code generates a couple of >> questions, one partially under your control, and one that I noticed >> while following how your change might work: >> >> 1) I think it would be a good idea if your patch set the value of >> TotalFuelUsed to zero at initialization (or reset). I think that >> this >> might be best accomplished in ResetToIC(). Otherwise TotalFuelUsed >> would accumulate across different runs of the same instance, even if >> everything else reset. >> >> 2) While looking how RestToIC() is used in FGEngine, I see it is >> overridden in FGPiston and FGTurbine. Fair enough. What I also >> see is >> that in FGPiston the FGEngine::ResetToIC() is called. This is *not* >> done in FGTurbine::ResetToIC(). I think this is a potential mistake. >> >> If you redo your patch, could you add that as well? >> >> Oh, and one other thing: patch files should be made relative to the >> top >> of the JSBSim directory so that they can be applied with a single >> command like this: >> >> cd where/I/keep/JSBSim >> patch -p0 <a_better_mousetrap.patch >> >> >> Your patch wouldn't have lines like this: >> >> --- FGTurbine.cpp 31 Aug 2010 04:01:32 -0000 1.29 >> +++ FGTurbine.cpp 14 Jan 2011 02:32:26 -0000 >> >> >> but rather like this: >> >> --- src/models/propulsion/FGTurbine.cpp 31 Aug 2010 04:01:32 >> -0000 >> 1.29 >> +++ src/models/propulsion/FGTurbine.cpp 14 Jan 2011 02:32:26 >> -0000 >> >> >> Dennis >> >> On 2011-01-13 8:48 PM, Scott wrote: >>> Hi ya Dave, >>> >>> >>> Having never made a source-code patch (or written a line of C++) I >>> decided to give this a try, since it seemed simple enough. >>> The attached file seems to compile OK, and given it's small size >>> and >>> simplicity gives me high hopes that it would actually work, but >>> I'm not >>> sure how to test it... >>> If the attached file is in the proper patch format, where should >>> it > go >>> next? >>> >>> >>> Cheers >>> Scott. >>> >>> >>> >>> >>> >>> >>> On Thu, 13 Jan 2011 13:57:25 -0800, David Culp <dav...@co...> > wrote: >>>> On Thu, 13 Jan 2011 11:23:09 +1100 >>>> Scott <sco...@pl...> wrote: >>>> >>>>> ... if one wanted to allow run-time modification of the >>>>> bleedDemand value from within FlightGear ... >>>> >>>> >>>> In this case all that's needed is to expose the bleed variable to >>>> the >>>> property tree from within FGTurbine, resulting in a property such >>>> as: >>>> propulsion/engine[n]/bleed-factor, which would be >>>> fdm/jsbsim/propulsion/engine[n]/bleed-factor from within >>>> FlightGear. >>>> >>>> I'm all for this, but I won't be able to get to it for a couple >>>> weeks. >>>> >>>> >>>> >>>>> I assume this arrives at the FlightGear codebase directly from >>> JSBsim >>>>> codebase, so to do this I would need to make a patch here rather >>>>> than >>> in >>>>> FG? >>>> >>>> Erik Hofman periodically cuts over the latest JSBSim code to > FlightGear. >>>> >>>> >>>>> If I do that I might see if I can work out how to keep track of >>> total >>>>> fuel used by each engine (just cumulative of the fuel flow, I >>>>> guess), >>>>> it's a common monitoring value in modern glass cockpits. >>>> >>>> That's also a good idea. This could easily be added to >>>> FGEngine::ConsumeFuel(), and the fuel_used value exposed to the > property >>>> tree by FGEngine. I'll work on it in a couple weeks, unless >>>> someone >>> beats >>>> me to it. >>>> >>>> >>>>> I notice you mention the value 0.04 as a common value, looking at > the >>>>> EASA Type Certification data sheets, they mention bleed values >>>>> of 5%, >>>>> that would give a value of 0.2 (normalised) that seems much >>>>> higher, > is >>>>> that an unrealistic number? >>>> >>>> In FGTurbine, 0.04 is treated as 4%, i.e. the resulting thrust >>>> factor >>>> would be 1 - 0.04, or 96%. >>>> >>>> >>>> Dave >>>> >>>> >>>> >>> > --- > --- > --- > --------------------------------------------------------------------- >>>> Protect Your Site and Customers from Malware Attacks >>>> Learn about various malware tactics and how to avoid them. >>>> Understand >>>> malware threats, the impact they can have on your business, and how > you >>>> can protect your company and customers by using code signing. >>>> http://p.sf.net/sfu/oracle-sfdevnl >>>> _______________________________________________ >>>> Jsbsim-devel mailing list >>>> Jsb...@li... >>>> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel >>>> _______________________________________________ >>>> The JSBSim Flight Dynamics Model project >>>> http://www.JSBSim.org >>>> _______________________________________________ >>>> >>>> >>>> > --- > --- > --- > --------------------------------------------------------------------- >>>> Protect Your Site and Customers from Malware Attacks >>>> Learn about various malware tactics and how to avoid them. >>>> Understand >>>> malware threats, the impact they can have on your business, and how > you >>>> can protect your company and customers by using code signing. >>>> http://p.sf.net/sfu/oracle-sfdevnl >>>> >>>> >>>> _______________________________________________ >>>> Jsbsim-devel mailing list >>>> Jsb...@li... >>>> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel >>>> _______________________________________________ >>>> The JSBSim Flight Dynamics Model project >>>> http://www.JSBSim.org >>>> _______________________________________________ >>>> >> >> > --- > --- > --- > --------------------------------------------------------------------- >> Protect Your Site and Customers from Malware Attacks >> Learn about various malware tactics and how to avoid them. Understand >> malware threats, the impact they can have on your business, and how >> you >> can protect your company and customers by using code signing. >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Jsbsim-devel mailing list >> Jsb...@li... >> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel >> _______________________________________________ >> The JSBSim Flight Dynamics Model project >> http://www.JSBSim.org >> _______________________________________________ > <jsbsim-turbine_2010-01-14_02.patch> > --- > --- > --- > --------------------------------------------------------------------- > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how > you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Jsbsim-devel mailing list > Jsb...@li... > https://lists.sourceforge.net/lists/listinfo/jsbsim-devel > _______________________________________________ > The JSBSim Flight Dynamics Model project > http://www.JSBSim.org > _______________________________________________ > |
From: Scott H. <sco...@pl...> - 2011-01-14 13:18:11
Attachments:
jsbsim-turbine_2010-01-15_01.patch
|
Sure, I can't think of a good reason not to.. :) I also made the property values in both old Imperial and modern Metric. S. On Fri, 14 Jan 2011 04:25:39 -0800, dpculp <dp...@gm...> wrote: > I think the "Total" part of TotalFuelUsed is superfluous. Can we go > with just "FuelUsed"? > > Dave > > Sent from my iPhone > > On Jan 13, 2011, at 8:45 PM, Scott <sco...@pl...> wrote: > >> >> >> Many thanks Dennis. I've redone the patch taking into account all >> your >> good suggestions. >> I should have added to the ResetToIC() method, but in my haste I >> didn't >> stop to think about it... >> If anyone can do a sanity check on it, I'd be pleased to hear back >> from >> them. >> >> >> cheers >> Scott. >> >> >> >> >> >> On Thu, 13 Jan 2011 21:44:14 -0600, "Dennis J. Linse" >> <js...@li...> >> wrote: >>> Scott, >>> >>> There are those of use out here that might be able to apply your >>> patch >>> to our local copy and try it. And there are the big, important >>> guys ;-) >>> that can apply it and commit it to the CVS repository. >>> >>> Just looking at your patch and the current code generates a couple of >>> questions, one partially under your control, and one that I noticed >>> while following how your change might work: >>> >>> 1) I think it would be a good idea if your patch set the value of >>> TotalFuelUsed to zero at initialization (or reset). I think that >>> this >>> might be best accomplished in ResetToIC(). Otherwise TotalFuelUsed >>> would accumulate across different runs of the same instance, even if >>> everything else reset. >>> >>> 2) While looking how RestToIC() is used in FGEngine, I see it is >>> overridden in FGPiston and FGTurbine. Fair enough. What I also >>> see is >>> that in FGPiston the FGEngine::ResetToIC() is called. This is *not* >>> done in FGTurbine::ResetToIC(). I think this is a potential mistake. >>> >>> If you redo your patch, could you add that as well? >>> >>> Oh, and one other thing: patch files should be made relative to the >>> top >>> of the JSBSim directory so that they can be applied with a single >>> command like this: >>> >>> cd where/I/keep/JSBSim >>> patch -p0 <a_better_mousetrap.patch >>> >>> >>> Your patch wouldn't have lines like this: >>> >>> --- FGTurbine.cpp 31 Aug 2010 04:01:32 -0000 1.29 >>> +++ FGTurbine.cpp 14 Jan 2011 02:32:26 -0000 >>> >>> >>> but rather like this: >>> >>> --- src/models/propulsion/FGTurbine.cpp 31 Aug 2010 04:01:32 >>> -0000 >>> 1.29 >>> +++ src/models/propulsion/FGTurbine.cpp 14 Jan 2011 02:32:26 >>> -0000 >>> >>> >>> Dennis >>> >>> On 2011-01-13 8:48 PM, Scott wrote: >>>> Hi ya Dave, >>>> >>>> >>>> Having never made a source-code patch (or written a line of C++) I >>>> decided to give this a try, since it seemed simple enough. >>>> The attached file seems to compile OK, and given it's small size >>>> and >>>> simplicity gives me high hopes that it would actually work, but >>>> I'm not >>>> sure how to test it... >>>> If the attached file is in the proper patch format, where should >>>> it >> go >>>> next? >>>> >>>> >>>> Cheers >>>> Scott. >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Thu, 13 Jan 2011 13:57:25 -0800, David Culp <dav...@co...> >> wrote: >>>>> On Thu, 13 Jan 2011 11:23:09 +1100 >>>>> Scott <sco...@pl...> wrote: >>>>> >>>>>> ... if one wanted to allow run-time modification of the >>>>>> bleedDemand value from within FlightGear ... >>>>> >>>>> >>>>> In this case all that's needed is to expose the bleed variable to >>>>> the >>>>> property tree from within FGTurbine, resulting in a property such >>>>> as: >>>>> propulsion/engine[n]/bleed-factor, which would be >>>>> fdm/jsbsim/propulsion/engine[n]/bleed-factor from within >>>>> FlightGear. >>>>> >>>>> I'm all for this, but I won't be able to get to it for a couple >>>>> weeks. >>>>> >>>>> >>>>> >>>>>> I assume this arrives at the FlightGear codebase directly from >>>> JSBsim >>>>>> codebase, so to do this I would need to make a patch here rather >>>>>> than >>>> in >>>>>> FG? >>>>> >>>>> Erik Hofman periodically cuts over the latest JSBSim code to >> FlightGear. >>>>> >>>>> >>>>>> If I do that I might see if I can work out how to keep track of >>>> total >>>>>> fuel used by each engine (just cumulative of the fuel flow, I >>>>>> guess), >>>>>> it's a common monitoring value in modern glass cockpits. >>>>> >>>>> That's also a good idea. This could easily be added to >>>>> FGEngine::ConsumeFuel(), and the fuel_used value exposed to the >> property >>>>> tree by FGEngine. I'll work on it in a couple weeks, unless >>>>> someone >>>> beats >>>>> me to it. >>>>> >>>>> >>>>>> I notice you mention the value 0.04 as a common value, looking at >> the >>>>>> EASA Type Certification data sheets, they mention bleed values >>>>>> of 5%, >>>>>> that would give a value of 0.2 (normalised) that seems much >>>>>> higher, >> is >>>>>> that an unrealistic number? >>>>> >>>>> In FGTurbine, 0.04 is treated as 4%, i.e. the resulting thrust >>>>> factor >>>>> would be 1 - 0.04, or 96%. >>>>> >>>>> >>>>> Dave >>>>> >>>>> >>>>> >>>> >> --- >> --- >> --- >> --------------------------------------------------------------------- >>>>> Protect Your Site and Customers from Malware Attacks >>>>> Learn about various malware tactics and how to avoid them. >>>>> Understand >>>>> malware threats, the impact they can have on your business, and how >> you >>>>> can protect your company and customers by using code signing. >>>>> http://p.sf.net/sfu/oracle-sfdevnl >>>>> _______________________________________________ >>>>> Jsbsim-devel mailing list >>>>> Jsb...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel >>>>> _______________________________________________ >>>>> The JSBSim Flight Dynamics Model project >>>>> http://www.JSBSim.org >>>>> _______________________________________________ >>>>> >>>>> >>>>> >> --- >> --- >> --- >> --------------------------------------------------------------------- >>>>> Protect Your Site and Customers from Malware Attacks >>>>> Learn about various malware tactics and how to avoid them. >>>>> Understand >>>>> malware threats, the impact they can have on your business, and how >> you >>>>> can protect your company and customers by using code signing. >>>>> http://p.sf.net/sfu/oracle-sfdevnl >>>>> >>>>> >>>>> _______________________________________________ >>>>> Jsbsim-devel mailing list >>>>> Jsb...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel >>>>> _______________________________________________ >>>>> The JSBSim Flight Dynamics Model project >>>>> http://www.JSBSim.org >>>>> _______________________________________________ >>>>> >>> >>> >> --- >> --- >> --- >> --------------------------------------------------------------------- >>> Protect Your Site and Customers from Malware Attacks >>> Learn about various malware tactics and how to avoid them. Understand >>> malware threats, the impact they can have on your business, and how >>> you >>> can protect your company and customers by using code signing. >>> http://p.sf.net/sfu/oracle-sfdevnl >>> _______________________________________________ >>> Jsbsim-devel mailing list >>> Jsb...@li... >>> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel >>> _______________________________________________ >>> The JSBSim Flight Dynamics Model project >>> http://www.JSBSim.org >>> _______________________________________________ >> <jsbsim-turbine_2010-01-14_02.patch> >> --- >> --- >> --- >> --------------------------------------------------------------------- >> Protect Your Site and Customers from Malware Attacks >> Learn about various malware tactics and how to avoid them. Understand >> malware threats, the impact they can have on your business, and how >> you >> can protect your company and customers by using code signing. >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Jsbsim-devel mailing list >> Jsb...@li... >> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel >> _______________________________________________ >> The JSBSim Flight Dynamics Model project >> http://www.JSBSim.org >> _______________________________________________ >> > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Jsbsim-devel mailing list > Jsb...@li... > https://lists.sourceforge.net/lists/listinfo/jsbsim-devel > _______________________________________________ > The JSBSim Flight Dynamics Model project > http://www.JSBSim.org > _______________________________________________ |
From: Ron J. <wi...@je...> - 2011-01-14 16:29:33
|
On Friday 14 January 2011 06:17:37 Scott Hamilton wrote: > Sure, I can't think of a good reason not to.. :) > > I also made the property values in both old Imperial and modern Metric. > > > > S. > I'm not trying to pick on Scott, since there are many instances of this practice, (might even be guilty myself) but isn't it really, really redundant to have the exact save value twice? Its simple enough to multiply lbm by 2.2 to get kg. It could be done by a function somewhere in the definition file when desired. But doing both Imperial and modern Metric could potentially double the size of the property tree for no really valid reason? Thanks, Ron |
From: Scott <sco...@pl...> - 2011-01-15 14:26:04
|
No offence taken Ron, it's also a fair point to bring up. The reason I added it was that it is not very effective to do this in Nasal in FG, but your idea of making it a function in the definition file sounds like something that needs to be explored, I'll give it a go on one of the aircraft I'm working on at the moment. I guess it also depends on the context of the property; that is, how widespread a measurement system is used for that value. For instance aviation fuels in this country are priced and delivered in litres or metric tonnes, and I'd suspect that is the case for many other countries, but altitudes still use the foot and long distances are in Nautical Miles (see ICAO Annex 5 amendments), just about everything else is in metric; runway lengths, visibility distances, barometric pressure, aircraft mass, etc, etc.. And given only three countries in the world (Burma, Liberia and USA) have not officially gone metric, it would make sense in the long-run to start changing over some of our (as in the sim world) measurements to metric, so perhaps I should drop the 'fuel-used-lbs' and just stick with the fuel-used-kg'. But I'll certainly give the function idea a try, I think I know what needs to be done.... cheers S. On Fri, 2011-01-14 at 09:29 -0700, Ron Jensen wrote: > On Friday 14 January 2011 06:17:37 Scott Hamilton wrote: > > Sure, I can't think of a good reason not to.. :) > > > > I also made the property values in both old Imperial and modern Metric. > > > > > > > > S. > > > > I'm not trying to pick on Scott, since there are many instances of this > practice, (might even be guilty myself) but isn't it really, really redundant > to have the exact save value twice? > > Its simple enough to multiply lbm by 2.2 to get kg. It could be done by a > function somewhere in the definition file when desired. But doing both > Imperial and modern Metric could potentially double the size of the property > tree for no really valid reason? > > Thanks, > Ron > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Jsbsim-devel mailing list > Jsb...@li... > https://lists.sourceforge.net/lists/listinfo/jsbsim-devel > _______________________________________________ > The JSBSim Flight Dynamics Model project > http://www.JSBSim.org > _______________________________________________ > |
From: dpculp <dp...@gm...> - 2011-01-15 18:43:54
|
English units have been the standard at JSBSim since day one, and that's very unlikely to change in our lifetime, so there is no point in tilting at windmills. The units will be pounds, and users will have to apply a conversion factor elsewhere, as with all the other properties. It works well. Dave Sent from my iPhone On Jan 15, 2011, at 7:25 AM, Scott <sco...@pl...> wrote: > > No offence taken Ron, it's also a fair point to bring up. > > The reason I added it was that it is not very effective to do this > in Nasal in FG, but your idea of making it a function in the > definition file sounds like something that needs to be explored, > I'll give it a go on one of the aircraft I'm working on at the moment. > > I guess it also depends on the context of the property; that is, > how widespread a measurement system is used for that value. > > For instance aviation fuels in this country are priced and > delivered in litres or metric tonnes, and I'd suspect that is the > case for many other countries, but altitudes still use the foot and > long distances are in Nautical Miles (see ICAO Annex 5 amendments), > just about everything else is in metric; runway lengths, visibility > distances, barometric pressure, aircraft mass, etc, etc.. > > And given only three countries in the world (Burma, Liberia and > USA) have not officially gone metric, it would make sense in the > long-run to start changing over some of our (as in the sim world) > measurements to metric, so perhaps I should drop the 'fuel-used-lbs' > and just stick with the fuel-used-kg'. > > But I'll certainly give the function idea a try, I think I know > what needs to be done.... > > > cheers > S. > > > > > On Fri, 2011-01-14 at 09:29 -0700, Ron Jensen wrote: >> >> On Friday 14 January 2011 06:17:37 Scott Hamilton wrote: >> > Sure, I can't think of a good reason not to.. :) >> > >> > I also made the property values in both old Imperial and modern >> Metric. >> > >> > >> > >> > S. >> > >> >> I'm not trying to pick on Scott, since there are many instances >> of this >> practice, (might even be guilty myself) but isn't it really, really >> redundant >> to have the exact save value twice? >> >> Its simple enough to multiply lbm by 2.2 to get kg. It could be >> done by a >> function somewhere in the definition file when desired. But doing >> both >> Imperial and modern Metric could potentially double the size of the >> property >> tree for no really valid reason? >> >> Thanks, >> Ron >> >> --- >> --- >> --- >> --------------------------------------------------------------------- >> Protect Your Site and Customers from Malware Attacks >> Learn about various malware tactics and how to avoid them. Understand >> malware threats, the impact they can have on your business, and how >> you >> can protect your company and customers by using code signing. >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Jsbsim-devel mailing list >> Jsb...@li... >> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel >> _______________________________________________ >> The JSBSim Flight Dynamics Model project >> http://www.JSBSim.org >> _______________________________________________ >> > > --- > --- > --- > --------------------------------------------------------------------- > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how > you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Jsbsim-devel mailing list > Jsb...@li... > https://lists.sourceforge.net/lists/listinfo/jsbsim-devel > _______________________________________________ > The JSBSim Flight Dynamics Model project > http://www.JSBSim.org > _______________________________________________ > |
From: Bertrand C. <bco...@gm...> - 2011-01-15 19:25:17
|
That was a nice try Scott :-) But life is sometimes unfair and Imperial units are a de facto standard in the aeronautic world. So, as Dave said, there is no reason why we should change that. Furthermore, there are some countries (like UK for instance) where, albeit official units are metric units, people are still using the Imperial system (speed limits are in mph, they measure their weight in stones, they order pints of beer and so on...). Furthermore, there can be much passion behind that (traditions preservation, time saving - it's easier not to learn a new system-, cost saving - changing the unit system would need to replace truck loads of sign posts -, etc.). So I guess we will have to continue live with that for a looong time. Anyway, I would happily trade the metric system for the Imperial system if the international language would become French. Any volunteers to support the cause ? :-) Cheers, Bertrand. 2011/1/15 dpculp <dp...@gm...>: > English units have been the standard at JSBSim since day one, and that's > very unlikely to change in our lifetime, so there is no point in tilting at > windmills. The units will be pounds, and users will have to apply a > conversion factor elsewhere, as with all the other properties. It works > well. > Dave > > Sent from my iPhone > On Jan 15, 2011, at 7:25 AM, Scott <sco...@pl...> wrote: > > > No offence taken Ron, it's also a fair point to bring up. > > The reason I added it was that it is not very effective to do this in > Nasal in FG, but your idea of making it a function in the definition file > sounds like something that needs to be explored, I'll give it a go on one of > the aircraft I'm working on at the moment. > > I guess it also depends on the context of the property; that is, how > widespread a measurement system is used for that value. > > For instance aviation fuels in this country are priced and delivered in > litres or metric tonnes, and I'd suspect that is the case for many other > countries, but altitudes still use the foot and long distances are in > Nautical Miles (see ICAO Annex 5 amendments), just about everything else is > in metric; runway lengths, visibility distances, barometric pressure, > aircraft mass, etc, etc.. > > And given only three countries in the world (Burma, Liberia and USA) have > not officially gone metric, it would make sense in the long-run to start > changing over some of our (as in the sim world) measurements to metric, so > perhaps I should drop the 'fuel-used-lbs' and just stick with the > fuel-used-kg'. > > But I'll certainly give the function idea a try, I think I know what needs > to be done.... > > > cheers > S. > > > > > On Fri, 2011-01-14 at 09:29 -0700, Ron Jensen wrote: > > On Friday 14 January 2011 06:17:37 Scott Hamilton wrote: >> Sure, I can't think of a good reason not to.. :) >> >> I also made the property values in both old Imperial and modern Metric. >> >> >> >> S. >> > > I'm not trying to pick on Scott, since there are many instances of this > practice, (might even be guilty myself) but isn't it really, really > redundant > to have the exact save value twice? > > Its simple enough to multiply lbm by 2.2 to get kg. It could be done by a > function somewhere in the definition file when desired. But doing both > Imperial and modern Metric could potentially double the size of the property > tree for no really valid reason? > > Thanks, > Ron > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Jsbsim-devel mailing list > Jsb...@li... > https://lists.sourceforge.net/lists/listinfo/jsbsim-devel > _______________________________________________ > The JSBSim Flight Dynamics Model project > http://www.JSBSim.org > _______________________________________________ > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > > _______________________________________________ > Jsbsim-devel mailing list > Jsb...@li... > https://lists.sourceforge.net/lists/listinfo/jsbsim-devel > _______________________________________________ > The JSBSim Flight Dynamics Model project > http://www.JSBSim.org > _______________________________________________ > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Jsbsim-devel mailing list > Jsb...@li... > https://lists.sourceforge.net/lists/listinfo/jsbsim-devel > _______________________________________________ > The JSBSim Flight Dynamics Model project > http://www.JSBSim.org > _______________________________________________ > > > |
From: Scott <sco...@pl...> - 2011-01-16 00:55:06
|
Yes true, it did become a bit tongue-in-cheek ;) But there is a serious side to that debate, not one I would expect to be resolved here, but the ICAO mandate the use of the metric SI system worldwide, with the use of the foot being allowed temporarily (I assume until the USA complete their metrication, whenever that may be...), so there is a "risk" in the future that the code-base will need to start delivering measurements in metric, I agree this doesn't look like it is going to happen anytime soon, given the US Metric Association has existed since 1916 and the US Metric Conversion Board was established in 1975 (I never knew the US was ever serious about the move to metric, even legalisation was passed!!) But for the reasons both you and Dave gave, I guess that is why it hasn't completely happened in real life, though as I pointed out, the only Imperial measurement used here is for altitude and long distances in aviation and that is true for many countries, where it is a hybrid Imperial/Metric system in aviation. It seems most countries move things relating to mass, pressure and short distances (eg: runways lengths) to metric, leaving only altitude and speed as the main Imperial measurements, then long distances and wind-speed can be either. I grew up with metric so I can't judge a foot by eye, but I'm fairly accurate with metres, I just go by the numbers. And quite a few pubs in major cities here sell pints, not as a real measure (it's officially banned), but just as a size of the holding vessel, same as the UK I believe are about to deregulate the size of beer drinking vessels, soon you too will have multiple different units available. Anyhow, back to Rons original point about pollution of the property tree, I'll come up with an example of how to do the conversion in the definition file, as I don't think a lot of the newer FG aircraft authors don't understand (or even look at) jsbsim files, so it does need an simple example to go along with it. S. On Sat, 2011-01-15 at 20:25 +0100, Bertrand Coconnier wrote: > That was a nice try Scott :-) But life is sometimes unfair and > Imperial units are a de facto standard in the aeronautic world. So, as > Dave said, there is no reason why we should change that. Furthermore, > there are some countries (like UK for instance) where, albeit official > units are metric units, people are still using the Imperial system > (speed limits are in mph, they measure their weight in stones, they > order pints of beer and so on...). Furthermore, there can be much > passion behind that (traditions preservation, time saving - it's > easier not to learn a new system-, cost saving - changing the unit > system would need to replace truck loads of sign posts -, etc.). So I > guess we will have to continue live with that for a looong time. > > Anyway, I would happily trade the metric system for the Imperial > system if the international language would become French. Any > volunteers to support the cause ? :-) > > Cheers, > > Bertrand. > > 2011/1/15 dpculp <dp...@gm...>: > > English units have been the standard at JSBSim since day one, and that's > > very unlikely to change in our lifetime, so there is no point in tilting at > > windmills. The units will be pounds, and users will have to apply a > > conversion factor elsewhere, as with all the other properties. It works > > well. > > Dave > > > > Sent from my iPhone > > On Jan 15, 2011, at 7:25 AM, Scott <sco...@pl...> wrote: > > > > > > No offence taken Ron, it's also a fair point to bring up. > > > > The reason I added it was that it is not very effective to do this in > > Nasal in FG, but your idea of making it a function in the definition file > > sounds like something that needs to be explored, I'll give it a go on one of > > the aircraft I'm working on at the moment. > > > > I guess it also depends on the context of the property; that is, how > > widespread a measurement system is used for that value. > > > > For instance aviation fuels in this country are priced and delivered in > > litres or metric tonnes, and I'd suspect that is the case for many other > > countries, but altitudes still use the foot and long distances are in > > Nautical Miles (see ICAO Annex 5 amendments), just about everything else is > > in metric; runway lengths, visibility distances, barometric pressure, > > aircraft mass, etc, etc.. > > > > And given only three countries in the world (Burma, Liberia and USA) have > > not officially gone metric, it would make sense in the long-run to start > > changing over some of our (as in the sim world) measurements to metric, so > > perhaps I should drop the 'fuel-used-lbs' and just stick with the > > fuel-used-kg'. > > > > But I'll certainly give the function idea a try, I think I know what needs > > to be done.... > > > > > > cheers > > S. > > > > > > > > > > On Fri, 2011-01-14 at 09:29 -0700, Ron Jensen wrote: > > > > On Friday 14 January 2011 06:17:37 Scott Hamilton wrote: > >> Sure, I can't think of a good reason not to.. :) > >> > >> I also made the property values in both old Imperial and modern Metric. > >> > >> > >> > >> S. > >> > > > > I'm not trying to pick on Scott, since there are many instances of this > > practice, (might even be guilty myself) but isn't it really, really > > redundant > > to have the exact save value twice? > > > > Its simple enough to multiply lbm by 2.2 to get kg. It could be done by a > > function somewhere in the definition file when desired. But doing both > > Imperial and modern Metric could potentially double the size of the property > > tree for no really valid reason? > > > > Thanks, > > Ron > > > > ------------------------------------------------------------------------------ > > Protect Your Site and Customers from Malware Attacks > > Learn about various malware tactics and how to avoid them. Understand > > malware threats, the impact they can have on your business, and how you > > can protect your company and customers by using code signing. > > http://p.sf.net/sfu/oracle-sfdevnl > > _______________________________________________ > > Jsbsim-devel mailing list > > Jsb...@li... > > https://lists.sourceforge.net/lists/listinfo/jsbsim-devel > > _______________________________________________ > > The JSBSim Flight Dynamics Model project > > http://www.JSBSim.org > > _______________________________________________ > > > > > > ------------------------------------------------------------------------------ > > Protect Your Site and Customers from Malware Attacks > > Learn about various malware tactics and how to avoid them. Understand > > malware threats, the impact they can have on your business, and how you > > can protect your company and customers by using code signing. > > http://p.sf.net/sfu/oracle-sfdevnl > > > > _______________________________________________ > > Jsbsim-devel mailing list > > Jsb...@li... > > https://lists.sourceforge.net/lists/listinfo/jsbsim-devel > > _______________________________________________ > > The JSBSim Flight Dynamics Model project > > http://www.JSBSim.org > > _______________________________________________ > > > > > > ------------------------------------------------------------------------------ > > Protect Your Site and Customers from Malware Attacks > > Learn about various malware tactics and how to avoid them. Understand > > malware threats, the impact they can have on your business, and how you > > can protect your company and customers by using code signing. > > http://p.sf.net/sfu/oracle-sfdevnl > > _______________________________________________ > > Jsbsim-devel mailing list > > Jsb...@li... > > https://lists.sourceforge.net/lists/listinfo/jsbsim-devel > > _______________________________________________ > > The JSBSim Flight Dynamics Model project > > http://www.JSBSim.org > > _______________________________________________ > > > > > > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Jsbsim-devel mailing list > Jsb...@li... > https://lists.sourceforge.net/lists/listinfo/jsbsim-devel > _______________________________________________ > The JSBSim Flight Dynamics Model project > http://www.JSBSim.org > _______________________________________________ > |
From: Scott H. <sco...@pl...> - 2011-01-18 12:55:50
|
Greetings all, OK, back to the problem at hand.. I'll re-post the patch for FGEngine etc with just "fuel-used-lbs" once I get the conversion function working. My initial thought was that the function should go in the <turbine_engine> definition I have in Trent900.xml, this seemed like a logical place, except I have no idea for which instance that XML is being run on, so I couldn't create a function just for that engine instance, is that correct? So my next place was as a child of <engine> within the <propulsion> definition of <fdm_config>, but that didn't seem to get executed at all, so I tried just as a child of <propulsion> this did seem to get executed, but too early so I got a property is not initially defined. So I then tried adding a <system file="metric-convert.xml"/> to the fdm_config and adding the functions below to that file, is this the best way to do this? It does indeed work, but I would have liked to not hard-code each engine index in there. <?xml version="1.0"?> <system name="metric-convert"> <function name="propulsion/engine[0]/fuel-flow-rate-kgps"> <product> <property>propulsion/engine[0]/fuel-flow-rate-pps</property> <value>0.45359237</value> </product> </function> <function name="propulsion/engine[1]/fuel-flow-rate-kgps"> <product> <property>propulsion/engine[1]/fuel-flow-rate-pps</property> <value>0.45359237</value> </product> </function> <function name="propulsion/engine[2]/fuel-flow-rate-kgps"> <product> <property>propulsion/engine[2]/fuel-flow-rate-pps</property> <value>0.45359237</value> </product> </function> <function name="propulsion/engine[3]/fuel-flow-rate-kgps"> <product> <property>propulsion/engine[3]/fuel-flow-rate-pps</property> <value>0.45359237</value> </product> </function> </system> |
From: Jon S. B. <jon...@co...> - 2011-01-18 13:56:10
|
> OK, back to the problem at hand.. I'll re-post the patch for FGEngine > etc with just "fuel-used-lbs" once I get the conversion function > working. Scott, Theoretically, this should be handled in the newer <function> capability in the engine definition files. It also depends on whether the function should be executed before the engine model code, or after (or maybe it doesn't matter). You would put this in your engine model definition: <function name="propulsion/engine[#]/fuel-flow-rate-kgps" type="post"> <product> <property>propulsion/engine[#]/fuel-flow-rate-pps</property> <value>0.45359237</value> </product> </function> Incidentally, the <property> and <value> tags can be used with a shorthand <p> and <v>, respectively: <function name="propulsion/engine[#]/fuel-flow-rate-kgps" type="post"> <product> <p> propulsion/engine[#]/fuel-flow-rate-pps </p> <v> 0.45359237 </v> </product> </function> It doesn't matter where in the turbine engine definition you put the <function> (top or bottom), but the "type" attribute should be either "pre" or "post" depending on whether you want the function to execute before or after the engine model code. Try this and see if it does what you want. This is a newer capability and has been lightly tested, so there might potentially be some issues. Jon |
From: Scott H. <sco...@pl...> - 2011-01-19 13:33:55
Attachments:
jsbsim-turbine_2010-01-20_01.patch
|
Thanks Jon, That new format is exactly what I was after :) So please find the patch file for new tied property /bleed-factor and /fuel-used-lbs and a fix for calling EngineResetIC() in the parent class for FGTurbine.cpp S. |
From: Jon S. B. <jon...@co...> - 2011-01-20 04:49:51
|
Is this patch to be applied to current JSBSim code as it is in CVS? Does it depend on one of your previous patches? Jon > -----Original Message----- > From: Scott Hamilton [mailto:sco...@pl...] > Sent: Wednesday, January 19, 2011 7:33 AM > To: Development issues > Subject: Re: [Jsbsim-devel] effect of bleed air extraction for external > use in jsbsim turbine engine. > > Thanks Jon, > > That new format is exactly what I was after :) > > So please find the patch file for new tied property /bleed-factor and > /fuel-used-lbs and a fix for calling EngineResetIC() in the parent > class for FGTurbine.cpp > > > > S. |
From: Scott H. <sco...@pl...> - 2011-01-20 05:29:55
|
Hi ya Jon, It was made against the current HEAD of CVS. This replaces the previous patches, they are all the same functionality, it has just been refined by the discussions here. So this is in effect the final patch I think. I haven't actually tested it, so it needs someone to do a sanity check on it first. Cheers S. On Wed, 19 Jan 2011 22:49:49 -0600, "Jon S. Berndt" <jon...@co...> wrote: > Is this patch to be applied to current JSBSim code as it is in CVS? Does > it depend on one of your previous patches? > > Jon > > >> -----Original Message----- >> From: Scott Hamilton [mailto:sco...@pl...] >> Sent: Wednesday, January 19, 2011 7:33 AM >> To: Development issues >> Subject: Re: [Jsbsim-devel] effect of bleed air extraction for external >> use in jsbsim turbine engine. >> >> Thanks Jon, >> >> That new format is exactly what I was after :) >> >> So please find the patch file for new tied property /bleed-factor and >> /fuel-used-lbs and a fix for calling EngineResetIC() in the parent >> class for FGTurbine.cpp >> >> >> >> S. > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Jsbsim-devel mailing list > Jsb...@li... > https://lists.sourceforge.net/lists/listinfo/jsbsim-devel > _______________________________________________ > The JSBSim Flight Dynamics Model project > http://www.JSBSim.org > _______________________________________________ |
From: dpculp <dp...@gm...> - 2011-01-14 15:40:40
|
Sounds like you're working on an Airbus. I can send you pics/info if you need any. Also, the Airbus E/WD displays the fuel used from the previous flight until engine start. Since there is no previous flight in the sim world, you may want to insert a fake value after FDM initialization. Dave Sent from my iPhone On Jan 14, 2011, at 5:17 AM, Scott Hamilton <sco...@pl...> wrote: > > > Sure, I can't think of a good reason not to.. :) > > I also made the property values in both old Imperial and modern > Metric. > > > > S. > > > > > On Fri, 14 Jan 2011 04:25:39 -0800, dpculp <dp...@gm...> wrote: >> I think the "Total" part of TotalFuelUsed is superfluous. Can we go >> with just "FuelUsed"? >> >> Dave >> >> Sent from my iPhone >> >> On Jan 13, 2011, at 8:45 PM, Scott <sco...@pl...> wrote: >> >>> >>> >>> Many thanks Dennis. I've redone the patch taking into account all >>> your >>> good suggestions. >>> I should have added to the ResetToIC() method, but in my haste I >>> didn't >>> stop to think about it... >>> If anyone can do a sanity check on it, I'd be pleased to hear back >>> from >>> them. >>> >>> >>> cheers >>> Scott. >>> >>> >>> >>> >>> >>> On Thu, 13 Jan 2011 21:44:14 -0600, "Dennis J. Linse" >>> <js...@li...> >>> wrote: >>>> Scott, >>>> >>>> There are those of use out here that might be able to apply your >>>> patch >>>> to our local copy and try it. And there are the big, important >>>> guys ;-) >>>> that can apply it and commit it to the CVS repository. >>>> >>>> Just looking at your patch and the current code generates a >>>> couple of >>>> questions, one partially under your control, and one that I noticed >>>> while following how your change might work: >>>> >>>> 1) I think it would be a good idea if your patch set the value of >>>> TotalFuelUsed to zero at initialization (or reset). I think that >>>> this >>>> might be best accomplished in ResetToIC(). Otherwise TotalFuelUsed >>>> would accumulate across different runs of the same instance, even >>>> if >>>> everything else reset. >>>> >>>> 2) While looking how RestToIC() is used in FGEngine, I see it is >>>> overridden in FGPiston and FGTurbine. Fair enough. What I also >>>> see is >>>> that in FGPiston the FGEngine::ResetToIC() is called. This is >>>> *not* >>>> done in FGTurbine::ResetToIC(). I think this is a potential >>>> mistake. >>>> >>>> If you redo your patch, could you add that as well? >>>> >>>> Oh, and one other thing: patch files should be made relative to the >>>> top >>>> of the JSBSim directory so that they can be applied with a single >>>> command like this: >>>> >>>> cd where/I/keep/JSBSim >>>> patch -p0 <a_better_mousetrap.patch >>>> >>>> >>>> Your patch wouldn't have lines like this: >>>> >>>> --- FGTurbine.cpp 31 Aug 2010 04:01:32 -0000 1.29 >>>> +++ FGTurbine.cpp 14 Jan 2011 02:32:26 -0000 >>>> >>>> >>>> but rather like this: >>>> >>>> --- src/models/propulsion/FGTurbine.cpp 31 Aug 2010 04:01:32 >>>> -0000 >>>> 1.29 >>>> +++ src/models/propulsion/FGTurbine.cpp 14 Jan 2011 02:32:26 >>>> -0000 >>>> >>>> >>>> Dennis >>>> >>>> On 2011-01-13 8:48 PM, Scott wrote: >>>>> Hi ya Dave, >>>>> >>>>> >>>>> Having never made a source-code patch (or written a line of C+ >>>>> +) I >>>>> decided to give this a try, since it seemed simple enough. >>>>> The attached file seems to compile OK, and given it's small size >>>>> and >>>>> simplicity gives me high hopes that it would actually work, but >>>>> I'm not >>>>> sure how to test it... >>>>> If the attached file is in the proper patch format, where should >>>>> it >>> go >>>>> next? >>>>> >>>>> >>>>> Cheers >>>>> Scott. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, 13 Jan 2011 13:57:25 -0800, David Culp <dav...@co...> >>> wrote: >>>>>> On Thu, 13 Jan 2011 11:23:09 +1100 >>>>>> Scott <sco...@pl...> wrote: >>>>>> >>>>>>> ... if one wanted to allow run-time modification of the >>>>>>> bleedDemand value from within FlightGear ... >>>>>> >>>>>> >>>>>> In this case all that's needed is to expose the bleed variable to >>>>>> the >>>>>> property tree from within FGTurbine, resulting in a property such >>>>>> as: >>>>>> propulsion/engine[n]/bleed-factor, which would be >>>>>> fdm/jsbsim/propulsion/engine[n]/bleed-factor from within >>>>>> FlightGear. >>>>>> >>>>>> I'm all for this, but I won't be able to get to it for a couple >>>>>> weeks. >>>>>> >>>>>> >>>>>> >>>>>>> I assume this arrives at the FlightGear codebase directly from >>>>> JSBsim >>>>>>> codebase, so to do this I would need to make a patch here rather >>>>>>> than >>>>> in >>>>>>> FG? >>>>>> >>>>>> Erik Hofman periodically cuts over the latest JSBSim code to >>> FlightGear. >>>>>> >>>>>> >>>>>>> If I do that I might see if I can work out how to keep track of >>>>> total >>>>>>> fuel used by each engine (just cumulative of the fuel flow, I >>>>>>> guess), >>>>>>> it's a common monitoring value in modern glass cockpits. >>>>>> >>>>>> That's also a good idea. This could easily be added to >>>>>> FGEngine::ConsumeFuel(), and the fuel_used value exposed to the >>> property >>>>>> tree by FGEngine. I'll work on it in a couple weeks, unless >>>>>> someone >>>>> beats >>>>>> me to it. >>>>>> >>>>>> >>>>>>> I notice you mention the value 0.04 as a common value, looking >>>>>>> at >>> the >>>>>>> EASA Type Certification data sheets, they mention bleed values >>>>>>> of 5%, >>>>>>> that would give a value of 0.2 (normalised) that seems much >>>>>>> higher, >>> is >>>>>>> that an unrealistic number? >>>>>> >>>>>> In FGTurbine, 0.04 is treated as 4%, i.e. the resulting thrust >>>>>> factor >>>>>> would be 1 - 0.04, or 96%. >>>>>> >>>>>> >>>>>> Dave >>>>>> >>>>>> >>>>>> >>>>> >>> --- >>> --- >>> --- >>> --- >>> ------------------------------------------------------------------ >>>>>> Protect Your Site and Customers from Malware Attacks >>>>>> Learn about various malware tactics and how to avoid them. >>>>>> Understand >>>>>> malware threats, the impact they can have on your business, and >>>>>> how >>> you >>>>>> can protect your company and customers by using code signing. >>>>>> http://p.sf.net/sfu/oracle-sfdevnl >>>>>> _______________________________________________ >>>>>> Jsbsim-devel mailing list >>>>>> Jsb...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel >>>>>> _______________________________________________ >>>>>> The JSBSim Flight Dynamics Model project >>>>>> http://www.JSBSim.org >>>>>> _______________________________________________ >>>>>> >>>>>> >>>>>> >>> --- >>> --- >>> --- >>> --- >>> ------------------------------------------------------------------ >>>>>> Protect Your Site and Customers from Malware Attacks >>>>>> Learn about various malware tactics and how to avoid them. >>>>>> Understand >>>>>> malware threats, the impact they can have on your business, and >>>>>> how >>> you >>>>>> can protect your company and customers by using code signing. >>>>>> http://p.sf.net/sfu/oracle-sfdevnl >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Jsbsim-devel mailing list >>>>>> Jsb...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel >>>>>> _______________________________________________ >>>>>> The JSBSim Flight Dynamics Model project >>>>>> http://www.JSBSim.org >>>>>> _______________________________________________ >>>>>> >>>> >>>> >>> --- >>> --- >>> --- >>> --- >>> ------------------------------------------------------------------ >>>> Protect Your Site and Customers from Malware Attacks >>>> Learn about various malware tactics and how to avoid them. >>>> Understand >>>> malware threats, the impact they can have on your business, and how >>>> you >>>> can protect your company and customers by using code signing. >>>> http://p.sf.net/sfu/oracle-sfdevnl >>>> _______________________________________________ >>>> Jsbsim-devel mailing list >>>> Jsb...@li... >>>> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel >>>> _______________________________________________ >>>> The JSBSim Flight Dynamics Model project >>>> http://www.JSBSim.org >>>> _______________________________________________ >>> <jsbsim-turbine_2010-01-14_02.patch> >>> --- >>> --- >>> --- >>> --- >>> ------------------------------------------------------------------ >>> Protect Your Site and Customers from Malware Attacks >>> Learn about various malware tactics and how to avoid them. >>> Understand >>> malware threats, the impact they can have on your business, and how >>> you >>> can protect your company and customers by using code signing. >>> http://p.sf.net/sfu/oracle-sfdevnl >>> _______________________________________________ >>> Jsbsim-devel mailing list >>> Jsb...@li... >>> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel >>> _______________________________________________ >>> The JSBSim Flight Dynamics Model project >>> http://www.JSBSim.org >>> _______________________________________________ >>> >> >> > --- > --- > --- > --------------------------------------------------------------------- >> Protect Your Site and Customers from Malware Attacks >> Learn about various malware tactics and how to avoid them. Understand >> malware threats, the impact they can have on your business, and how >> you >> can protect your company and customers by using code signing. >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Jsbsim-devel mailing list >> Jsb...@li... >> https://lists.sourceforge.net/lists/listinfo/jsbsim-devel >> _______________________________________________ >> The JSBSim Flight Dynamics Model project >> http://www.JSBSim.org >> _______________________________________________ > <jsbsim-turbine_2010-01-15_01.patch> > --- > --- > --- > --------------------------------------------------------------------- > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how > you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Jsbsim-devel mailing list > Jsb...@li... > https://lists.sourceforge.net/lists/listinfo/jsbsim-devel > _______________________________________________ > The JSBSim Flight Dynamics Model project > http://www.JSBSim.org > _______________________________________________ > |
From: Anders G. <and...@gi...> - 2011-01-14 16:08:12
|
On Fri, 14 Jan 2011, dpculp wrote: > Sounds like you're working on an Airbus. I can send you pics/info if > you need any. > > Also, the Airbus E/WD displays the fuel used from the previous flight > until engine start. Since there is no previous flight in the sim > world, you may want to insert a fake value after FDM initialization. FlightGear has a mechanism for persistent aircraft state which could be used for that.. :) It is currently used for hobbs counters, remembering the last used livery etc. See the data "class" in fgdata/Nasal/aircraft.nas for more info. Cheers, Anders -- --------------------------------------------------------------------------- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ |
From: Jon S. B. <jon...@co...> - 2011-01-16 02:07:29
Attachments:
winmail.dat
|
Hi, Scott and all, As for me, I’m sensitive to the concerns about the use of metric units. JSBSim – like FlightGear – has an international team of developers and users. I’m actually comfortable with metric units = even know some of the conversion values by memory. But, there had to be a primary unit system chosen for internal use at the beginning, and that was the English system due to our greater familiarity with that system at the time. As you know, we support the input of many items in either system, and as I recall we support some unit conversions in the output of values, as well. Most or all properties are in English units. Unfortunately, I don’t think it would be very “clean” to add a metric counterpart to each property. I’m afraid there’ s not a good way to add better support for SI units without more messiness. But, if anyone can think of a good way, I’d be interested to see that. Jon |
From: Scott <sco...@pl...> - 2011-01-16 16:22:53
|
Sorry to consume so much bandwidth on this topic, which was accidental anyway. But it has piqued my interest, and please don't get me wrong, I'm not trying to convert the world to Metric, or even suggesting that we should change everything over to SI, I just find it a interesting problem, that I suspect will require more attention as time goes on. So given that it is mainly the instruments themselves that need to do the conversion (whether they are steam instruments or glass cockpit instruments) what would be nice, would be if we could store objects in the property tree that are just wrappers of the class instances in the C ++ space. If one had; Mass, Pressure, Distance, Airspeed, Temperature object classes for instance, these could have .getSI() or .getImperial() or perhaps more specific .getKg() or .getInHG() type of methods, which would just map from a property syntax of "/a/b/kg" to get instance b and call .getKg() on that instance. In C++ land the same object classes would need to replace the double or float values, that is the downside (and would require a lot of work). This would firstly abstract the measurement system, so it could easily be swapped in or out, and secondly it would push the conversion closer to the point of decision of what measurement system is needed. That is only way I can think of not increasing the number of property nodes but allowing multiple measurements systems easily. Unfortunately SGPropertyNode doesn't support objects. And I know that standards are enacted by national standards bodies, but can we only use the BIPM spellings of metre and litre, as a meter is a different word altogether; either a noun; a device that measures and records the quantity, degree , or rate of something eg: a parking meter, an electricity meter, a light meter or a verb; measure by means of a meter so you can use a metre meter to meter metres. S. On Sat, 2011-01-15 at 20:07 -0600, Jon S. Berndt wrote: > Hi, Scott and all, > > As for me, I’m sensitive to the concerns about the use of metric units. > JSBSim – like FlightGear – has an international team of developers and > users. I’m actually comfortable with metric units = even know some of the > conversion values by memory. But, there had to be a primary unit system > chosen for internal use at the beginning, and that was the English system > due to our greater familiarity with that system at the time. As you know, we > support the input of many items in either system, and as I recall we support > some unit conversions in the output of values, as well. Most or all > properties are in English units. Unfortunately, I don’t think it would be > very “clean” to add a metric counterpart to each property. I’m afraid there’ > s not a good way to add better support for SI units without more messiness. > But, if anyone can think of a good way, I’d be interested to see that. > > Jon > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ Jsbsim-devel mailing list Jsb...@li... https://lists.sourceforge.net/lists/listinfo/jsbsim-devel _______________________________________________ The JSBSim Flight Dynamics Model project http://www.JSBSim.org _______________________________________________ |
From: Bertrand C. <bco...@gm...> - 2011-01-16 16:51:44
|
Speaking about C++ syntactic sugar, I made a small review some months ago about what C++ could do to help us dealing with units (and especially with conversion between SI and English). I discovered a couple of libraries that define C++ templates that are able to give a dimension (length, time, mass, etc. as well as their combination such as speed, energy, etc.) to any variable and to check the dimension consistency in an expression at compile time. There is an article there http://www.oonumerics.org/tmpw01/brown.pdf which describes very well how that can be handled with C++ templates. And there is also a Boost C++ library which is dedicated to that: http://www.boost.org/doc/libs/1_45_0/doc/html/boost_units.html These are very smart approaches and having dimension check at compile time with no additional code in the binary is quite an impressive achievement of these libraries. Conversion between units also seem to be done automatically. At least, this is my understanding of what they are doing, I never conducted any serious test to see what are their real capabilities. However, using these libraries would add a dependency to JSBSim which is not very good. And developing our own is quite a substantial effort, even if we limit ourselves to a subset of these libraries capacities. Furthermore, I do not feel English units are so much of an issue that we would absolutely need to go down that path. But opinions may differ. Cheers, Bertrand. 2011/1/16 Scott <sco...@pl...>: > > > Sorry to consume so much bandwidth on this topic, which was accidental > anyway. But it has piqued my interest, and please don't get me wrong, I'm > not trying to convert the world to Metric, or even suggesting that we should > change everything over to SI, I just find it a interesting problem, that I > suspect will require more attention as time goes on. > > So given that it is mainly the instruments themselves that need to do the > conversion (whether they are steam instruments or glass cockpit instruments) > what would be nice, would be if we could store objects in the property tree > that are just wrappers of the class instances in the C++ space. > > If one had; Mass, Pressure, Distance, Airspeed, Temperature object classes > for instance, these could have .getSI() or .getImperial() or perhaps more > specific .getKg() or .getInHG() type of methods, which would just map from a > property syntax of "/a/b/kg" to get instance b and call .getKg() on that > instance. > > In C++ land the same object classes would need to replace the double or > float values, that is the downside (and would require a lot of work). This > would firstly abstract the measurement system, so it could easily be swapped > in or out, and secondly it would push the conversion closer to the point of > decision of what measurement system is needed. > > That is only way I can think of not increasing the number of property > nodes but allowing multiple measurements systems easily. Unfortunately > SGPropertyNode doesn't support objects. > > And I know that standards are enacted by national standards bodies, but > can we only use the BIPM spellings of metre and litre, as a meter is a > different word altogether; > > either a noun; > a device that measures and records the quantity, degree , or rate of > something > eg: a parking meter, an electricity meter, a light meter > > or a verb; > measure by means of a meter > > so you can use a metre meter to meter metres. > > > > S. > > > On Sat, 2011-01-15 at 20:07 -0600, Jon S. Berndt wrote: > > Hi, Scott and all, > > As for me, I’m sensitive to the concerns about the use of metric units. > JSBSim – like FlightGear – has an international team of developers and > users. I’m actually comfortable with metric units = even know some of the > conversion values by memory. But, there had to be a primary unit system > chosen for internal use at the beginning, and that was the English system > due to our greater familiarity with that system at the time. As you know, we > support the input of many items in either system, and as I recall we support > some unit conversions in the output of values, as well. Most or all > properties are in English units. Unfortunately, I don’t think it would be > very “clean” to add a metric counterpart to each property. I’m afraid there’ > s not a good way to add better support for SI units without more messiness. > But, if anyone can think of a good way, I’d be interested to see that. > > Jon > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ Jsbsim-devel mailing list > Jsb...@li... > https://lists.sourceforge.net/lists/listinfo/jsbsim-devel > _______________________________________________ The JSBSim Flight Dynamics > Model project http://www.JSBSim.org > _______________________________________________ > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Jsbsim-devel mailing list > Jsb...@li... > https://lists.sourceforge.net/lists/listinfo/jsbsim-devel > _______________________________________________ > The JSBSim Flight Dynamics Model project > http://www.JSBSim.org > _______________________________________________ > > > |