#2394 Tutorials: value comparison inconsistent with checklists; errors in log.

Tutorial execution refuses to compare a nil against a number and gets stuck and complains if a non-existing or empty property (showing up like '' (none) in browser) is compared against something. This is unlike checklist window, which behaves "less correctly" but "more intuitively" and simply treats nil as zero.

Side observation: JSBSim recently (less than half a year ago or so) started making empty properties instead of doubles if <property>/asd/fgh</property> without a value="0.0". While not related, this is how I found the problem with tutorials, and this might break tutorials in other aircraft that define inputs via their JSBSim file without forcing their initial value. Is the new behaviour a regression in JSBSim or intended?

1. Put this in <checklists>of any aircraft:

 <group>
  <name>test</name>
  <checklist>
   <title>test</title>
   <page>
    <item>
     <name>asd</name>
     <value>fgh</value>
     <condition>
       <less-than>
        <property>asd/fgh</property>
        <value>0.1</value>
       </less-than>
     </condition>
    </item>
   </page>
  </checklist>
 </group>

1. Fire up tutorial and open Checklists window for the corresponding checklist. Browse /asd in property tree.

2. The tutorial will get stuck, with the following error repeating over and over in the log:

  124.19 [ALRT]:nasal      condition: comparing with nil
  124.19 [INFO]:nasal      less-than {NONE} = nil
  124.19 [INFO]:nasal      less-than/property {STRING} = asd/fgh
  124.19 [INFO]:nasal      less-than/value {STRING} = 0.1

but the item will show up as "done" in the Checklists window.

[James Turner]

@bcoconni See above for a question about a JSBsim change.

Michael, in general for 'is this an intentional change' questions, better to ask on the devel list, with JSBsim in th subject, Betrand follows the list but not every single email, I believe.

[Anonymous]

Sorry, will do that in the future.

[Bertrand Coconnier]

Side observation: JSBSim recently (less than half a year ago or so) started making empty properties instead of doubles if <property>/asd/fgh</property> without a value="0.0". While not related, this is how I found the problem with tutorials, and this might break tutorials in other aircraft that define inputs via their JSBSim file without forcing their initial value. Is the new behaviour a regression in JSBSim or intended?

