Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AbstractState Mathematica Wrapper #2085

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

friederikeboehm
Copy link
Contributor

Description of the Change

[ We must be able to understand the design of your change from this description. If we can't get a good idea of what the code will be doing from the description here, the pull request may be closed at the maintainers' discretion. Keep in mind that the maintainer reviewing this PR may not be familiar with or have worked with the wrapper code being implemented, so please walk us through the concepts. ]

Benefits

Adds a lot of functionality to the Mathematica Wrapper. Especially the use of the interface layer to the low-level interface was not implemented in Mathematica beforehand.

Possible Drawbacks

None

Verification Process

I implemented a mathematica package to use the Library Functions (CoolProp.wl). This also adds error recognition and error messages to the Mathematica Wrapper. This was used in the example.nb Notebook. There I used examples from the CoolProp Homepage (Access from High-Level Interface and Cubic Equations of State - Mixtures) and received the same results.

grafik
grafik
grafik

Applicable Issues

Changes in PR #2084 are used in this one
#2065

@CLAassistant
Copy link

CLAassistant commented Jan 31, 2022

CLA assistant check
All committers have signed the CLA.

@ibell
Copy link
Contributor

ibell commented Feb 3, 2022

Please rebase based on #2084

@friederikeboehm friederikeboehm marked this pull request as draft February 3, 2022 07:58
@friederikeboehm
Copy link
Contributor Author

Please rebase based on #2084

Hi,
I did the rebase and pushed it, but I have a question: I realized I needed to add some more functions to the wrapper for what I am trying to achieve. Should I finish those and make a new pull request later / keep this as a draft or should I go ahead with the current state of the PR?

@ibell
Copy link
Contributor

ibell commented Feb 4, 2022

I would say if you have further changes to make to Lib, best to resolve those first.

@henningjp
Copy link
Contributor

@friederikeboehm - Any progress on this?

A few comments:

  • I'm all for creating a package, but the current practice is to create a "paclet" which includes the package, documentation, and DLL. This paclet could easily be loaded and served from the Wolfram Paclet Server (in beta) - I'm thinking of creating a CoolProp organizational ID on the Wolfram Paclet Server for this and a direct IF97 paclet. I was ready to start working on this by expanding the high-level functions and adding documentation and rolling it into a paclet, when I saw your PR.
  • Noting your changes to example.nb, I would leave the high-level examples in there and not remove them. Maybe three sections are needed:
    • Direct LibraryLink calls to the high-level functions (as they were) using only the DLL
    • High-level function calls (from the package, i.e. PropsSI, Props1SI, PhaseSI, HAProps, etc.)
    • Low-level function calls (per your low-level calls)

I'd like to proceed with some enhancements of my own and can help with the paclet creation. Don't want to get too aggressive if your PR is eminent.

@friederikeboehm
Copy link
Contributor Author

@henningjp Thanks for the input!

Yes, I did made progress on this, just got busy doing other things befor cleaning everything up for the PR. I will try to get to it this week.
So far I've only implemented the functions I need for my specific application but I hope to get around implementing all functions in CoolPropLib eventually. But until then I think the inclusion of the low level interface at all improves the Mathematica wrapper enough that a PR at this stage is useful.

About your comments:

  • I know about paclets, just was too lazy to do it ... Didn't think the package would grow as big as it did and I remembered the paclet process in the Workbench as somewhat tedious. I am hoping this is better with Mathematica 13.0 and will use this as an opportunity to check it out :) I'll update the PR accordingly and am looking forward to your input!
  • about example.nb:
    • I wasn't planning on removing the high-level examples, they are still in there?
    • the current version of the notebook actually somewhat resembels your suggested sections, I just didn't update this PR in too long...

@friederikeboehm
Copy link
Contributor Author

Pushed current state. This PR is now based on PRs #2133, #2134 and #2135
Hoping to get around to the paclet version soon

@henningjp
Copy link
Contributor

@friederikeboehm - Thanks. I'll wait until this settles down before contributing.

I've been using the new Doc Tools in MM 13.0 outside of Workbench. It works pretty good. There are a few bugs yet, but it's workable. I can help with that and/or the paclet-izing if you like. Docs are just tedious, however you do it.

@friederikeboehm
Copy link
Contributor Author

