-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compatibility to Open Modelica #10
Comments
progress report with bugfixes and workarounds on branch OM_adaptions and OM version v1.17.0:which test cases do at least compile (most will then simulate, some still simulate forever or fail initializing):Tests:
Examples:
why models dont run:
known issues:
|
The results with OM master branch (nightly builds) fix a lot of these issues, in particular the MoistAir bug: |
I have installed OM version v1.19.0-dev-64bit (02.07.2021): The Reason why most simulation fail, is that the correct assertion level is not used in the components, if it is set in the dropOfCommons. remaining known issues:
Reasons why models still not compile:
|
@adeas31 any comment? I think the axis thing can be resolved by going from left to right when drawing the icon to get it consistent? Been a while since I looked at OMEdit GUI issues.
@perost should these be opened as bugs for the frontend? Especially 2 and 3 I think should be possible to resolve (2 only when possible to evaluate in the frontend I suppose; 3 should be possible to evaluate the level at runtime as far as I can tell).
|
Which icons are mirrored?
Yes. This is the known conditional connectors issue. |
examples are the upper |
concerning the point "Sensors use a function to determine their RealOutput units. OM only supports string literals" the warning is no longer apperent in the nightly build of 02.07. I have installed now, but the unit does not show up in the plotting window. |
That is a bug in OM. See https://trac.openmodelica.org/OpenModelica/ticket/5816 |
@mimeissner, I see that now the main and OM-adaptions branches are fully aligned, and produce the same results in our CI reporting: https://libraries.openmodelica.org/branches/master/ThermofluidStream/ThermofluidStream.html vs. https://libraries.openmodelica.org/branches/master/ThermofluidStream_OM_adaptions/ThermofluidStream_OM_adaptions.html I can't see any reason why you should have OMC-specific adaptations; in fact, we should all strive or a situations where libraries can run on multiple Modelica tools without any kind of adaptation. So, I would suggest that we stop testing the OM-adaption branch on our servers, and that you remove it from the repo. What do you think? |
@casella, if it is not to harmful to your process (e.g. runtime of the test) I would prefer to keep the OM_adaptions open for some time, so I can use it to test some ideas before merging them into main (where we dont want to rewrite history). The naming of the branch would be miss-leading, but I think this would be usefull to keep our history of the main branch clean for now. We also aim for our library to run in all tools without tool-spcific adaptions, so longterm the two branchen will not diverge. |
I just closed the branch OM_adaptions since we dont use it anylonger. @sjoelund can you remove it from the OpenModelica Library testing? |
@mimeissner, @dzimmer, this is the current status of ThermoFluidStream with the latest OMC nightly build Seems to me quite good. Can we close this ticket for good? |
I have downloaded and tested the latest official release of Open Modelica v1.22.2 and was pleasently surprised. I think we can justify closing this issue and if there are further points to be taken care of they can be addressed by a separate issue. |
Currently the library works fine with Dymola. However we want to make it available to OpenModelica as well. In this issue we track the corresponding state and progress.
The text was updated successfully, but these errors were encountered: