Error in test_KratosCore if FluidDynamicsApplication is not compiled

[armingeiser]

I just noticed that there happens an error in the block of skipping the "test_materials_input.py" if the FluidDynamicsApplication is not compiled.

Running tests for KratosCore
/media/arming/Volume/04_Development/Kratos/kratos/tests/test_KratosCore.py
Traceback (most recent call last):
  File "/media/arming/Volume/04_Development/Kratos/kratos/tests/test_materials_input.py", line 7, in <module>
    import KratosMultiphysics.FluidDynamicsApplication as KratosFluid
  File "/media/arming/Volume/04_Development/Kratos/KratosMultiphysics/FluidDynamicsApplication.py", line 2, in <module>
    from KratosFluidDynamicsApplication import *
ModuleNotFoundError: No module named 'KratosFluidDynamicsApplication'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/media/arming/Volume/04_Development/Kratos/kratos/tests/test_KratosCore.py", line 13, in <module>
    import test_materials_input
  File "/media/arming/Volume/04_Development/Kratos/kratos/tests/test_materials_input.py", line 16, in <module>
    '{0}'.format(e)).group(1)
AttributeError: 'NoneType' object has no attribute 'group'

[armingeiser]

The error happens if the FluidDynamicsApplication.py is available, but the pybind module KratosFluidDynamicsApplication is not. then a ModuleNotFoundError is thrown, and the extraction of the application name from the exception does not work:

    missing_application = re.search(r'''.*'KratosMultiphysics\.(.*)'.*''',
                                    '{0}'.format(e)).group(1)

[jcotela]

Just in case someone else encounters this issue: This error is due to old files remaining in the KratosMultiphysics folder from a past compilation of the FluidDynamicsApplication (FluidDynamicsApplication.py in this case). The easiest fix is to modify your configure.sh to delete the folder KratosMultiphysics before a new compilation, just as we are doing now for libs.

@KratosMultiphysics/technical-committee should we update the example configures (and tutorials) to reflect this?

[roigcarlo]

+1 to indicate that this may happen, but I think the behavior is correct. In fact it is the same problem than when we try to load outdated .so.

Maybe we can extend that RE so it captures this sort of problems. I was not aware of this mechanism, but as it seems that there are several files using it maybe we can even put it as part of the test utils.

[jcotela]

Extending the RE would fix it for this test, but similar statements appear in other parts of the code. In fact, this RE is part of the recommended best practice for skipping tests in the wiki.

If we want to go in this direction, maybe we should provide a method to manage import errors somewhere in the core (or probably in the test suite).

[armingeiser]

The hint of @jcotela solved the issue for me. I'll leave it to you to close it as you maybe consider this in the future.

[philbucher]

@jcotela where is the code that deletes the libs folder while compiling?
I occasionally also struggle with this

[jcotela]

It is not there officially, but most of us have added to our configure.sh at some point...

[philbucher]

Could you please share how you do it?
I am not an expert in this

[jcotela]

Well, in my configure I have

rm -f /home/jcotela/Kratos/libs/*
rm -r /home/jcotela/Kratos/KratosMultiphysics/*

rm CMakeCache.txt

cmake ..  
# cmake options....

(adjust for your local paths etc.) This removes installed files from a previous compilation, which cmake places in the libs (C++) and KratosMultiphysics (Python) folders during make install. It helps when switching between different compilation types, especially if you are not building the same set of applications in all of them.

[philbucher]

thanks @jcotela

[pooyan-dadvand]

It would be better to use CMake to cleanup these folders

[jcotela]

Closing, for now we recommend deleting the installed files (KratosMultiphysics and libs folders) before calling cmake in the configure script if necessary.