@henningjp Turned out to be less tedious than I thought. Mathematica 13 definetly improved this process! Could automatically generate the documentation notebooks whicht then contain the usage message, guess thats okay for a version 0.0.1
I have a paclet now (https://github.com/friederikeboehm/CoolProp/tree/pacletDev) so far so good, only problem now is: I can only run the generated .dll on the machine I built it on or a machine which has the CoolProp project downloaded as well. If I take a "virgin" machine (wanted to check version compatibility) it cannot load the functions. Any ideas why that might be?
Can you try using the paclet? It can be found here: https://github.com/friederikeboehm/CoolProp/tree/pacletDev/wrappers/Mathematica/CoolProp/build

I think we should open an issue to further discuss paclet development as this wasn't the point of this PR originally.

@ianhbell should I close this PR and open a new one or keep this going on here? Or should we merge this one and do the paclet development in a new one?

@ibell
Copy link
Contributor

ibell commented May 10, 2022

Probably related to DLL hell (not being able to find expected shared libraries, likely standard library ones). That's why I statically link the standard library, although this is not a recommended best practice.

Props1SImulti new function in CoolProp
Implementation comparable to HelmholtzEOSMixturebackend
See PR CoolProp#1371 (4014f85)

Minor changes to CubicBackend.cpp
If phase is imposed, it is returned
instead of always returning gas phase for mixtures
TODO is not properly fixed though
AbstractState_get_mole_fractions_satState
AbstractState_keyed_output_satState
AbstractState_backend_name
add_fluids_as_JSON

changes to AbstractState_get_phase_envelope_data
Add PhaseSI, test.nb and filterNotebooks.bat

filterNotebook.bat utilizes Notebook-Filter to clean up Mathematica .nb
files

Fix memory leak

String handling in Mathematica...

Add Abstract_State_factory for Mathematica

Add Abstract_State_free

Add get_input_pair_index

Add get_param_index, AS_update and AS_keyed_output

Add Abstract_State_set_fractions

Add AbstractState_set_binary_interaction_double

test.nb contains examples from CoolProp documentation regarding
low level access from the high level interface
and accessic cubic EoS mixtures

Add get_global_param_string and many fixes

fix char pointers
fix function names

Add error handling for mathematica

Add Mathematica Package to load LibraryFunctions

Supports error messages
CoolPropMathematica.cpp minor changes

Add AbstractState_get_mole_fractions  CoolPropLib

Add AbstractState_set_fractions, get_input_pair_description
and get_parameter_information to Mathematica Wrapper

Add AbstractState_fluid_names to CoolPropLib

Add AbstractState_fluid_names to Mathematica Wrapper

Add get_cubic_fluids_list to Mathematica Wrapper

Add pattern matching for Mathematica Wrapper

Functions overloaded, error message generation for incorrect type entry
Syntax highlighting for number of Arguments

Add AbstractState_specify_phase

Build Phase Envelope

Fix CoolProp.wl

Add ReadPhaseEnvelopeData

Add AbstractState_keyed_output_satState

Add AbstractState_get_mole_fractions_satState

Proper Calls to Saturated State

Add Comments

add_fluids_as_JSON

Add get_fluid_as_JSON

Add AbstractState_set_cubic_alpha_C

Add Boolean and Fix List of Reals

Add fluid_param_string to cubic backend

Add PropsSImulti to CoolPropLib

Add PropsSImulti to Mathematica wrapper

Add Props1SImulti

Add Props1SImulti to Mathematica wrapper

Add Props1SImulti and PropsSImulti to CoolProp.wl

Files formatted

Format Mathematica wrapper

Add Props1SI to Mathematica wrapper

Add set_buffer_length to Mathematica wrapper

Keep imposed phase for cubic backend

AbstractState -> AS in Mathematica

Fix Buffer for multi outputs

example.nb überarbeitet

Add ASSetCubicAlpha to CoolProp.wl
@friederikeboehm
Copy link
Contributor Author

friederikeboehm commented May 11, 2022

I tried (and think succeeded) in statically linking only to realise, static librarys seem not to work with Mathematica...

But I did manage to get it working! Including and loading three missing dlls, that are not part of standard Windows (see https://github.com/friederikeboehm/CoolProp/tree/pacletDev/wrappers/Mathematica/CoolProp/LibraryResources/Windows-x86-64) did the trick.

@ibell how should I proceed with this PR (see above, tagged your other account last time)?

@henningjp The package is working on Windows now, can you test it?

  1. Download CoolProp-0.0.2.paclet from https://github.com/friederikeboehm/CoolProp/tree/pacletDev/wrappers/Mathematica/CoolProp/build
  2. Install the Paclet:
    PacletInstall[PathToPaclet <> "CoolProp-0.0.2.paclet"]
  3. Load the CoolProp-Package:
    Needs@"CoolProp`"
  4. List the Functions:
    ?"CoolProp`*"
  5. Try them out! Documentation should work as well!

@henningjp
Copy link
Contributor

@friederikeboehm - This is pretty incredible. I've only just loaded it and started testing, but everything behaves as I'd expect. Installing the paclet was seamless. I'll poke at it some more in the evenings. I have a Mathcad verification document that I'll try and recreate in Mathematica and check that everything is behaving. So far returned values seam reasonable. It'll take some time to work through all the functions.

My wheels are spinning already on fleshing out the docs to be more "Wolfram like", but we can do that later.

Nice work!

I'm tied up this weekend so it may take me into next week to check it all out.

@henningjp
Copy link
Contributor

Only high level PropsSI and Props1SI tested so far, but backends working.

CP Test-1

@henningjp
Copy link
Contributor

@friederikeboehm Some thoughts, which you may already be considering:

  1. Consider using a .ignore file in the paclet direcotry to ignore the paclet/build directory. This will keep binaries out of the repository (Ian will be grateful) and built copies of the documentation. These are redundant if the pacletDev notebook is there for users to roll their own paclet, which will overwrite that /build directory anyway.

  2. I believe there's a way to list the resource file in the PacletInfo.wl file and make it point to the different resource directories depending on the platform being built on. I've not done this myself yet, but I'm pretty sure that capability is there. Maybe it's doing this already without the entries in the PacletInfo file (there were lots of changes in v13.0). I haven't pulled the whole branch to try it myself yet and won't get a chance until next week.

  3. If users don't want to roll their own paclet (or have the resources to do so), we can put various version binaries on the Wolfram Paclet Repository for remote paclet server installs.

@friederikeboehm
Copy link
Contributor Author

@henningjp Some of your points I actually did consider:

  1. I already added a .ignore file which ignores build/CoolProp. I did not exlude all of build to include the paclet file (which is automatically saved there). The built copies of documentation etc. are not tracked by git. We can of course exclude it in the future, this was just easiest to make it available to you.
    https://github.com/friederikeboehm/CoolProp/blob/pacletDev/wrappers/Mathematica/.gitignore
    One thing I am wondering about are the DLLs I had to add to the paclet files in https://github.com/friederikeboehm/CoolProp/tree/pacletDev/wrappers/Mathematica/CoolProp/LibraryResources/Windows-x86-64. Should they live on this Repo or should the instructions for building the paclet include copying these files there?
  2. Also thought about this. As long as the .dll, .so or dylib files are placed in the right directory under CoolProp/LibraryResources, Mathematica will automatically find the correct file for the used platform. It is worth considering making separate Paclets for each platform, so end users don't have to load all files for e.g. Windows on ther Linux machine. You can do that by specifying SystemID in PacletInfo.wl
    From https://reference.wolfram.com/language/tutorial/Paclets.html#1453777398:

For example, you might have a paclet that includes a large executable or a large LibraryLink library, and there will be a different one for each SystemID. You could make a single paclet that contained subdirectories for each SystemID, but this might become very large, having copies of each binary for each system. You do not want your users to have to download tens of megabytes of libraries for operating systems they are not using. Instead, you can split your paclet up into paclets "qualified" by the SystemID for which they are intended.

  1. Don't fully understand, what versions you are referring to. Mathematica or CoolProp?

@henningjp
Copy link
Contributor

henningjp commented May 21, 2022

@friederikeboehm - Ignore third item, I didn't realize that it would bundle all existing OS versions into a single paclet. I think that's the way to go.

@henningjp
Copy link
Contributor

@friederikeboehm Are you still working on this? I liked where it was going.

@friederikeboehm
Copy link
Contributor Author

@henningjp Kind of, I am using what I implemented, just never fot around to finishing it to a point to make it worth publishing... What would you think is a good way to bring this to a nice form?

@henningjp
Copy link
Contributor

@friederikeboehm - I'll take a look at what you have on your site and see. I noticed that the WIP PR is now quite out of date with the current state of CoolProp with some conflicts. I have a personal interest in

  1. Implementing this in a paclet
  2. providing the other OS resources (I can help with the Linux version/testing)
  3. providing doc pages that match the built-in Help style and structure.
  4. putting a CoolProp paclet out on the Wolfram paclet repository (requires some additional paclet mods)

I'll check your repo over the next week or so and see where it stands.

@friederikeboehm
Copy link
Contributor Author

I've kept my private repo somewhat up to date (currently on a commit from mid-January), I'll try to clean up and update to the current master over the weekend!
I have actually already implemented a Linux version, just not sure how to distribute, but I'll try

@friederikeboehm
Copy link
Contributor Author

@henningjp Didn't get around to it until today. I've kept the changes on a different branch so far (https://github.com/friederikeboehm/CoolProp/tree/pacletDev/wrappers/Mathematica) as I'm still not sure what should live on the official CoolProp repo and what shouldn't (i.e. other DLLs necessary to make it run on other Windows machines).
For the paclet repository I am wondering how to handle the Linux library, if I compile on my machine (WSL) I cannot use it on my university cluster.
Feel free to let me know your thoughts!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants