Hello,
Turns out this problem -- passing constants to functions -- may not
be 100% resolved:
While the testcases do run ok, if I make a model which passes a
constant to a function, run it and look at the .plt and log files, I
see the correct answers in the .plt file, but I still get an error
message. For example, the following works fine:
// ----------------------------
// Testing.mo
function TestingAlgorithm
input Real i;
output Real o;
external "C" o=TestingAlgorithm(i) annotation
(Library="TestingAlgorithmLib.a",Include="#include
\"TestingAlgorithm.h\"");
end TestingAlgorithm;
model Testing
Real p(start=0.0);
parameter Real q = 2;
equation
p = TestingAlgorithm(q);
end Testing;
// ----------------------------
// TestingAlgorithm.h
double TestingAlgorithm(double);
// ----------------------------
// TestingAlgorithm.c
double TestingAlgorithm(double i)
{
double res;
res = 14 + i;
return res;
}
// ----------------------------
// Script file Testing_Script.mos
loadFile("Testing.mo");
system("gcc -c -o TestingAlgorithmLib.a TestingAlgorithm.c");
simulate(Testing, startTime=0.0, stopTime=0.3, numberOfIntervals=5);
getErrorString()
With this, there's no problems, and the Testing_res.plt correctly
shows p with a value of 16.
However, if I change
parameter Real q = 2;
to
constant Real q = 2;
I still get a Testing_res.plt showing p with a correct value of 16,
but I also get an error message:
>>> runScript("Testing_Script.mos")
"true
0
record
resultFile = "Testing_res.plt"
end record
"Error building simulator. Buildlog: gcc -shared -export-dynamic -
single_module -dynamiclib -flat_namespace -I"/Users/jasonbrown/
opnmodlca/OpenModelica/build/include" -o TestingAlgorithm.so
TestingAlgorithm.c -L"/Users/jasonbrown/opnmodlca/OpenModelica/build/
lib" -lc_runtime -lm
i686-apple-darwin8-gcc-4.0.1: unrecognized option '-shared'
ld: Undefined symbols:
_TestingAlgorithm
/usr/bin/libtool: internal link edit command failed
make: *** [TestingAlgorithm] Error 1
Error building simulator. Buildlog: command "/Users/jasonbrown/
opnmodlca/OpenModelica/build/bin/Compile" not found. Check
$OPENMODELICAHOME
"
true"
Is the error message itself an error?
Thanks,
Jason
On Jun 22, 2008, at 4:04 PM, Jason Brown wrote:
Hi Adrian,
I guess you're right about FunctionSimplex.mo; here's the last
lines from
/tmp/log-FunctionSimplex.m
Equation diff:
got: (b,z,p,q) =
({0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,
0.0,0.0,0.0,0.0,0.607157202224188,0.0,0.209290730549892,0.524163301609
514,0.0,0.0,0.186891015589603,0.0,1.42026618663458},
1.3406112343836,31,4);
expected: (b,z,p,q) =
({0.0,0.618333725158916,0.0,0.0,0.0,0.0,0.0,0.0737216122307216,0.0,0.0
,
0.136823856436815,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.6154230713
63511,0.0,0.0,1.97802663649155,0.0,0.0,0.0,0.0,0.0},
3.42232890168151,31,2);
If I'm reading this right (?) it looks like there's a few big
differences.
I'll send you my systemimpl.c via email outside the forum.
Thanks again!
Jason
On Jun 22, 2008, at 3:17 PM, Adrian Pop wrote:
Hi Jason,
I'm glad we could fix it with Eric's help and mine.
Could you please send me a copy of your systemimpl.c?
Or at least a diff so I can apply the changes to our
sources in the trunk. Thanks!
About -shared for gcc in MacOS I have no idea.
We could just remove the flag for MacOS platform
if it generates that warning in the logs.
About FunctionSimplex.mo I believe the mismatch you get
is due to less or more precision on floating point numbers
as we do the comparison using textual diff. Have a look
in /tmp/log-FunctionSimplex.mo.
Cheers,
Adrian Pop/
Jason Brown wrote:
Ah, that helps quite a bit: the snippet below for System_5finit
seems to have done the trick for the most part, as now (after a
re-configure and re-make) 281 out of 282 tests succeeded in
mofiles. The one that failed is
+ FunctionSimplex ... equation mismatch
after
../../build/bin/omc FunctionSimplex.mo
and looking at the *.log files, all of them have for their last
line:
i686-apple-darwin8-gcc-4.0.1: unrecognized option '-shared'
(first line is "gcc -shared -export-dynamic -single_module -
dynamiclib -flat_namespace ... "
I see '-shared' as a linker option in the man pages...any ideas?
Thanks again,
Jason
On Jun 20, 2008, at 6:28 PM, Adrian Pop wrote:
Hi,
This can be fixed in:
OpenModelica/Compiler/runtime/systemimpl.c
in function: System_5finit (Linux part,
second definition) with something like:
#ifdef __APPLE_CC__ /* I don't know the actual define */
set_linker("gcc -shared -export-dynamic -single_module
-dynamiclib -flat_namespace");
#endif
Then the correct flags for the
linker will be put in the makefiles.
Cheers,
Adrian Pop/
Eric Meyers wrote:
I haven't seen the makefile being used for OSX, but I'll bet it
needs -single_module -dynamiclib -flat_namespace for the shared
libraries.
Eric
On Jun 20, 2008, at 6:02 PM, Adrian Pop wrote:
Hi Jason,
We have changed the way functions are handled.
Now we generate an .so (or .dll) for the function, load
it dynamically and call it. We haven't tested this at all
on Mac OS and I think this is the reason for the failures.
It works pretty OK in Linux, Windows, and Solaris.
To obtain more information on what might be the problem do:
1) cd OpenModelica/testsuite/mofiles
2) ../../build/bin/omc Vectorizable1.mo
3) look into all *.log generated to see
how the compilation of the functions went.
Let me know how it goes as I might be able to
help and we could fix also the compilation on
MacOS.
Cheers,
Adrian Pop/
Jason Brown wrote:
Hi,
I've been going over some of the failed testsuite models
under OS X Tiger:
1. In mofiles, 261 out of 282 tests succeed; failures are:
... + Constant6 ... nonzero exit status
...
+ Vectorizable1 ... equation mismatch
+ Vectorizable2 ... equation mismatch
+ Vectorizable3 ... equation mismatch
...
+ FunctionEval1 ... equation mismatch
+ FunctionEval2 ... equation mismatch
...
+ FunctionEval9 ... equation mismatch
...
+ FunctionBubblesort ... equation mismatch
+ FunctionSimplex ... equation mismatch
+ ExternalFunction1 ... equation mismatch
+ ExternalFunction2 ... equation mismatch
+ ExternalFunction3 ... equation mismatch
...
+ MultFuncCall ... equation mismatch
...
+ EquationCall ... equation mismatch
...
+ MultipleResultsFunction ... equation mismatch
+ PolynomialEvaluator1 ... equation mismatch
...
+ FuncMultResults ... equation mismatch
...
+ EqualityEquationsCorrect ... equation mismatch
...
+ FuncDer ... equation mismatch
...
+ InOutBool ... equation mismatch
+ InOutArray ... equation mismatch
It seems like a common thing in these test cases is that
somewhere they call a function with a constant as an
argument, e.g. foo(1.2) or foo(a) where a is, e.g., "constant
Real a = 1.2;"
2. In mofiles/msl, everything passes.
3. in mosfiles, 94 out of 105 tests succeeded, and for the
most part the output looks like what has been discussed in
previous posts, along with some function calls with constants
as arguments.
4. in meta, everything passes.
I was wondering if anyone has had the passing constants
failures like in item #1 above under Leopard?
Thanks,
Jason
--------------------------------------------
Jason Brown
Georgia Institute of Technology
College of Architecture
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Eric Meyers
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
--------------------------------------------
Jason Brown
Georgia Institute of Technology
College of Architecture
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
--------------------------------------------
Jason Brown
Georgia Institute of Technology
College of Architecture
[EMAIL PROTECTED]
--------------------------------------------
Jason Brown
Georgia Institute of Technology
College of Architecture
[EMAIL PROTECTED]
