symengine / symengine.f90 Goto Github PK

I trying to run the test cases of symengine.f90 on windows 10.

Symengine has been installed using vcpkg. Btw it seems that there is a mismatch between the displayed version (0.10.0) and the actual version (0.9.0) on vcpkg.
I compiled both the x86 and x64 dlls successfully.

Then I compiled symengine.f90 in visual studio 2019, with ifort classic 2021.5.0. I linked the project to symengine.lib and made sure the symengine-0.9.dll ends up in the build folder.

When I run the test I get the following exception right after calling a = SymInteger(12)

The same happens in Release, x64 or x86.

symengine.f90 signals bindings to an old fortran standard. Perhaps we could rename it to symengine.f to avoid the fortran version in the name?

It would be nice if the Fortran wrapper could be built and used as a dependency with fpm.

The challenges are the many libraries that need to be installed and linked. Last time I tried the command needed was:

gfortran -o test_symengine -I/usr/local/include/symengine symengine_cwrapper.o test_symengine.o -L/usr/local/lib -lsymengine -lteuchos -lstdc++ -lmpfr -lgmp -lbfd

Or with the C++ driver as compiler (see #6):

g++ test.o symengine.o /home/symengine/build/symengine/libsymengine.a /home//symengine/build/symengine/utilities/teuchos/libteuchos.a -lgfortran -lgmp -lbfd -otest

@certik, is symengine installable using conda or pip?

Looking at the C header file in SymEngine, one could probably do everything manually. On the long term however, an automatic tool will probably be easier.

Would using Shroud (https://github.com/LLNL/shroud) be an option?

A presentation (PowerPoint file) is also available from FortranCon: https://tcevents.chem.uzh.ch/event/12/contributions/30/attachments/29/98/Taylor-Shroud-forcon.pptx

@ivan-pi posted an example here:

https://fortran-lang.discourse.group/t/code-generation-using-sympy/321/5

use symengine

type(sym_t) :: x, y
type(expr_t) :: f

call f%set([x,y], x**2 + y**2)
call fortran_function(f,'File','myfile')
end

I assume one must overload the + and ** operators, and then make it work with the sym_t type (I would just call it sym, as in Matlab). One issue is about ensuring it does not leak memory, i.e. in: c = a + b + c, it must automatically deallocate the intermediate expressions. The same in x**2+y**2, the operator ** first creates x**2, but then when you do x**2+y**2, it must deallocate the x**2. In C++ and in Python, when the expression goes out of scope, its destructor gets called which deallocates the memory.