Appetite to wrap the scripting api?

[bc0n]

When using OMPython previously I spent some time wrapping it in less-primitive functions:

    def loadFile(self, filePath): #load some other *.mo file, True = load success, False = failed
        relPath = self.getRelativePathFromWorkingDirectory( filePath ) #file path must be RELATIVE to Modelica's working directory, absolute do not work
        if relPath:
            ret = self.omc.sendExpression('loadFile("./{0}")'.format( relPath ) )
            if not ret:
                print('Modelica.loadFile(): on filePath[' + filePath +'] relPath[' + relPath +'] returned',ret)
        else:
            print('loadFile: relPath failed', relPath)
            ret = False

        if ret is False :
            print('loadFile [' + filePath +'] failed')

        return ret

This is needed because the zeroMQ / sendExpression interface lacks error handling. While it would be useful for omc to be more verbose (and documented!), a wrapper can smooth over the rough edges. I can make a longer proposal if desired.

Is there any appetite/roadmap to include those functions within OMJulia or should I again keep these separate? Similarly, I wrote a pr for MAT.jl to read Modelica mat files, but that function could be placed here just as well in my opinion.

Thoughts?

[bc0n]

Perhaps this is the intention of the 'advanced' part of OMJulia, though the source is more clear..?

[AnHeuermann]

Hey @bc0n.

When using OMPython previously I spent some time wrapping it in less-primitive functions:

Julia like functions for most of the scripting API functions sound like a very good idea and contributions are always welcome.
I'm not sure if @arun3688 has any plans for this in OMJulia or OMPython.
For most parts they should be straight forward and in my opinion have the same interface as the scripting API functions itself, but it's a bit tedious.
So e.g. for simulate something along these lines?

"""
    simulate(className,
             startTime = "<default>",
             stopTime = 1.0,
             numberOfIntervals = 500,
             tolerance = 1e-6,
             method = "<default>",
             fileNamePrefix = "<default>",
             options = "<default>",
             outputFormat = "mat",
             variableFilter = ".*",
             cflags = "<default>",
             simflags = "<default>")

Simulates a modelica model by generating c code, build it and run the simulation executable.
The only required argument is the className, while all others have some default values.
"""
function simulate(className::String,
                  startTime::Union{Number, String} = "<default>",
                  stopTime::Number                 = 1.0,
                  numberOfIntervals::Integer       = 500,
                  tolerance::Number                = 1e-6,
                  method::String                   = "<default>",
                  fileNamePrefix::String           = "<default>",
                  options::String                  = "<default>",
                  outputFormat::String             = "mat",
                  variableFilter::String           = ".*",
                  cflags::String                   = "<default>",
                  simflags::String                 = "<default>"
                  )::Tuple{String, Dict{String, Any}, String}

  simulationResults = ""
  ret = sendExpression(omc, "simulate($className, $startTime, $stopTime, $numberOfIntervals, $tolerance, $method, $fileNamePrefix, $options, $outputFormat, $variableFilter, $cflags, $simflags)")
  if haskey(ret, "resultFile") && ret["resultFile"] != ""
    # Simulation was successful
    simulationResults = ret["resultFile"]
  end

  err = sendExpression(omc, "getErrorString()")

  return (simulationResults, ret, err)
end

(Using a bit of AI to wrap the scripting API into Julia was very helpful in this case.)
Not sure what's the best way to make omc available in this function. I don't think there is something similar to Python's self in Julia.

[AnHeuermann]

Similarly, I wrote a JuliaIO/MAT.jl#181 to read Modelica mat files, but that function could be placed here just as well in my opinion.

I think the right place for handling mat v4 is indeed juliaIO. Then other can use it as well.
Actually I would immediately use it in another package of mine that's using OMJulia.

[AnHeuermann]

Oh and if it's not possible to merge JuliaIO/MAT.jl#181, because OpenModelica mat files need some special treatment that is not fit for a general package like MAT.jl we could make it a package extension to this package instead.

[arun3688]

Julia like functions for most of the scripting API functions sound like a very good idea and contributions are always welcome.
I'm not sure if @arun3688 has any plans for this in OMJulia or OMPython.
For most parts they should be straight forward and in my opinion have the same interface as the scripting API functions itself, but it's a bit tedious.
So e.g. for simulate something along these lines?

This should be possible, and this is a different approach, The current implementation was based on the proposal from Bernt Lie to OMPython. To make all the scripting interface consistent it was implemented this way. but as you can the simulate() function is a wrap of the following API getSimulationOptions(), setSimulationOptions() etc...

[AnHeuermann]

In today's dev-meeting we had the idea to collect all scripting API functions inside a new package called something like API.
In this case there would be a clear separation between the OMJulia.simulate function and the OMJulia.API.simulate function.

@bc0n do you want to give it a go? I can support a bit if you need some help, but don't have the time to do it myself anytime soon.

[arun3688]

@AnHeuermann I hope i will have sometime, if some of my other project works does not pop up immediately, I guess i can write the wrapper for all the important API which we currently have in ModelicaSystem but not the whole openmodelica scripting API may be this can be implemented based on demand. Another question is? Will this wrapper be really useful ? I guess most of the users are already using our current API and may be they report issues, but not having any issues in using the API

[arun3688]

Perhaps this is the intention of the 'advanced' part of OMJulia, though the source is more clear..?

Yes that is the case, most of the API are split into smaller API's and finally wrapped inside the main API

[bc0n]

I agree with @arun3688's caution on not knowing the use-cases or usages of any of these packages; I wrote my python wrappers when I wanted to do model development guided by more advanced graphing than capable in OMEdit, and now having moved to Julia my use is similar.

@AnHeuermann @arun3688 I'm happy to take a swing at this, though I do not have a full understanding of how the api is used and won't be able to enable every feature or use case. Also the existing tests do not cover the present functionality, eg needing actual model loading, simulation, and results checking.
I'm also happy to push my additions so far and let @arun3688 take/merge whatever he thinks is correct.

[AnHeuermann]

Maybe we should wait for #92 and see how the advanced API is doing. To be honest I never used it, because I didn't understand how to use it.

For me it would be easier to use a Julia version of the classic OM scripting API, but if I'm the only one it's not worth to invest too much time into this.

Also the existing tests do not cover the present functionality

I'll add some tests in #94 to ensure at least the basic functionality stays working.

I'm also happy to push my additions so far and let @arun3688 take/merge whatever he thinks is correct.

Sound like a good idea. We can add functions in small increments as we see fit do to it (or have time for it).

[AnHeuermann]

Added to release v0.3.0.