compilation failure for TwoPhaseFlowEngine.cpp, missing header?

Asked by Kenneth Hoste

I'm running into the following compilation failure with Yade 2018.02b when compiling with both g++ 6.4.0 and the Intel C++ compiler 2018 update 1:

In file included from /tmp/trunk-2018.02b/pkg/pfv/TwoPhaseFlowEngine.hpp:18:0,
                 from /tmp/trunk-2018.02b/pkg/pfv/TwoPhaseFlowEngine.cpp:16:
/tmp/easybuild_obj/pkg/pfv/FlowEngine_TwoPhaseFlowEngineT.hpp: At global scope:
/tmp/easybuild_obj/pkg/pfv/FlowEngine_TwoPhaseFlowEngineT.hpp:44:152: error: ‘FlowBoundingSphere’ in namespace ‘CGT’ does not name a template type
 template<class _CellInfo, class _VertexInfo, class _Tesselation=CGT::_Tesselation<CGT::TriangulationTypes<_VertexInfo,_CellInfo> >, class solverT=DEFAULTSOLVER >
                                                                                                                                                        ^~~~~~~~~~
/tmp/easybuild_obj/pkg/pfv/FlowEngine_TwoPhaseFlowEngineT.hpp:44:170: error: expected ‘>’ before ‘<’ token
 template<class _CellInfo, class _VertexInfo, class _Tesselation=CGT::_Tesselation<CGT::TriangulationTypes<_VertexInfo,_CellInfo> >, class solverT=DEFAULTSOLVER >
                                                                                                                                                                          ^

/tmp/trunk-2018.02b/pkg/pfv/TwoPhaseFlowEngine.hpp:232:15: error: ‘solver’ was not declared in this scope
   int label = solver->T[solver->currentTes].cellHandles[cellId]->info().label;
               ^~~~~~
/tmp/trunk-2018.02b/pkg/pfv/TwoPhaseFlowEngine.hpp: In member function ‘boost::python::list TwoPhaseFlowEngine::getPotentialPendularSpheresPair()’:
/tmp/trunk-2018.02b/pkg/pfv/TwoPhaseFlowEngine.hpp:244:4: error: ‘RTriangulation’ was not declared in this scope
    RTriangulation& Tri = solver->T[solver->currentTes].Triangulation();
    ^~~~~~~~~~~~~~
/tmp/trunk-2018.02b/pkg/pfv/TwoPhaseFlowEngine.hpp:244:20: error: ‘Tri’ was not declared in this scope
    RTriangulation& Tri = solver->T[solver->currentTes].Triangulation();
                    ^~~
...

Does this ring any bells for anyone?

My C++ isn't that good, but after looking around for similar errors it seems like this could be due to a missing `include` (although I don't understand how this could not be known already).

