compiling error: "pyconfig.h: No such file or directory"

[elafnm]

Greetings dear @roigcarlo,

I am trying to recompile kratos, and I am getting this error "fatal error: pyconfig.h:No such file or directory" as shown here:

In file included from /home/elaf/boost_1_59_0/boost/python/detail/prefix.hpp:13:0,
                 from /home/elaf/boost_1_59_0/boost/python/args.hpp:8,
                 from /home/elaf/boost_1_59_0/boost/python.hpp:11,
                 from /home/elaf/Kratos/applications/ULFapplication/custom_python/kratos_ulf_python_application.cpp:48:
/home/elaf/boost_1_59_0/boost/python/detail/wrap_python.hpp:50:23: fatal error: pyconfig.h: No such file or directory
compilation terminated.

how can I resolve this issue please. I think it has to do with "#include <boost/python.hpp>"; but not sure exactly.

kindly note, kratos applications will be compiled fine. However, I am getting this error only when I am trying to include "ULF application, Incompressible fluid application, or structural application"

thanks and best regards,

[maceligueta]

hi @elafnm , during the last weeks, most of the Kratos Community has removed the dependency of Kratos on the library Boost-python. Now, the communication between C++ and Python is no longer carried out by boost-python, but by Pybind, a library which is included in Kratos. All applications need some adaptation, and we all are willing to help. Actually, a guide for 'porting to pybind' was written in the wiki: https://github.com/KratosMultiphysics/Kratos/wiki/Porting-to-PyBind11---common-steps Apparently, these steps have not been done for the ULF application yet. Whoever is maintining this application should take a look on this. Maybe @playpaolo ?

[playpaolo]

Thanks @maceligueta! I will have a look at it

[elafnm]

Greetings dear @playpaolo,

I will create a new branch and try to do it if you don't mind please,

best regards,

[playpaolo]

Hi @elafnm . Okay. Please let me know which branch it is

[RiccardoRossi]

Pavel, is the ULF in master ported?

[playpaolo]

@RiccardoRossi, what does "master ported" mean? Around two months ago we pushed it and it joined the master.

[RiccardoRossi]

@playpaolo i think i missed a comma. I am asking if the version fo the ULF application which can be found in the master branch includes the necessary changes to compile with pybind11. I guess that this also depends on the incompressible fluid application to be ported.

[elafnm]

greetings dear @RiccardoRossi

do you mean as per the guidelines in the link below: https://github.com/KratosMultiphysics/Kratos/wiki/Porting-to-PyBind11---common-steps

I am planning to follow these steps for ULF soon, please let me know if I need to consider something else as well.

best,

[elafnm]

Greetings dears @roigcarlo,

the ULF application is compiled now. Accordingly, we created a new branch "compile_ULF" where we pushed the changes,

However, one of the test_examples, "lagrangian_sessile_droplet", inside the ULF application is not working as it should be; where now, no nodes being added as coded "where nodes should be added utilizing one of the MeshingApplication external_include files (trigen_droplet_refine.h)"

do you think this has to do with pybind when linking our code to the meshing application,

One more comment please, since I got an error while executing this example

ImportError: generic_type: "SoveingStrategy" is already registered!

so I had to keep the "SoveingStrategy" class binding localized to the ULF module as:

class_< BaseSolvingStrategyType, BaseSolvingStrategyType::Pointer >(m,"SolvingStrategy", module_local())

as I am not sure if this will be working fine for kratos, noting that it was not defined locally before pybind and we did not face any si errors before,

best,

[roigcarlo]

Dear @elafnm, very glad to hear you managed to compile the app. Boost was a little bit more lenient with the conflicts, so maybe there is a name clash in the ULF application. I'll take a look asap

[playpaolo]

Hi @elafnm and @roigcarlo, I am compiling it now on my comp. Lets see

[playpaolo]

@roigcarlo, what should one do with the lines corresponding to BOOST inside configure.sh file? Should they be deleted?

[roigcarlo]

You have to leave the -BOOST_ROOT, everything else related with boost should be deleted

[playpaolo]

@roigcarlo thanks! And what about -DPYTHON_LIBRARY="C:\Python34\libs\python34.lib" (thats what is written in the instruction), but I cannot find pytho34.lib. Cant we use: -DPYTHON_LIBRARY="/usr/lib/python3.4/config-3.4m-x86_64-linux-gnu/libpython3.4.so" \ ?

[roigcarlo]

hi @playpaolo -DPYTHON_LIBRARY and -DPYTHON_INCLUDE_DIR should be removed as well. Instead you should add -DPYTHON_EXECUTABLE which should point to the python binary. For example:

-DPYTHON_EXECUTABLE="C:\Python34\python.exe"

