search

ORNL-Modelica / Modelica-GNU_ScientificLibrary

GNU General Public License v3.0
10 stars 8 forks source link

Updated some examples / Started integration attempt #9

Closed tburch-LSS closed 2 weeks ago

tburch-LSS commented 2 months ago
tburch-LSS commented 2 months ago

changed from 'ar' to using only 'gcc' to create shared libraries (.so,.dll). so as long as gcc is available, this should work for windows systems as well.

greenwoodms06 commented 1 month ago

Do you want me to merge this? It seems like you are still iterating on it. Let me know.

tburch-LSS commented 1 month ago

hi. yeah, sorry, the changes have been coming kind of fast since i've been struggling with the integration interface. it's still a bit "kludgy", but i think it could be merged in its present state. thanks!

tburch-LSS commented 1 month ago

a few more quick changes (like integration blocks and parameter passing): v1.0.4. i'll have more probably sometime soon, but i imagine this can be merged anytime...

tburch-LSS commented 1 month ago

if there are problems with the changes, it would be good to know. otherwise, this could all be merged... cheers!

greenwoodms06 commented 1 month ago

Could I make a request since you've been working with this actively? Could you add a section to the README.md to help orient the user on how to add the gsl.lib file to the project? I assume that is fresh in your mind. Thoughts?

tburch-LSS commented 1 month ago

yes, i could do something like that. i just need to know a bit more about what needs to be explained. is there a problem in general with libgsl now? or just with the new integration routines? i work within a linux/openmodelica environment, so i could imagine that something might not work the same in windows or with dymola.

if it's just the new integration stuff, i've already put together some things in the info sections, so i can add it to the README. just let me know... thanks!

tburch-LSS commented 1 month ago

i added the overview and a section on the interface to the README. let me know if there's anything else i should add or if there are any problems which you've noticed. thanks!

tburch-LSS commented 1 month ago

if there are problems with a connection editor on windows finding libgsl or libgsl_integration_MI, this may stem from a few things: 1. linux systems add the "lib" by default, apparently windows may not (?); 2. i moved the libraries into their respective "linux64" and "win64" directories; 3. i changed the annotations in the GSL function calls to be without the "lib" prefix. so 1 and 3 might make it that the gsl library and the interface might not be found on windows. if this is the case, it would be good to know. i can make the necessary changes and commit them...

greenwoodms06 commented 1 month ago

The main branch simulates from a fresh download/clone. The branch attempting to merge does not. It could be the issues you are referring too. Can you attempt to make the necessary changes to correct this please. Thanks.

tburch-LSS commented 1 month ago

could you supply a bit more info about what goes wrong? e.g.: what OS and connection editor is being used? what "does not simulate"? any example model? or just the new integration ones? if only the latter, was an "integrand setup" model run first? thanks.

(i already committed the changes i mentioned in my last comment.)

greenwoodms06 commented 1 month ago

Sure. Let's see if we can figure out what could be the culprit.

My initial tests are with the existing examples and not the new ones added.

When I pull the main branch on this repo I can open the library on Dymola Windows and run the existing examples. For example, GNU_ScientificLibrary.Examples.specfunc.Bessel_1stKind.

However, when I pull your branch those i get compiling issues with a reference to gsl.lib image

Does this help you figure out what was changed that is causing things to break?

tburch-LSS commented 1 month ago

ouch! so dymola can't open gsl.lib... googling "LNK1181" appears to bring up a bunch of problems involving the library path, but i put it into default location: modelica://GNU_ScientificLibrary/Resources/Library/win64/ . i removed the "lib" prefix on the dll file. supposedly that's what's needed for windows. you could try to rename the lib with that again... another possibility: i believe the dll's for windows are rather old ones. if you have compiled versions for gsl v2.7, they should probably replace the ones here. i can also have a look to see if compiled versions are available at the gsl site.

greenwoodms06 commented 1 month ago

Frankly I'm kind of at a loss too. Based on the Dymola documentation, it seems like everything should work. I tried to modify the original main and I was able to reproduce the issue I am seeing by adding the win64 folder. When I add that it throws errors regardless of if I move the dll files to win64 or just leave them where they are in Library...

Now to determine if this is somehow a Dymola bug or if there is some additional step required that is being missed... hmm...

tburch-LSS commented 1 month ago

