Flat Modelica and External or Vendor-specific Functions

[sjoelund]

Flat Modelica has some issues regarding builtin functions, and there are several ways to deal with them.

Take for example ModelicaServices - it contains vendor-specific functions that may not work in other tools.
Should a Flat Modelica model be allowed to have a uses-annotation on a package such as ModelicaServices and pull in the corresponding external or non-external functions?

Let's say you depend on Modelica_DeviceDrivers and it has many nice libraries and include-files you would like to use. Do you need to copy them to the same location as the flat Modelica file? (Can you even do that if you have files with the same name in the directory structure, etc?)

Or would you be allowed to modify the function and simply add a uses-annotation at the top-level and LibraryDirectory/IncludeDirectory to override the defaults for the function?

So you could have an external object like:

class 'Modelica.Blocks.Types.ExternalCombiTable2D'
extends ExternalObject;
function constructor
  input String 'tableName';
  input String 'fileName';
  input Real[:, :] 'table';
  input 'Modelica.Blocks.Types.Smoothness' 'smoothness';
  output 'Modelica.Blocks.Types.ExternalCombiTable2D' 'externalCombiTable2D';
external "C" 'externalCombiTable2D' = ModelicaStandardTables_CombiTable2D_init('tableName', 'fileName', 'table', size('table', 1), size('table', 2), 'smoothness') annotation(LibraryDirectory="modelica://Modelica/Resources/Library", Library = {"ModelicaStandardTables"});
end constructor;

function destructor
  input 'Modelica.Blocks.Types.ExternalCombiTable2D' 'externalCombiTable2D';
external "C" ModelicaStandardTables_CombiTable2D_close('externalCombiTable2D') annotation(LibraryDirectory="modelica://Modelica/Resources/Library", Library = {"ModelicaStandardTables"});
end destructor;

end 'Modelica.Blocks.Types.ExternalCombiTable2D';

The second issue is possible to solve with a bit of tweaking, but I think ModelicaServices is tricky.

[henrikt-ma]

I don't think I see the problem here. I suppose the external functions will keep their LibraryDirectory and Library annotations, so I would have expected that to work just the same as in full Modelica. Would Modelica_DeviceDrivers be any different in this respect?

Isn't ModelicaServices really a different kind of problem due to the fact that it could be referring to tool-specific implementations? It wouldn't surprise me if we end up with a one-off solution to make a FlatModelica replacement for ModelicaServices.

[sjoelund]

If you don't modify the LibraryDirectory annotation, it will no longer look in the correct place because the Flat Modelica file is in a directory separate from the original package(s). (There is a hidden default which you could copy if you want)

Modelica_DeviceDrivers uses C-headers a lot more than MSL, which are more susceptible to weird things happening if you try to move all C-files and libraries from one place to another.

ModelicaServices includes things like maximum Integer size which may be different in different tools. Which is a bit different. But it is similar in the sense that you could handle it by allowing the same kind of thing:

If you were allowed to refer to outside packages, you could simply refer to ModelicaServices constants and functions from your flat model. (And do the same for other libraries with external C-code, libraries, etc). It wouldn't be a totally self-contained model anymore, but it would possibly be easier to implement and standardize.

[henrikt-ma]

If you don't modify the LibraryDirectory annotation, it will no longer look in the correct place because the Flat Modelica file is in a directory separate from the original package(s). (There is a hidden default which you could copy if you want)

Right, so it has to be modified.

Modelica_DeviceDrivers uses C-headers a lot more than MSL, which are more susceptible to weird things happening if you try to move all C-files and libraries from one place to another.

Don't you just have to make sure that include directories are set up properly in the Flat Modelica functions, similar to how LibraryDirectory needs to be modified?

ModelicaServices includes things like maximum Integer size which may be different in different tools. Which is a bit different. But it is similar in the sense that you could handle it by allowing the same kind of thing:

If you were allowed to refer to outside packages, you could simply refer to ModelicaServices constants and functions from your flat model. (And do the same for other libraries with external C-code, libraries, etc). It wouldn't be a totally self-contained model anymore, but it would possibly be easier to implement and standardize.

I think that Flat Modelica support for these constants isn't a priority; tools only using Flat Modelica as intermediate representation can just inline the constant values, while people actually writing Flat Modelica from scratch will be missing this nice feature of full Modelica.

[sjoelund]

Don't you just have to make sure that include directories are set up properly in the Flat Modelica functions, similar to how LibraryDirectory needs to be modified?

Maybe if we assume the files don't use ../ to escape into some other directory.

Then there is of course the whole modelica:// lookup of files at runtime... ModelicaServices issues.

[henrikt-ma]

Then there is of course the whole modelica:// lookup of files at runtime... ModelicaServices issues.

I'm not sure this is really that much more of a problem for Flat Modelica than for full Modelica. For full Modelica, we generate a function for resolving Modelica URIs based on the classes loaded at the time of translation. When producing Flat Modelica, I suppose we would then generate a tool-specific Flat Modelica helper function to support our tool-specific translation of ModelicaServices.ExternalReferences.loadResource.