However, the header files where `DEFAULTSOLVER` is defined as `CGT::FlowBoundingSphere<_Tesselation>` (i.e. `pkg/pfv/FlowEngine.hpp`) and where the `FlowBoundingSphere` class in the `CGT` namespace is defined (i.e. `lib/triangulation/FlowBoundingSphere.hpp` are both included in `/pkg/pfv/FlowEngine_TwoPhaseFlowEngineT.hpp`, so I don't understand what the problem is...

I suspect the first problem w.r.t. `FlowBoundingSphere` is the real problem, while the others are potentially caused by the perceived syntax error?

Question information

Language:
English Edit question
Status:
Solved
For:
Yade Edit question
Assignee:
No assignee Edit question
Solved by:
Kenneth Hoste
Solved:
Last query:
Last reply:
Revision history for this message
Chareyre (bruno-chareyre-9) said :
#1

Hi, I can't check details at the moment but I would suggest checking out
the latest version of the sources. It sounds like a mistaken combination of
#def/#ifdef in this specific version or something of this sort.
Probably already fixed.
Bruno

Le lun. 20 août. 2018 10:17, Kenneth Hoste <
<email address hidden>> a écrit :

> New question #672510 on Yade:
> https://answers.launchpad.net/yade/+question/672510
>
> I'm running into the following compilation failure with Yade 2018.02b when
> compiling with both g++ 6.4.0 and the Intel C++ compiler 2018 update 1:
>
>
> In file included from
> /tmp/trunk-2018.02b/pkg/pfv/TwoPhaseFlowEngine.hpp:18:0,
> from
> /tmp/trunk-2018.02b/pkg/pfv/TwoPhaseFlowEngine.cpp:16:
> /tmp/easybuild_obj/pkg/pfv/FlowEngine_TwoPhaseFlowEngineT.hpp: At global
> scope:
> /tmp/easybuild_obj/pkg/pfv/FlowEngine_TwoPhaseFlowEngineT.hpp:44:152:
> error: ‘FlowBoundingSphere’ in namespace ‘CGT’ does not name a template type
> template<class _CellInfo, class _VertexInfo, class
> _Tesselation=CGT::_Tesselation<CGT::TriangulationTypes<_VertexInfo,_CellInfo>
> >, class solverT=DEFAULTSOLVER >
>
>
> ^~~~~~~~~~
> /tmp/easybuild_obj/pkg/pfv/FlowEngine_TwoPhaseFlowEngineT.hpp:44:170:
> error: expected ‘>’ before ‘<’ token
> template<class _CellInfo, class _VertexInfo, class
> _Tesselation=CGT::_Tesselation<CGT::TriangulationTypes<_VertexInfo,_CellInfo>
> >, class solverT=DEFAULTSOLVER >
>
>
> ^
>
> /tmp/trunk-2018.02b/pkg/pfv/TwoPhaseFlowEngine.hpp:232:15: error: ‘solver’
> was not declared in this scope
> int label =
> solver->T[solver->currentTes].cellHandles[cellId]->info().label;
> ^~~~~~
> /tmp/trunk-2018.02b/pkg/pfv/TwoPhaseFlowEngine.hpp: In member function
> ‘boost::python::list TwoPhaseFlowEngine::getPotentialPendularSpheresPair()’:
> /tmp/trunk-2018.02b/pkg/pfv/TwoPhaseFlowEngine.hpp:244:4: error:
> ‘RTriangulation’ was not declared in this scope
> RTriangulation& Tri = solver->T[solver->currentTes].Triangulation();
> ^~~~~~~~~~~~~~
> /tmp/trunk-2018.02b/pkg/pfv/TwoPhaseFlowEngine.hpp:244:20: error: ‘Tri’
> was not declared in this scope
> RTriangulation& Tri = solver->T[solver->currentTes].Triangulation();
> ^~~
> ...
>
>
> Does this ring any bells for anyone?
>
> My C++ isn't that good, but after looking around for similar errors it
> seems like this could be due to a missing `include` (although I don't
> understand how this could not be known already).
>
> However, the header files where `DEFAULTSOLVER` is defined as
> `CGT::FlowBoundingSphere<_Tesselation>` (i.e. `pkg/pfv/FlowEngine.hpp`) and
> where the `FlowBoundingSphere` class in the `CGT` namespace is defined
> (i.e. `lib/triangulation/FlowBoundingSphere.hpp` are both included in
> `/pkg/pfv/FlowEngine_TwoPhaseFlowEngineT.hpp`, so I don't understand what
> the problem is...
>
> I suspect the first problem w.r.t. `FlowBoundingSphere` is the real
> problem, while the others are potentially caused by the perceived syntax
> error?
>
> --
> You received this question notification because your team yade-users is
> an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp
>

Revision history for this message
Kenneth Hoste (kenneth-hoste) said :
#2

Thanks for the feedback.

I tried using the latest sources in master (commit c15b274), but I'm still hitting the same problem, so this issue is not fixed with the latest master.

I'm following the same build procedure that worked fine for earlier versions of Yade (e.g. 2017.01a), albeit with slightly older compilers...

Could this be an issue with the compiler versions?

Revision history for this message
Chareyre (bruno-chareyre-9) said :
#3

Ok, thanks. Could you show the logs of cmake?
Bruno

Le mar. 21 août. 2018 12:23, Kenneth Hoste <
<email address hidden>> a écrit :

> Question #672510 on Yade changed:
> https://answers.launchpad.net/yade/+question/672510
>
> Status: Answered => Open
>
> Kenneth Hoste is still having a problem:
> Thanks for the feedback.
>
> I tried using the latest sources in master (commit c15b274), but I'm
> still hitting the same problem, so this issue is not fixed with the
> latest master.
>
> I'm following the same build procedure that worked fine for earlier
> versions of Yade (e.g. 2017.01a), albeit with slightly older
> compilers...
>
> Could this be an issue with the compiler versions?
>
> --
> You received this question notification because your team yade-users is
> an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp
>
>

Revision history for this message
Kenneth Hoste (kenneth-hoste) said :
#4

I have upload the full log to https://gist.github.com/boegel/3747157a2b453e7edeb76a27ccf54d83 (make sure you download the full log, since it's trimmed by default).

This is an EasyBuild (http://easybuilders.github.io/easybuild/) log file, so it also contains a lot of other stuff.

You can find the relevant output at:

* line 2276: 'cmake' command + output
* line 2513: 'make' command + output
* line 16072: compiler errors

Revision history for this message
Bruno Chareyre (bruno-chareyre) said :
#5

Hi Kenneth,
Thanks for reporting.
It was due to compiling with PFVFLOW disabled but the dependent feature TWOPHASEFLOW enabled.

Running cmake with -DENABLE_TWOPHASEFLOW=OFF would not have shown the problem, but obviously it would need to update all existing build-scripts like yours since TWOPHASEFLOW is a new feature.
I thus fixed it directly in our cmake file [1]. After this revision it should compile without a change in your build process (TWOPHASEFLOW will be automatically disabled). Could you please confirm?

Bruno

[1] https://github.com/yade/trunk/commit/6828270c6ea1f065742e7b584fafaee52610a124

Revision history for this message
Kenneth Hoste (kenneth-hoste) said :
#6

Hi Bruno,

Thank you very much for the feedback, I don't think I would have been able to figure that out by myself, despite spending several hours on it... Did I mention I'm not a big fan of either C++ or CMake? Deadly combo here... ;)

I can confirm that:

* using the patch fixes the problem with (only) PFVFLOW disabled, the CMake output includes "-- TWOPHASEFLOW was disabled automatically because PFVFLOW is disabled"

* not disabling PFVFLOW also fixes the issue; that setting was inherited from a build script of an older Trilinos version, I should check why we had it disabled but it probably was to work around compilation problem (which now seems to be resolved)

Revision history for this message
Bruno Chareyre (bruno-chareyre) said :
#7

> I'm not a big fan of either C++ or CMake? Deadly
> combo here... ;)
Indeed :)

> * not disabling PFVFLOW also fixes the issue [...] I should check why we
> had it disabled but it probably was to work around compilation problem
> (which now seems to be resolved)
I would bet on library-related problems (openblas or suitesparse (cholmod)).

I have a very vague idea of what Trilinos is doing. Could you tell why a
Trilinos script is building yade? Just curious.

Bruno

Revision history for this message
Kenneth Hoste (kenneth-hoste) said :
#8

>I have a very vague idea of what Trilinos is doing. Could you tell why a
> Trilinos script is building yade? Just curious.

Oh, sorry for the confusion, I was mixing up things, Trilinos has nothing to do with this (I'm also swearing on getting a Trilinos build to work in which I'm facing some problems similar as the ones I'm hitting with Yade, incl. CMake...).

To correct my statement: "that setting was inherited from a build script of an older Yade version"