1

Since Modelica 3.2 (released March 2010) it is allowed to use arbitrary Unicode characters in comments, description strings and/or annotations.
But for some reason I am having trouble with code like the following:

within ;
model ENCO_testing "code for investigating Dymola encoding problems"
  Real TempC "Temperature in °C";
  parameter Real someNumber "description string german üöäß";
  Integer greekInt=4 "description string greek αβδεηζμθ";
  // a comment with math symbols: °²³~µ

equation 
  TempC = if greekInt > 3 then someNumber*5 else someNumber/3;
end ENCO_testing;

To reproduce my problems try the following UTF-8 roundtrip:

  • copy and paste the above text into your favorite text editor
  • save the file using UTF-8 (with or without BOM, or any other encoding) and close
  • open again in favorite editor, then in OpenModelica and Dymola (in this order)
  • if things still look good, hit the save button in Dymola (maybe delete a character and re-type it)
  • open again in favorite editor, OpenModelica and Dymola
  • at least some symbols will look different somewhere

Can somebody tell me how to save that file in a way that it looks good everywhere? Or am I expecting too much? What has to be fixed and where?

matth
  • 2,568
  • 2
  • 21
  • 41
  • In reality, I am only interested in the °degree symbol°. A copy of the offending code is here: https://gist.github.com/thorade/1aa56a886b003fc1e42c – matth May 21 '15 at 11:55

3 Answers3

1

Testing UTF-8 in latest Dymola (Linux), it seems as if Dymola does not change the encoding to ISO-8859-1 any longer (to my memory it used to change this). It does however, not look good since it is displayed as if the UTF-8 text is ISO.

The easiest way to get it to look OK everywhere is to use HTML entities instead. This does not seem to show up correctly in the simulation results browser in OMEdit, but does in Dymola:

Real TempC "<html>Temperature in &deg;C<html>";
sjoelund.se
  • 3,468
  • 12
  • 15
1

Yes this is definitely an issue with lack of UTF8 support in Dymola (even 2016). So what to do? For the description strings you could simply use html entities to workaround Dymola's lack of UTF8 support.

e.g.,

Real TempC "<html>Temperature in &deg;C</html>";
parameter Real someNumber 
  "<html>description string german &uuml;&ouml;&auml;&szlig;</html>";

Not nice but works ;-)

PS: Ah and complain to DS about this long overdue feature.

Dietmar Winkler
  • 942
  • 5
  • 11
  • Looks like @sjoelund.se beat me to it. – Dietmar Winkler May 21 '15 at 14:08
  • Dymola 2018 seems to fully support UTF-8, at least the above example works without problems. It seems Dymola is using UTF-8 with BOM by default, but also accepts UTF-8 without BOM. – matth Jun 13 '17 at 09:28
1

In Dymola 2016 FD01 (literally just released) you can set Advanced.PreferWritingLatin1=false; to avoid writing iso-latin-1 files.

For support you should use http://www.3ds.com/support and/or contact your reseller; the address Dymola.support@3ds.com has been retired.

matth
  • 2,568
  • 2
  • 21
  • 41
Hans Olsson
  • 11,123
  • 15
  • 38
  • Thanks for clarification regarding the email address. Installing the latest Dymola version will be the first thing I'll do tomorrow. – matth Nov 25 '15 at 20:30
  • This seems to be working, thanks, but the flag has to be set manually: If not set manually, Dymola will still mess up the above example, because contrary to the release notes, detection of non-iso-latin-1 characters does not work (or not sufficiently reliable, just try that example). For now, I will just add the flag to one of the startup scripts. – matth Nov 27 '15 at 08:37
  • Dymola 2017 adds a new flag `Advanced.AlwaysWriteUTF8`. – matth Sep 20 '16 at 14:45
  • Dymola 2018 includes some more UTF-8 related improvements. The above example works without any problem now. – matth Jun 13 '17 at 09:27