load_fmu documentation

[MStreet3]

There is currently no accessible version of load_fmu help docs outside of the file pyfmi.so

load_fmu is generates this result:

http://stackoverflow.com/q/25999554/1258390

[chria]

If you are looking for none code documentation, see either http://www.jmodelica.org/page/4924 or http://www.jmodelica.org/api-docs/usersguide/1.14.0/ch05.html .

Regarding your stackoverflow question (I'm unable to comment), I cannot reproduce the error. Running the same code on two models, I get:
In [2]: models
Out[2]: [<pyfmi.fmi.FMUModelME1 at 0x4680bc0>, <pyfmi.fmi.FMUModelME1 at 0x318dab0>]

where they have different memory adress. Although trying to run load too many models you will eventually run out of memory and an error will occur which might be hard to diagnose.

[MStreet3]

Chris,

Thanks for the reply. I found the doc and method for load_fmu in
pyfmi/fmi.pyx. The online index doc http://www.jmodelica.org/page/4924
does not match what I found and caused the confusion.

pyfmi.fmi.load_fmu()

Helper function for loading FMUs of different kinds.

From what I can tell, it appears that each instance of a FMUModelCS1 object
is successfully constructed. The issue comes up with the call to
instantiate_slave.

I see there's an inaccesible method parameter "location", which is passed
to the specification function.

I'm not too familiar with C and it's memory management abilities, but if
this default location is continually passed to the same function it seems
this may be causing my problem.

The issue occurs for any number of calls to load_fmu greater than 1. In
all cases the memory location is identical.

Do you have any thoughts on how I can further diagnose my issue?

Thanks a lot,

Mike

On Tue, Sep 23, 2014 at 10:39 PM, Christian Andersson <
notifications@github.com> wrote:

If you are looking for none code documentation, see either
http://www.jmodelica.org/page/4924 or
http://www.jmodelica.org/api-docs/usersguide/1.14.0/ch05.html .

Regarding your stackoverflow question (I'm unable to comment), I cannot
reproduce the error. Running the same code on two models, I get:
In [2]: models
Out[2]: [, ]

where they have different memory adress. Although trying to run load too
many models you will eventually run out of memory and an error will occur
which might be hard to diagnose.

—
Reply to this email directly or view it on GitHub
#1 (comment).

Michael Street
BS, Physics
Morehouse College, 2011
SM, Building Technology
Massachusetts Institute of Technology, 2013
NSF Graduate Research Fellow, High Performance Building Lab
Georgia Institute of Technology
Hinman 230
C: 301-655-2358

[chria]

The default value for the location is NULL which means that FMI Library will replace this value with the path to where the FMU was actually unpacked to, see http://www.jmodelica.org/api-docs/FMIL_docs/2.0/group__fmi1__import__capi__cs.html#gabd57224b28ac604720e46267d88aad54 . From where are the FMUs?

Best
/Christian

[MStreet3]

Okay, thank you for the information. I don't believe this is the issue
then. This is my current call:

load_fmu(fmu = "foo.fmu", path = "/path/to/fmu/")

Each of the fmu's is stored in "/path/to/fmu/".
My understanding is that the call to FMUModelCS1 creates the appropriate
object at a given memory location. What ensures this is unique other than
Python internal processes? I see the lines:

self.callBackFunctions.allocateMemory = FMIL.calloc;
self.callBackFunctions.freeMemory = FMIL.free;

and it makes me wonder if this is interacting in some unforseen way on my
system.

Of, assuming this is working fine, does the call to self.instantiate_slave
(each expecting name = "Slave") mix up Python object assignment?

Again, thanks for looking deeper into this with me.

Mike

On Wed, Sep 24, 2014 at 1:02 PM, Christian Andersson <
notifications@github.com> wrote:

The default value for the location is NULL which means that FMI Library
will replace this value with the path to where the FMU was actually
unpacked to, see
http://www.jmodelica.org/api-docs/FMIL_docs/2.0/group__fmi1__import__capi__cs.html#gabd57224b28ac604720e46267d88aad54
. From where are the FMUs?

Best
/Christian

—
Reply to this email directly or view it on GitHub
#1 (comment).

Michael Street
BS, Physics
Morehouse College, 2011
SM, Building Technology
Massachusetts Institute of Technology, 2013
NSF Graduate Research Fellow, High Performance Building Lab
Georgia Institute of Technology
Hinman 230
C: 301-655-2358

[chria]

No problem. I'm also confused why this happens. We are relying on Pythons internal process for created the instances of FMUModelCS1 and I don't believe there would be a problem here. If there were I believe it would have been detected in other situations and fixed in Python.

Regarding the callback functions, here we are just providing references to the allocation and de-allocation methods in FMIL there is really no connection to how the instance of FMUModelCS1 are created here (the instance is already created when we are this far)

Regarding the expected name, I don't believe that it would have any impact on how Python creates the instances (as above, the instance is already created). So I'm really at loss on how to proceed.

Best
/Christian

[lambtt]

If you are looking for none code documentation, see either http://www.jmodelica.org/page/4924 or http://www.jmodelica.org/api-docs/usersguide/1.14.0/ch05.html .

Regarding your stackoverflow question (I'm unable to comment), I cannot reproduce the error. Running the same code on two models, I get: In [2]: models Out[2]: [<pyfmi.fmi.FMUModelME1 at 0x4680bc0>, <pyfmi.fmi.FMUModelME1 at 0x318dab0>]

where they have different memory adress. Although trying to run load too many models you will eventually run out of memory and an error will occur which might be hard to diagnose.

Hi chria, I'm wondering if there are any documents about PyFMI and Jmodelica on the internet since the links you listed were all "not found".
It is really difficult to find a comprehensive and specific resource for FMU on the internet nowadays.
I appreciate any hints.
Thanks for that!