there is this real-pain-in-the-butt issue with the linux/win "lib" prefix. one thing you could try: since you're trying to run the first example, you could alter the line:

external "C" y=gsl_sf_bessel_J0(x) annotation(Library="gsl");

in Functions.specfunc.bessel_J0 to have "libgsl" instead. you could do the same with bessel_Jn and bessel_In and then see if the example works.

greenwoodms06 commented 1 month ago

I was able to recreate some of the issue: 1) If I add the win64 folder, even if the dll files are in the top level, it will cause an error. 2) If I add the files to the win64 folder it still fails. 3) If I switch the win64 to win32 then it will run (if they are called libgsl and the Modelica code uses libgsl). Apparently the one there was built for 32. 4) If I rename to gsl.dll and update Modelica code to gsl then it fails again.

It seems strange to me that it won't work when named only "gsl". Will the linux version work if "libgsl" is called instead of "gsl" ?

tburch-LSS commented 1 month ago

sigh it seems this "lib" prefix issue will never go away. (we are not the only ones having trouble with this.) i can get it to work on linux with the prefix, but then one has to create symbolic links for liblibgsl.so to find libgsl.so... a rather ugly fix that many seem resigned to use. i was hoping to get rid of this and thought i found out how, but it seems not. so i guess i'll have to switch everything back to libgsl and move the dll's to a win32 folder. i could find no win64 binaries. i guess one has to build them using mingw64/msys2.

tburch-LSS commented 1 month ago

ok. i changed everything back to containing the "lib" prefix. i even changed the linux libraries to "liblib...". i don't like it, but i don't see any other fix for now. hoping this can be merged. let me know if there are any other problems.

greenwoodms06 commented 1 month ago

I grabbed and checked one example and it simulates now! I'll try to do a more thorough check later today and then approve the merge if it checks out.

tburch-LSS commented 1 month ago

good! it would be good to try out the new integration examples and see if all works ok. with linux / openmodelica all appears fine. it's great that you can also check the windows / dymola perspective.

greenwoodms06 commented 1 month ago

So i ran all the tests. The failed tests on Windows are:

tburch-LSS commented 1 month ago

ok. another attempt... i fixed the "Params" issue in that one specfunc example... and i simplified the 'CreateIntegrand' model (and the others like it). now, there are no 'equation' sections. the 'integrand_setup' function is called via the initialization of a parameter. if your system has gcc and its location is in your PATH, then these should work (fingers crossed).

greenwoodms06 commented 1 month ago

Bad news. None of the integration bits work. I tried:

The way I am doing it is just loading the library and running the CreateIntegrand and the ExampleIntegral. It gives the error of not finding libgsl_integration_MI.so. Is this the correct thing to do?

If we need to just merge this and have a disclaimer that integration only works on OMEdit - Linux I am ok with that unless you can have access to a windows system and at least verify it works on OMEdit - Windows too... If you can get it working there it should surely work for Dymola too... I did find it curious that Dymola-Linux didn't work... I expected that to work...

Thoughts?

tburch-LSS commented 1 month ago

yes, that sounds like the correct approach. hmm... the problem seems to be that, for whatever reason, libgsl_integration_MI.so is not being created... or that it is not in the correct path.

for the first and third approach, since you're working with win64, do you also have gsl for 64-bit installed elsewhere? if not, there may be problems since the dll in Library/ is only for 32-bit (gcc via msys). we may need to provide 64-bit versions of the libgsl....dll's for windows.

i cannot imagine out what's the problem with the second approach.

i will try out an installation of OMEdit on a windows machine and see if i can figure out what the problem may be. thanks!

tburch-LSS commented 3 weeks ago

well, i learned some things... i hadn't realized that the windows version of OpenModelica provides the msys tools as well. i tried out the integration examples there and found the problem: a missing -llibgsl in the linking command (along with the proper ordering) in 'integrand_setup'. i am able to run the integration examples using OMEdit on 64-bit windows. the only other pitfall is that one might need to set the PATH environment variable to include the location of gcc. i mention this in the README.

the only thing i can't test is Dymola.

tburch-LSS commented 3 weeks ago

i had to add a 'foo' file to create the win64 Library folder. git apparently won't add empty directories.

greenwoodms06 commented 2 weeks ago

It worked for me on OMEdit. So I'll go ahead and merge this now.

tburch-LSS commented 2 weeks ago

great! thanks!