Components views changed in v1.16.2

[anonymous]

The components are misplaced misplaced and their views changed in Diagram Viem in v1.16.2.

Attached are the screen shots of 2 Modelica.Fluid examples.

OS: Win7 64 Bit
OM version: 1.16.2

[stephan.fevrier]

Same also applies also to v1.16.2 and the latest nightly build on Ubuntu 20.04.1 LTS. I reported the issue here:
​https://github.com/OpenModelica/OpenModelica/issues/7060

[casella]

The issue is not present in v1.17.0-dev-281-g1a53775ae8 (13 Dec 2020). It was probably introduced later.

It seems that the order of components is scrambled up: boundary1 shows up in place of system, heat2 instead of ramp1, etc.

[casella]

See also #6310

[casella]

I just tried the latest Windows nightly v1.17.0-dev-313-g0591e00b90 on Win 10 but I had no such problem.

I turned "Enable new frontend use in the OMC API" on and off (restarting OMEdit), but that didn't change the situation.

[casella]

I tried to reproduce the issue on Windows 10, using the 1.16.2 64-bit released version, and using the 1.17.0-dev-301 and 1.17.0-dev-313 releases. According to the ​1.16 maintenance commit history and ​master commit history, all three include the commits ​fd2a6cf and ​ee13cc6 that are the most likely culprits. However, I always got the correct result and couldn't reproduce the faulty diagrams.

Maybe you have some other setting that is interfering badly with -d=nfAPI. Can you please select Tools | Options, press the Reset button, that resets all settings to default, restart OMEdit and then report what happens?

[casella]

See also #6313

[Bruno PERMANNE <bruno.permanne@…>]

"Maybe you have some other setting that is interfering badly with -d=nfAPI. Can you please select Tools | Options, press the Reset button, that resets all settings to default, restart OMEdit and then report what happens?"

I did it, it happens nothing new on:
Linux Mint 19/20 (ubuntu 18/04 and 20/04)

/Bruno

[xiang.wang@…]

Replying to casella:

I tried to reproduce the issue on Windows 10, using the 1.16.2 64-bit released version, and using the 1.17.0-dev-301 and 1.17.0-dev-313 releases. According to the ​1.16 maintenance commit history and ​master commit history, all three include the commits ​fd2a6cf and ​ee13cc6 that are the most likely culprits. However, I always got the correct result and couldn't reproduce the faulty diagrams.

Maybe you have some other setting that is interfering badly with -d=nfAPI. Can you please select Tools | Options, press the Reset button, that resets all settings to default, restart OMEdit and then report what happens?

windows 10, version 2004

for 1.16.2-64bit I have tried to go with reset, but nothing happens, the components are still incorrectly displayed, e.g.. the main image is gone only left a rectangular with cross in it, components can't be connected

for 1.16.0-64bit the same issue. Before I installed 1.16.2, the Opentank in fluid can't display right, that means the "tank" is gone, but ports are there and the component still can be connected. But after I have installed 1.16.2 and go back to 1.16.0, the valve and pump can't display right.

1.16.0-64bit may shows different cases since I use this in my class and I ask students to install and do the simulation. Some of them have this problem but some not.

I am downloading 1.17.0 now and will report later when I finish the installation. Before I have installed, but rolled back due to some other issues.

[xiang.wang@…]

incorrect display of components in view and in tree

[casella]

Replying to xiang.wang@…:

for 1.16.0-64bit the same issue.
Before I installed 1.16.2, the Opentank in fluid can't display right, that means the "tank" is gone,

The tank is not gone, it is just that the blue cylinder representing the filled part is currently broken, see #5631. This will be fixed some time in 2021.

I can actually but ports are there and the component still can be connected. But after I have installed 1.16.2 and go back to 1.16.0, the valve and pump can't display right.

Do you mean you uninstalled 1.16.2 and reinstalled 1.16.0, but you didn't get the old behaviour? This is interesting, maybe it holds a clue so as to what is going wrong there. I can't figure it myself now, but maybe @adrpo or @adeas31 can.

The Chinese-titled .png file made me wonder, maybe you still have some issues related to the use of non-ASCII characters in the file system. @xiang.wang, @bruno, are you using pathnames with non-ASCII characters in the omc installation path?

I am downloading 1.17.0 now and will report later when I finish the installation.

OK, please keep up posted here.

Before I have installed, but rolled back due to some other issues.

Please report them if still there

[Bruno PERMANNE <bruno.permanne@…>]

Hello,

As an old programmer, I never use pathname with non-ASCII characters. It's only in the range 0..9 a..z A..Z and underscore '_' to simulate spaces.
For me, so far in W7 W10 Linux:
1.14 : Fluid is OK
1.16.0 : Fluid is NOT Ok
1.16.1 : Fluid is Ok
1.16.2 : Fluid is still NOT Ok

/Bruno

[casella]

Replying to Bruno PERMANNE <bruno.permanne@…>:

Hello,

As an old programmer, I never use pathname with non-ASCII characters.