@mike402 That's weird since this feature has not been modified in JSBSim since at least Apr 27, 2019.
The code at stake is in src/FDM/JSBSim/input_ouput/FGPropertyReader.cpp (lines 79-83) where properties default value is set to 0.0( unless a value parameter is provided).

  while (property_element) {
    SGPropertyNode* node = nullptr;
    double value=0.0;
    if ( ! property_element->GetAttributeValue("value").empty())
      value = property_element->GetAttributeValueAsNumber("value");

Could you please provide an example that triggers the behavior you are reporting ?

[Anonymous]

Weird, indeed, because never saw empty properties before around last summer.

Two JSBSim systems are defining reverser lever input because they both use it:
https://gitlab.com/mdanil/Tu-144/-/blob/bc6530e7f354509882a97135916d42eeaef90261/Tu-144-jsbsim/propulsion/RD-36_0.xml#L49
https://gitlab.com/mdanil/Tu-144/-/blob/bc6530e7f354509882a97135916d42eeaef90261/Tu-144-jsbsim/propulsion/RD-36-reverser_0.xml#L11
Then this line of tutorial gets a NIL instead of 0.0 and gets stuck:
https://gitlab.com/mdanil/Tu-144/-/blob/bc6530e7f354509882a97135916d42eeaef90261/Doc/Tu-144D-checklists.xml#L1894
Somehow even if I add value=0.0 to either system or both, it still ends up empty until I move the levers at least once.

I managed to force it to be a double via -set.xml, which is a kludge, of course:
https://gitlab.com/mdanil/Tu-144/-/commit/bcc1ec39b1b0254f639c8fc6297d9cd360e4936a

I will try to make a more minimal example of what is happening tomorrow.

[Bertrand Coconnier]

I uploaded the Tu-144 on my PC and ran FlightGear. It gave these warnings (among many others of the same kind):

In file /home/bertrand/.fgfs/Aircraft/com.gitlab.users.mdanil/Aircraft/Tu-144/Tu-144-jsbsim/propulsion/RD-36_0.xml: line 49
      Property propulsion/engine[0]/panel/lever/reverser/pos-deg is already defined.

In file /home/bertrand/.fgfs/Aircraft/com.gitlab.users.mdanil/Aircraft/Tu-144/Tu-144-jsbsim/propulsion/RD-36-reverser_0.xml: line 11
      Property propulsion/engine[0]/panel/lever/reverser/pos-deg is already defined.

which means that these 2 properties have already been defined elsewhere when JSBSim reaches the 2 lines that you mentioned above. In such a case, JSBSim leave the properties as they are and move to the next statement in the XML file. If the properties contain garbage at this stage, then they will still contain garbage after JSBSim has processed the statements (see the source code in file src/FDM/JSBSim/src/input_output/FGPropertyReader.cpp lines 104-110

      else {
        cerr << property_element->ReadFrom()
             << "      Property " << interface_property_string 
             << " is already defined." << endl;
    property_element = el->FindNextElement("property");
    continue;
      }

I guess your best course of action is to look for the place where these properties are initially defined and check what happens there.

[Bertrand Coconnier]

In case someone asks: the code above from src/FDM/JSBSim/src/input_output/FGPropertyReader.cpp has not been modified for 7 years.

[Anonymous]

Indeed, looking at the errors (which are inevitable, given how I have to define inputs of each system using <property>) RD-36_0 and RD-36-reverser_0 both show that error, instead of only RD-36-reverser_0, which means they both are ignored, instead of the value being taken from the first file, and that is why the property ends up empty.

To make sure nothing else defines it, here's a search for that lever pos-deg (ignore engines 1 and 2 because they do not have reversers but still have that property for simplicity):

Tu-144 > grep -Ri "property>.*lever/reverser/pos-deg" Tu-144-jsbsim 
Tu-144-jsbsim/propulsion/RD-36_2.xml: <property>&U;/panel/lever/reverser/pos-deg</property>
Tu-144-jsbsim/propulsion/RD-36-reverser_0.xml: <property>&U;/panel/lever/reverser/pos-deg</property>
Tu-144-jsbsim/propulsion/RD-36_3.xml: <property>&U;/panel/lever/reverser/pos-deg</property>
Tu-144-jsbsim/propulsion/RD-36_1.xml: <property>&U;/panel/lever/reverser/pos-deg</property>
Tu-144-jsbsim/propulsion/RD-36-reverser_3.xml: <property>&U;/panel/lever/reverser/pos-deg</property>
Tu-144-jsbsim/propulsion/RD-36_0.xml: <property>&U;/panel/lever/reverser/pos-deg</property>

Which means for engine 0 there's only 2 files that mention it. I will try to look for the property in more places, but it seems that is all.

[Bertrand Coconnier]

I found there are files outside Tu-144-jsbsim that uses the property:

> find . -type f -name '*.xml' -exec grep -l 'reverser/pos-deg' {} \;
./PRules/animations-console.xml
./Systems/Tu-144-keyboard.xml
./Systems/Tu-144-checklists.xml
./Systems/flightrecorder/Tu-144-cockpit.xml
./Tu-144-jsbsim/propulsion/RD-36_2.xml
./Tu-144-jsbsim/propulsion/RD-36_1.xml
./Tu-144-jsbsim/propulsion/RD-36_3.xml
./Tu-144-jsbsim/propulsion/RD-36-reverser_3.xml
./Tu-144-jsbsim/propulsion/RD-36_0.xml
./Tu-144-jsbsim/propulsion/RD-36-reverser_0.xml

If one of the 4 first files of the list above is parsed before the JSBSim model then the property is most likely defined there.

[Anonymous]

Indeed, and if JSBSim is initialized after those things, any <property> in JSBSim model gets disrespected, unlike if it were to run standalone.

This is counter-intuitive imho. Why not initialize JSBSim first?

[Bertrand Coconnier]

This is counter-intuitive imho. Why not initialize JSBSim first?

@jmturner, I guess the ball is back in your court now :-)

[Anonymous]

Sorry about stirring up the init again right when it seems to have settled... :'(

[Anonymous]

I just found what results in empty properties being created before JSBSim: property rules that use them as input:

 <filter>
  <type>gain</type>
  <gain>1.0</gain>
  <input>/fdm/jsbsim/propulsion/engine[0]/panel/lever/reverser/pos-deg</input>
  <output>/instrumentation/jsbsim/propulsion/engine[0]/panel/lever/reverser/pos-deg</output>
 </filter>

Property rules somehow end up initializing sooner than JSBSim and create empty properties before JSBSim tries to create them.

[James Turner]

Unfortunately it's historical that we initialise the FDMs quite late; the problem is they need the scenery loaded to determine ground evlevation for trimming.

I don't think we change that ordering, or at least, it would be far down my things I want to consider for a peaceful life. However, the ordering has also not changed in /forever/, so that cannot be the reason for a new bug.

Why is it a problem, if the property-rules initialise the value before JSBsim? Surely JSBims will over-write the value on its own init?

[Anonymous]

Strange, but it doesn't overwrite. Maybe it only checks if a property already exists, rather than checking if the property has been created by it, and not externally (which would probably be too complicated?).

[Bertrand Coconnier]

Why is it a problem, if the property-rules initialise the value before JSBsim? Surely JSBims will over-write the value on its own init?

JSBSim does not overwrite because it assumes that when properties are already defined, it is on purpose. The other option would have been to assume that the world starts when JSBSim starts and that whatever happened before is irrelevant. In such a scenario JSBSim would overwrite all the properties that it uses but I guess some users would then have complained that they had to set the data twice for an aircraft that had 2 FDMs (say JSBSim and YASim for example) or something like that.

Unfortunately, there is no option that fits everyone needs and JSBSim took the assumption that those who first set properties know what they are doing. It has been so for years (if not decades) and switching to another assumption would be a major breach to our backward compatibility.

[Anonymous]

Fine, then. I'll just stop using property rules for those things.

[James Turner]

@mike402 it's okay that you have a work-around but I'm still confused why the bug is new: as far as I know, the property-rules code did not change; Bertrand says the JSBsim behaviour has not changed, and the FDM init order has not changed for sure. So, whatever we have today, is /also/ what we had five years ago. (or, it should be)

Therefore if something is recently broken (in the last twelve months), it's an unintentional regression caused by something else, and we should probably try to figure it out, since it will affect other aircraft in the same way.

[Anonymous]

I think it could be that reverser lever has always been empty and just went unnoticed because everything beside tutorials treated the empty property as "0.0". I will try to build earlier versions of FG to see if the issue is still there.

[James Turner]

That would be really helpeful; I think just checking 2018 would be sufficient, since if the behaviour was rthe same in 2018, and no one complained, I think wwe can assume it's also the same before as well.

If you find 2018 (or older) is the same, then I'm afraid we will just have to accept it as 'the way things' are; not ideally, but certainly not good to change it now. Only possiblity I can suggest would be to add a flag to either JSBSim or property-rules, which says something like 'set-initial-value=true/false'; that would let you make a new consistent behaviour in a backwards compatbile way.

Bertrand, I guess this would be doable from your side as well, so we could even make /both/ places support a 'set-initial-value' flag?

[Anonymous]

2019.1 and 2018.3 fill reverser pos-deg with double 0.0 instead of none '', but still gives 2 JSBSim errors, that means something other than JSBSim changed. Maybe property rules used to initialize their inputs but now only create them?

[James Turner]

Doing some checking: I can't find an intentional change in the property-rules code.

I did find some 'initialize-to' option in the <filter> element, it can initalise to the input, output or none. The default behaviour is to initalize to the input value, whatever that is.</filter>

All of this code is unchanged in 7 years, so .. something strange is happening. There were some renaming of items in the last two years but none of that was supposed to change any behaviour, of course

[Anonymous]

Whoa, I just realized I had reverted the wrong commits in my aircraft, which left the workaround in. 🤦

Checked again properly, 2019.1 and 2018.3 indeed putnone '' the same as 2020.x. So it has been aircraft-side bug all along. Sorry about the noise!

Only the main issue with tutorial system is there.

[James Turner]

Okay that's good to hear. I think the original issue maybe got lost in thsi discusison, can you remind @stuartbuchanan the problem to look at?