Notice that now you can use anaconda, pypy and similars as long as you target the .exe file are well if you like to do so

[playpaolo]

Ahora tira: /home/pavel/boost_1_66_0/boost/python/detail/wrap_python.hpp:50:23: fatal error: pyconfig.h: No such file or directory

include

[roigcarlo]

Hi @pablobecker this means there is still some boost/python.h include somewhere in the application that should be removed.

I took a quick look at the code in the compile_ULF and it seems that there are several parts of the code that are still not ported. I imagine most of the problems come from here: ULFapplication/custom_python/add_custom_io_to_python.cpp.

Leaving pybind aisde, I also noticed that you have includes to to #include "boost/smart_ptr.hpp". You should try to delete those as well as now we work with the std variant and may cause problems.

[playpaolo]

Hi @roigcarlo, thanks! i will look through the app now and check these

[playpaolo]

Hi @elafnm! There are more than 20 files with insludes of boost. I am cleaning them now.

[playpaolo]

@elafnm: There are more than 20 files with includes of boost.

all the matrix declarations that were using boost types should be modified as:

BoundedMatrix<double, NumNodes, Dim> DN_DX; (instead of what we had before: boost::numeric::ublas::bounded_matrix<double, NumNodes, Dim> DN_DX;)

[playpaolo]

@roigcarlo please see the above comment! Should we change the types of matrices so as not to depend on boost? Or can we leave it?

[roigcarlo]

@playpaolo, @elafnm Yep matrices will be better with the new signature, but this does not directly cause any problem with pybind.

[elafnm]

Greetings dear @playpaolo

I agree with you, and they are changed accordingly in the compile_ULF branch

Best,

[roigcarlo]

@elafnm Ho, I see, I was just watching the result matches but they correspond to the old commented code, everything fine then with the matrices :+1:

[elafnm]

Greetings dear @roigcarlo

Thank you for you help,

Please note that we are not using ULFapplication/custom_python/add_custom_io_to_python.cpp in CMake,

I will remove all the boost includes soon and let you know dear

Also please note I modified all signatures except boost::timer, I kept as is

Best,

[playpaolo]

Hi @elafnm, when putting includes please pay attention that you cannot specify the specific directories from your computer, like what you did here for example: #include "/home/elaf/Kratos/applications/ULFapplication/ULF_application_variables.h". These pathes cannot be used by any other user.

It should be: #include "ULF_application_variables.h"

[elafnm]

Thank you dear @playpaolo, sure I will consider it,

Best,

[elafnm]

Greetings @playpaolo,

Only one example is running with me, the Laplacian_droplet. However, the code is not running for the sessile droplet. I am not sure why...

Best,

[playpaolo]

hi @elafnm . The wrong pathes are still there.

/home/pavel/Kratos/applications/ULFapplication/custom_elements/surface_tension.h:48:85: fatal error: /home/elaf/Kratos/applications/ULFapplication/ULF_application_variables.h: No such file or directory

include "/home/elaf/Kratos/applications/ULFapplication/ULF_application_variables.h"

                                                                                 ^

It shuld be: /home/pavel/Kratos/applications/ULFapplication/custom_elements/surface_tension.h:48:85: fatal error: /home/elaf/Kratos/applications/ULFapplication/ULF_application_variables.h: No such file or directory

It should be:

include "ULF_application_variables.h"

[playpaolo]

Hi @RiccardoRossi! We are moving ULF to pybind. There is one big problem. ULF depends on things from structural_application, in particular, it uses: ResidualBasedPredictorCorrectorBossakScheme But structural_application is not maintained anymore. I could not find where the scheme I was using is moved to...

[elafnm]

Greetings dear @roigcarlo,

I am not sure why I receive the following error if I use "#include "ULF_application_variables.h" instead of the full path "#include "/home/elaf/Kratos/applications/ULFapplication/ULF_application_variables.h"

fatal error: ULF_application_variables.h: No such file or directory

Also, when I run an example, I receive the following:

KratosMeshingApplication.cpython-35m-x86_64-linux-gnu.so: undefined symbol: _ZN6Kratos12TRIPLE_POINTE

it seems I am having an issue with pybind when calling some functions from my droplet_trigen.h file inside the meshing application; where before my example was running fine,

any idea please how to resolve these two points,

best regards,

[roigcarlo]

Dear @elafnm