Lucky you. Some people in corporate environments need to use pathnames with spaces ("Program Files"), see #4504, and I actually had students from Russia (#5192) with cyrillic Windows pathnames, and from Italy with accented letters (#5437). As far as I know, all these issues should have been fixed for good since 1.14.0.

It's only in the range 0..9 a..z A..Z and underscore '_' to simulate spaces.

Good to know, anyway.

For me, so far in W7 W10 Linux:
1.14 : Fluid is OK
1.16.0 : Fluid is NOT Ok
1.16.1 : Fluid is Ok
1.16.2 : Fluid is still NOT Ok

One thing that changed from 1.14 to 1.16.0 is that we started using the new frontend for some of the APIs that OMEdit calls to get information to display stuff. That feature speeds up the response of OMEdit considerably, but it may still have some bugs. Maybe something was broken in 1.16.0, fixed in 1.16.1, and then broken again in 1.16.2.

Please check Tools | Options | Simulation | Enable new frontend use in the OMC API. You may turn it on or off, then restart OMEdit and see what happens.

It's just strange that I cannot reproduce the issue myself. I still can't figure out what could be the difference that causes this issue.

[Bruno PERMANNE <bruno.permanne@…>]

I think there is no problem with de pathnames.

I have attached two pictures of exactly the same program open in 1.16.1 the other in 1.16.2
with new frontend on

As you said, I have turn off new frontend and MIRACLE all is ok now.

So the issue is there and not dependent of the OS

Thanks, I can now work further on this extraordinary soft with my french students.

/Bruno

[casella]

Replying to Bruno PERMANNE <bruno.permanne@…>:

As you said, I have turn off new frontend and MIRACLE all is ok now.

Well, it's not really a miracle, just workaround to avoid using the broken nfAPI. @adrpo will get it fixed in 1.16.3 after the Christmas break.

Thanks, I can now work further on this extraordinary soft with my french students.

Enjoy!

[xiang.wang@…]

Replying to casella:

Replying to xiang.wang@…:

for 1.16.0-64bit the same issue.
Before I installed 1.16.2, the Opentank in fluid can't display right, that means the "tank" is gone,

The tank is not gone, it is just that the blue cylinder representing the filled part is currently broken, see #5631. This will be fixed some time in 2021.

I can actually but ports are there and the component still can be connected. But after I have installed 1.16.2 and go back to 1.16.0, the valve and pump can't display right.

Do you mean you uninstalled 1.16.2 and reinstalled 1.16.0, but you didn't get the old behaviour? This is interesting, maybe it holds a clue so as to what is going wrong there. I can't figure it myself now, but maybe @adrpo or @adeas31 can.

yes, it is. this is what I found.

The Chinese-titled .png file made me wonder, maybe you still have some issues related to the use of non-ASCII characters in the file system. @xiang.wang, @bruno, are you using pathnames with non-ASCII characters in the omc installation path?

I have noticed this long ago since many software have such issue. Students have also encountered this when they install the software. And not only the installation of software, if the path of saved model has Chinese characters there may also be problems. For me it is always in default "Program Files". If this may cause a problem, I will change and try.

I am downloading 1.17.0 now and will report later when I finish the installation.

OK, please keep up posted here.

Before I have installed, but rolled back due to some other issues.

Please report them if still there

Well, for 1.17, it seems everything is fine. The software is still in "Program Files" and all the displays are correct. But it rises another concern. 1.17 works always fine for me, but when I ask students to install 1.17 (also in "Program Files"), they will have errors when they run my (text) model. Even I can't reproduce this error. So let it be as it is, when I have this problem again, I will post in a ticket.

[xiang.wang@…]

Replying to casella:

Please check Tools | Options | Simulation | Enable new frontend use in the OMC API. You may turn it on or off, then restart OMEdit and see what happens.

I installed back 1.16.0 and check this off, and all symbols are back, components can be correctly displayed. Problem solved! (In 1.17.0 no need to do this, it is correct originally)

Thank you for your advice.

[casella]

@xiang.wang, if you are facing other such weird problems, please try to install the software on C:\openmodelica... and put your model files in C:\MyFiles. If that solves the issue, please let us know, we may still need to fix something regarding non-ascii pathnames.

[stephan.fevrier]

With some Email support from martin sjoelund I could resolve the issue by rolling back to the nightly build 1.17.0 dev-300 from December 20th. The bug was apparently introduced after that date.

Hoping this helps.

[casella]

Replying to stephan.fevrier:

With some Email support from martin sjoelund I could resolve the issue by rolling back to the nightly build 1.17.0 dev-300 from December 20th. The bug was apparently introduced after that date.

Hoping this helps.

Yes, thanks! This is consistent with the info in comment:7.

[openmodelica@…]

Replying to casella:

Replying to Bruno PERMANNE <bruno.permanne@…>:

For me, so far in W7 W10 Linux:
1.14 : Fluid is OK
1.16.0 : Fluid is NOT Ok
1.16.1 : Fluid is Ok
1.16.2 : Fluid is still NOT Ok