I cannot reproduce the include error. I compiled in my machine and it works ( I was only having problem in the include located in ULFapplication/custom_elements/surface_tension.h

As for the second problem it seems that you are trying to use the variable TRIPLE_POINT in the meshing application, but it is defined in the ULF Application, so it is not visible from the Meshing application point of view.

If you need that variable to be used in the meshing we should move the definition to the core

[playpaolo]

Hi @roigcarlo, you didnt have the error, because I corrected it and pushed the file. I believe that @elafnm is missing specifying the path to the application somwhere.

On the other hand I am having some problems with matrices due to changing the types. For example, by now I had the following in my python scripts:

self.pA = self.space_utils.CreateEmptyMatrixPointer() self.A = (self.pA).GetReference()

Now I cannot execute: self.A = (self.pA).GetReference() since 'Kratos.CompressedMatrix' object has no attribute 'GetReference'.

How can this function be replacred? Thanks!

[elafnm]

Greetings @playpaolo and @roigcarlo

Thank you for your help,

today I will do the required modification (defining triple point in core) from my side and will let you know,

Best,

[playpaolo]

@roigcarlo Of course I can make a copy, but is it clean? self.A = self.pA

[roigcarlo]

@playpaolo I am not familiar with the matrix interface in python. Not sure that code makes a copy but probably someone from @KratosMultiphysics/technical-committee knows it better than I do

[elafnm]

greetings dear @playpaolo and dear @roigcarlo,

I added three variables in the core, and we did minor modifications in our code... and the code is running fine now

I merged the master to compile_ULF branch, and compiled it again, and seems fine for my code

please let me know if you want me to ask for a pull request and close this issue...

thanks and best regards,

[playpaolo]

Hi @elafnm! thanks for the modifications. Please wait with the pull request because by now not all the ULF application is updated accordingly (all the python files that are not related to your surface tension work are not updated). I will update the python scripts of the ULF application and then we will proceed with the pull request.

[playpaolo]

Dear @elafnm, which three variables did you add to the core?

[elafnm]

greetings dear @playpaolo

sorry for late reply, it is only due to the time difference. Kindly find them below:

KRATOS_DEFINE_VARIABLE(double, TRIPLE_POINT)
KRATOS_DEFINE_VARIABLE(double, CONTACT_ANGLE)
KRATOS_DEFINE_3D_VARIABLE_WITH_COMPONENTS(SOLID_FRACTION_GRADIENT)

Also, As per my discussion with Dr. Jarauta, for the 2D embedded case I need to transfer some files from incompressible_fluid_application to the ULF application; could you please provide us with the needed list of files to be transferred (similar to what you advised earlier about the recommended procedure to include the surface_tension files into the ULF application).

best,

[playpaolo]

Dear @elafnm, what does solid_fraction_gradient mean? If you add a new variable to the core, its name should reflect its meaning. If I am not mistaken, SOLID_FRACTION_GRADIENT was an existing variable of one of the applications that Alex used for different purposes. Please make a variable with a different name, making sure that one can understand what it is used form.

Which files of incompressible_fluid_application do you need to transfer? I cannot advise on this as I don't know what exactly you need to take from there. Do you mean the files related to finding the intersections between the Lagrangian and the Eulerian meshes?

As of now we cannot make a pull request as most of the fluid-structure interaction scripts are not working anymore after these latest changes and I am resolving these issues.

We should carefully do the updates to the branch, taking care of what the reciprocal side did (i.e. you regularly do the pull to get my changes and I do the pull to get your changes).

[elafnm]

Greetings dear @playpaolo,

regarding " solid_fraction_gradient ", yes dear you are correct it was used by Dr. Jarauta, I met him this week and he informed me that it can be deleted; please let me know if you would like me to remove it now, or shall I wait so I don't interrupt your ongoing updates/activities within the ULF_application,

and regarding the incompressible_fluid_application files, yes dear we are looking for the intersection related files,

best regards,

[loumalouomega]

Is this solved?

[playpaolo]

@elafnm If you want to use my old functions you need the following files of the incompressible_fluid_application:

embedded_utils.h coupled_eulerian_ulf_utilities.h

proj_dirichlet_cond.cpp proj_dirichlet_cond.h

proj_dirichlet_cond3D.cpp proj_dirichlet_cond3D.h

and

apply_proj_dirichlet_process.h

Note however, that my algorithms were written for finding intersections of two meshes in 2D. And these should still be working. As for 3D, you need to use the newest version of distance function for finding the intersected elements in the embedded settings. If you have the distance function working fine (distance function is part of the core, and not of the code I implemented), then I believe you can still use the ProjectionDirichletBoundary conditions to impose the velocity at the intersected elements. In any case I recommend you to read carefully the files to see if all the variables my functions use are still existing in Kratos.

I also think that in 2D it would be better to use a distance function calculation rather than my old algorithm of intersections. But I am not sure if the distance calculatpr in 2D exists. Is that so @roigcarlo ?

Best

[elafnm]

Greetings dear @playpaolo,

sure will do, if you don't mind I will just wait till our pull request get approved, and then will add them in a new branch and open a new pull request.

Thanks and best regards,

[philbucher]

closing since inactive please reopen otherwise