One thing that changed from 1.14 to 1.16.0 is that we started using the new frontend for some of the APIs that OMEdit calls to get information to display stuff. That feature speeds up the response of OMEdit considerably, but it may still have some bugs. Maybe something was broken in 1.16.0, fixed in 1.16.1, and then broken again in 1.16.2.

Please check Tools | Options | Simulation | Enable new frontend use in the OMC API. You may turn it on or off, then restart OMEdit and see what happens.

It's just strange that I cannot reproduce the issue myself. I still can't figure out what could be the difference that causes this issue.

Turning off "Enable new frontend use in the OMC API (faster GUI response)" and restarting OMEdit fixed my problems with rendering my Fluid library based models in my Debian version OpenModelica 1.18.0~dev-26-gc69a0c7 of OMEdit.

Michael

[casella]

Yes, that solves the issue, but then you have a much slower response from OMEdit. We'll release 1.16.3 without the two problematic commits ASAP, and also roll them back from 1.17.0 and 1.18.0-dev.

[adrpo]

Can somebody that had this issue try to test with 1.16.3?
​https://build.openmodelica.org/omc/builds/windows/releases/1.16/maintenance/64bit/
Just make sure that Tools->Options->Simulation "Enable new frontend use in the OMC API" is selected.

[casella]

I just tried the 1.16.3 nightly, unfortunately it still has the same issue, see the two attachments nfAPI.png and nonfAPI.png

[adrpo]

Geez. I effectively reversed those 2 commits.
@casella, what model did you use for the pictures?
I want to debug with it.

[casella]

Sorry, I forgot to write it here, I started to write an email but then switched to the ticket. I'll send it to you by mail.

[casella]

Replying to adrpo:

Geez. I effectively reversed those 2 commits.

Not really, probably there was something else going bad there.

I would really suggest to just to git revert those two commits and proceed with the 1.16.3 release. Anything else can go in 1.17.0.

[adrpo]

Ok. I could finally reproduce this. One needs to deactivate "Enable Replaceable Support" in OMEdit->Tools->Options->General (at the bottom). And activate "Enable new frontend use in the OMC API" in OMEdit->Tools->Options->Simulation.

Now I can debug it and fix it properly.

[casella]

Do you mean that if one activates both, the problem is gone?

[adrpo]

Yes.

[Stephan F.]

I can confirm this. I just updated from 1.17 dev300 to 1.18 dev43 and fluid models were a mess again. Enabling replaceable support, followed by a restart fixed it. Thank you for the hint Adrpo.

[casella]

We'll get this fixed ASAP in 1.16.4, 1.17.0 and 1.18.0-dev. In the meantime, that's the workaround.

[casella]

Retargeted to 1.16.4, since 1.16.3 was already released but did not address the issue

[adrpo]

Fixing the master (1.18.0) with PR: ​https://github.com/OpenModelica/OpenModelica/pull/7180
Will port this to 1.17 and 1.16.4 asap.

[casella]

Great, thanks!

[adrpo]

PRs now testing:

• 1.17 ​https://github.com/OpenModelica/OpenModelica/pull/7184
• 1.16 ​https://github.com/OpenModelica/OpenModelica/pull/7186

will tag and generate new versions later today.

[casella]

Great! Both tests passed, I just merged in 1.16.

@adrpo, before making the release, could you please check all the test cases in the tickets of milestone 1.16.4?

I guess they should all be fixed now, but better make sure, just in case.

[adrpo]

I also need to fix the documentation as well as it has changed since 1.16.3 (some settings moved around). I will try to do this today, at latest tomorrow.

[casella]

Sounds good. Next week I will start to draft the release notes of 1.17.0, I guess I should still do this here
https://trac.openmodelica.org/OpenModelica/wiki/ReleaseNotes/1.17.0
I would suggest that we make the trac->github transition after the release.

[adrpo]

This is now fixed on master and maintenance/v1.16, maintenance/v1.17.
1.16.4 and 1.17.0-dev.beta1 are tagged and will be released as soon as they build.

[casella]

Hooray! :)

[Stephan F.]

I just upgraded to the latest nightly build 1.18.0~dev-49-gc5c5e43 and still experience the same issue when disabling the "Enable Replaceables Support" option. I was under the impression that this issue was fixed. Am I wrong?

[adeas31]

Note that "Enable Replaceables Support" requires to restart OMEdit.

[adrpo]

Hmm, it should not happen on any combination. I will check.

[casella]

Replying to Stephan F.:

I just upgraded to the latest nightly build 1.18.0~dev-49-gc5c5e43 and still experience the same issue when disabling the "Enable Replaceables Support" option. I was under the impression that this issue was fixed. Am I wrong?

@Stephan, 1.18.0~dev-49-gc5c5e43 is not the latest build, it is almost ​two weeks old. Please try the latest one.

[casella]

Tested successfully in v1.17.0-dev.beta2 (64-bit) on Windows 10