optional compilation of LBM engine

Asked by Luc Sibille

Hi,
 A LBM engine (to compute interstitial fluid flow with the lattice Boltzmann method) was implemented in Yade some years ago, but have not been submitted to git so far. Now I want to submit this engine, and I want to make its compilation optionnal, with this option disable by default.

Consequently I added in CMakeLists.txt the following lines:

OPTION(ENABLE_LBMFLOW "Enable LBM engine (very experimental)" OFF)

and

IF(ENABLE_LBMFLOW)
   SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DLBM_ENGINE")
   SET(CONFIGURED_FEATS "${CONFIGURED_FEATS} LBMFLOW")
   MESSAGE("LBMFLOW is still experimental, building and running LBM engine are at your own risk!")
ELSE(ENABLE_LBMFLOW)
   SET(DISABLED_FEATS "${DISABLED_FEATS} LBMFLOW")
 ENDIF(ENABLE_LBMFLOW)

In addition all .ccp and .hpp files related to the LBM engine begin with:
#ifdef LBM_ENGINE
and finish with
#endif

When I choose the option:
cmake -DENABLE_LBMFLOW=ON
the message:
"LBMFLOW is still experimental, building and running LBM engine are at your own risk!"
is printed in the console, thus ENABLE_LBMFLOW is turned to ON as requested, but that's all and the compilation of the LBM engine is not performed. It is as if the results of the condition:
#ifdef LBM_ENGINE
is still false. Indeed, if I remove the condition #ifdef LBM_ENGINE, then the LBM engine is compiled.

I think I missed a point somewhere in the definition of the variable LBM_ENGINE, but which one? Have you got an idea?

Best,
Luc

Question information

Language:
English Edit question
Status:
Solved
For:
Yade Edit question
Assignee:
No assignee Edit question
Solved by:
Luc Sibille
Solved:
Last query:
Last reply:
Revision history for this message
Anton Gladky (gladky-anton) said :
#1

Try to use
ADD_DEFINITIONS("-DLBM_ENGINE")

instead

SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DLBM_ENGINE")

Show your CMakeCache.txt

Anton

2014-03-18 16:56 GMT+01:00 Luc Sibille <email address hidden>:
> New question #245682 on Yade:
> https://answers.launchpad.net/yade/+question/245682
>
> Hi,
> A LBM engine (to compute interstitial fluid flow with the lattice Boltzmann method) was implemented in Yade some years ago, but have not been submitted to git so far. Now I want to submit this engine, and I want to make its compilation optionnal, with this option disable by default.
>
> Consequently I added in CMakeLists.txt the following lines:
>
> OPTION(ENABLE_LBMFLOW "Enable LBM engine (very experimental)" OFF)
>
> and
>
> IF(ENABLE_LBMFLOW)
> SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DLBM_ENGINE")
> SET(CONFIGURED_FEATS "${CONFIGURED_FEATS} LBMFLOW")
> MESSAGE("LBMFLOW is still experimental, building and running LBM engine are at your own risk!")
> ELSE(ENABLE_LBMFLOW)
> SET(DISABLED_FEATS "${DISABLED_FEATS} LBMFLOW")
> ENDIF(ENABLE_LBMFLOW)
>
> In addition all .ccp and .hpp files related to the LBM engine begin with:
> #ifdef LBM_ENGINE
> and finish with
> #endif
>
> When I choose the option:
> cmake -DENABLE_LBMFLOW=ON
> the message:
> "LBMFLOW is still experimental, building and running LBM engine are at your own risk!"
> is printed in the console, thus ENABLE_LBMFLOW is turned to ON as requested, but that's all and the compilation of the LBM engine is not performed. It is as if the results of the condition:
> #ifdef LBM_ENGINE
> is still false. Indeed, if I remove the condition #ifdef LBM_ENGINE, then the LBM engine is compiled.
>
> I think I missed a point somewhere in the definition of the variable LBM_ENGINE, but which one? Have you got an idea?
>

Revision history for this message
Luc Sibille (luc-sibille) said :
#2

Using
ADD_DEFINITIONS("-DLBM_ENGINE")
did not change anything.

Now I have additionnal informations during the compilation, i.e. at make step (with the option -DCMAKE_VERBOSE_MAKEFILE=1 (by the way I don't now why but these additionnals informations are not displayed at each compilation...), and there is something strange. At make step there is:
-- Yade configured with following features: Eigen3 VTK OpenMP GTS GUI CGAL PFVflow GL2PS
-- Disabled features: Odeint LinSolv LBMFLOW
thus LBM engine is disable whereas at cmake step there is:
-- Yade configured with following features: Eigen3 VTK OpenMP GTS GUI CGAL PFVflow GL2PS LBMFLOW
-- Disabled features: Odeint LinSolv
and we expect the LBM engine to be enable.

Here are the two lines the CMakeCache.txt relative to the LBM engine:
//Enable LBM engine (very experimental)
ENABLE_LBMFLOW:BOOL=OFF
there is nothing else about LBM...

I tried also to define ENABLE_LBMFLOW=ON by default with:
OPTION(ENABLE_LBMFLOW "Enable LBM engine (very experimental)" ${DEFAULT})
as it is done for instance for the PFV engine, but there is still
ENABLE_LBMFLOW:BOOL=OFF in CMakeCache.txt

... oh, actually:
ENABLE_LBMFLOW:BOOL=OFF in CMakeCache.txt in the "build" directory
but
ENABLE_LBMFLOW:BOOL=ON in CMakeCache.txt in the "trunk" directory
thus, why CMakeCache.txt is not updated in the "build" directory? Should I rebuild the whole code as for a very new installation of Yade? How can I impose to rebuild the whole code as for a new installation?

Luc

Revision history for this message
Luc Sibille (luc-sibille) said :
#3

I tried:

make clean
make

to rebuild the whole code but apparently it did not updated CMakeCache.txt in the build directory.

Luc

Revision history for this message
Anton Gladky (gladky-anton) said :
#4

Please, commit your changes, I will try to fix it
just after that.

Anton

2014-03-18 19:01 GMT+01:00 Luc Sibille <email address hidden>:
> Question #245682 on Yade changed:
> https://answers.launchpad.net/yade/+question/245682
>
> Status: Answered => Open
>
> Luc Sibille is still having a problem:
> Using
> ADD_DEFINITIONS("-DLBM_ENGINE")
> did not change anything.
>
> Now I have additionnal informations during the compilation, i.e. at make step (with the option -DCMAKE_VERBOSE_MAKEFILE=1 (by the way I don't now why but these additionnals informations are not displayed at each compilation...), and there is something strange. At make step there is:
> -- Yade configured with following features: Eigen3 VTK OpenMP GTS GUI CGAL PFVflow GL2PS
> -- Disabled features: Odeint LinSolv LBMFLOW
> thus LBM engine is disable whereas at cmake step there is:
> -- Yade configured with following features: Eigen3 VTK OpenMP GTS GUI CGAL PFVflow GL2PS LBMFLOW
> -- Disabled features: Odeint LinSolv
> and we expect the LBM engine to be enable.
>
> Here are the two lines the CMakeCache.txt relative to the LBM engine:
> //Enable LBM engine (very experimental)
> ENABLE_LBMFLOW:BOOL=OFF
> there is nothing else about LBM...
>
> I tried also to define ENABLE_LBMFLOW=ON by default with:
> OPTION(ENABLE_LBMFLOW "Enable LBM engine (very experimental)" ${DEFAULT})
> as it is done for instance for the PFV engine, but there is still
> ENABLE_LBMFLOW:BOOL=OFF in CMakeCache.txt
>
> ... oh, actually:
> ENABLE_LBMFLOW:BOOL=OFF in CMakeCache.txt in the "build" directory
> but
> ENABLE_LBMFLOW:BOOL=ON in CMakeCache.txt in the "trunk" directory
> thus, why CMakeCache.txt is not updated in the "build" directory? Should I rebuild the whole code as for a very new installation of Yade? How can I impose to rebuild the whole code as for a new installation?
>
> Luc
>
> You received this question notification because you are a member of
> yade-users, which 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
Anton Gladky (gladky-anton) said :
#5

touch path/to/src/CmakelLst.txt

should force to rebuild the whole source tree.

Anton

2014-03-18 19:16 GMT+01:00 Luc Sibille <email address hidden>:
> Question #245682 on Yade changed:
> https://answers.launchpad.net/yade/+question/245682
>
> Luc Sibille posted a new comment:
> I tried:
>
> make clean
> make
>
> to rebuild the whole code but apparently it did not updated
> CMakeCache.txt in the build directory.
>
> Luc
>
> --
> You received this question notification because you are a member of
> yade-users, which 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
Luc Sibille (luc-sibille) said :
#6

touch path/to/src/CmakelLst.txt have no effect.
I removed /trunk/CMakeCache.txt (I imagine it was there because I made a mistake once by compiling Yade from the trunk dir. and not from the build dir. ?). Now it works fine, when I enable the option ENABLE_LBMFLOW at the cmake step, this option is on in /build/CMakeCache.txt.

Thanks for your help Anton, consequently I have just committed the LBM engine.

Luc

Revision history for this message
Anton Gladky (gladky-anton) said :
#7

Hi Luc,

glad, that you solved it. Some notes about your pull request.

1) Is it OK for you, if i put all LBM-stuff into the pkg/LBM? I think,
our pkg/common and pkg/dem are overloaded and from my point of
view it is better to do it.
2) Please, try to provide a couple of simple examples. Without them
any engine is useless.
3) The most important. You declare the license for your files GPL-3+,
but the rest of the code is licensed under GPL-2+. I would strongly escape
such license mixing. Please, try to talk to all contributors of this code
and relicense it under GPL-2+.

Thanks for contribution!

Anton

2014-03-20 19:01 GMT+01:00 Luc Sibille <email address hidden>:
> Question #245682 on Yade changed:
> https://answers.launchpad.net/yade/+question/245682
>
> Status: Answered => Solved
>
> Luc Sibille confirmed that the question is solved:
> touch path/to/src/CmakelLst.txt have no effect.
> I removed /trunk/CMakeCache.txt (I imagine it was there because I made a mistake once by compiling Yade from the trunk dir. and not from the build dir. ?). Now it works fine, when I enable the option ENABLE_LBMFLOW at the cmake step, this option is on in /build/CMakeCache.txt.
>
> Thanks for your help Anton, consequently I have just committed the LBM
> engine.
>
> Luc

Revision history for this message
Luc Sibille (luc-sibille) said :
#8

Hi Anton

1/ put all LBM-stuff into the pkg/LBM: if you think it is better there is no problem. It is just necessary to keep in mind that LBM is coupled with DEM, and I think that LBM computation cannot by run alone, it need at least the rigid walls defined in the DEM part to build the LBM grid (but it should works even without grain). It should require also a DEM time step.

2/ Yes I know that examples are essential, I plan to commit one concerning a buoyancy problem, but the script is quite old and not updated with respect to the current version of Yade. Thus I need to update it before committing it.
Actually I prefer to commit things incrementally, than waiting that all is perfectly ready and complete. I am afraid that this last option would never be reached, and then the code would be definitively lost. But you're right, the next step is to commit an example.

3/ I will ask to the contributors of the code concerning GPL-2+. Franck and Luc, maybe you are following this discussion, do not hesitate to react. Personnally I agree.

Thus, how do we proceed? You reject the pull request and I will make a new one following your recommendations(LBM directory + GPL-2+)? Or you accept it by changing the LBM directory (pkg/LBM) and I will bring afterwards the modifications (GPL-2+)?

Best,
Luc

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

Hi Luc,
> 1/ put all LBM-stuff into the pkg/LBM: if you think it is better there
> is no problem. It is just necessary to keep in mind that LBM is coupled
> with DEM, and I think that LBM computation cannot by run alone
Evrything in Yade is related to DEM. Putting things in different folders
is just for clarity, it does not mean it is not DEM-friendly.
I think I will also move PFV to a PFV folder, since the number of
associated files will soon increase.

Nice commit by the way. And yes, I think is best to commit incrementaly.
Note that you can also increment your branch for a while before doing a
big push to the main branch.

Bruno

Revision history for this message
Luc Sibille (luc-sibille) said :
#10

>Evrything in Yade is related to DEM. Putting things in different folders
>is just for clarity, it does not mean it is not DEM-friendly.
Ok, so we agree ;-)

>Nice commit by the way.
It is a work iniated by Luc Scholtès and then rewritten and largely developped by Franck Lominé. In my opinion it would be a pity to lose this work, that's why I want to commit it.

>Note that you can also increment your branch for a while before doing a
>big push to the main branch.
Yes, but some persons may use this code quite soon, thus I would prefer that we all use and modifiy the same code in the main branch. I imagine I could make other persons committing to my own branch, but I am not sufficiently friendly with all these stuffs to choose this option...

Luc

Revision history for this message
Anton Gladky (gladky-anton) said :
#11

Hi Luc,

2014-03-21 18:41 GMT+01:00 Luc Sibille <email address hidden>:
> 1/ put all LBM-stuff into the pkg/LBM: if you think it is better there
> is no problem. It is just necessary to keep in mind that LBM is coupled
> with DEM, and I think that LBM computation cannot by run alone, it need
> at least the rigid walls defined in the DEM part to build the LBM grid
> (but it should works even without grain). It should require also a DEM
> time step.

I agree with Bruno. And it is just putting files in a separate folder to escape
overcrowding, there is nothing about running LBM-code alone.

> 2/ Yes I know that examples are essential, I plan to commit one concerning a buoyancy problem, but the script is quite old and not updated with respect to the current version of Yade. Thus I need to update it before committing it.
> Actually I prefer to commit things incrementally, than waiting that all is perfectly ready and complete. I am afraid that this last option would never be reached, and then the code would be definitively lost. But you're right, the next step is to commit an example.

Yes, incremental commits are always better than the large (sometimes
unreadable) patch.

> 3/ I will ask to the contributors of the code concerning GPL-2+. Franck
> and Luc, maybe you are following this discussion, do not hesitate to
> react. Personnally I agree.

That would be fine.

> Thus, how do we proceed? You reject the pull request and I will make a
> new one following your recommendations(LBM directory + GPL-2+)? Or you
> accept it by changing the LBM directory (pkg/LBM) and I will bring
> afterwards the modifications (GPL-2+)?

As you want. We can do both.

Best regards

Anton

Revision history for this message
flomine (flomine) said :
#12

Hi all,

Luc, I am agree to relicense the code under GPL-2+.
Thank you for your work.

Best regards

Franck

Revision history for this message
Luc Sibille (luc-sibille) said :
#13

> Luc, I am agree to relicense the code under GPL-2+.
> Thank you for your work.
>
Thank you Franck!

Anton, consequently, I will close my pull resquest and make a new one in
a LBM directory and with GPL-2+ license.

Best,
Luc

Revision history for this message
Luc Sibille (luc-sibille) said :
#14

Hi Anton,
I made a new pull request concerning the lbm engine last week. Do you think it is now satisfaying?
For the future I could make the "push" directly on the trunk instead of my own fork, it would avoid you some work (but it will be more dangerous for me and the trunk!) ;-)
What do you think?
Best,
Luc

Revision history for this message
Anton Gladky (gladky-anton) said :
#15

Hi Luc,

I merged your branch! Please, do not forget to add a simple
example, which shows, how to use this interface.

Thanks

Anton

2014-04-09 21:16 GMT+02:00 Luc Sibille <<email address hidden>
>:

> Question #245682 on Yade changed:
> https://answers.launchpad.net/yade/+question/245682
>
> Luc Sibille posted a new comment:
> Hi Anton,
> I made a new pull request concerning the lbm engine last week. Do you
> think it is now satisfaying?
> For the future I could make the "push" directly on the trunk instead of my
> own fork, it would avoid you some work (but it will be more dangerous for
> me and the trunk!) ;-)
> What do you think?
> Best,
> Luc
>
> --
> You received this question notification because you are a member of
> yade-users, which 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
Luc Sibille (luc-sibille) said :
#16

Thank you for your help Anton!
I am working on an example concerning the buoyancy and I will submit it
soon.
Best,
Luc

Le 10/04/2014 07:41, Anton Gladky a écrit :
> Your question #245682 on Yade changed:
> https://answers.launchpad.net/yade/+question/245682
>
> Anton Gladky posted a new comment:
> Hi Luc,
>
> I merged your branch! Please, do not forget to add a simple
> example, which shows, how to use this interface.
>
> Thanks
>
>
> Anton
>
>
> 2014-04-09 21:16 GMT+02:00 Luc Sibille <<email address hidden>
>> :
>> Question #245682 on Yade changed:
>> https://answers.launchpad.net/yade/+question/245682
>>
>> Luc Sibille posted a new comment:
>> Hi Anton,
>> I made a new pull request concerning the lbm engine last week. Do you
>> think it is now satisfaying?
>> For the future I could make the "push" directly on the trunk instead of my
>> own fork, it would avoid you some work (but it will be more dangerous for
>> me and the trunk!) ;-)
>> What do you think?
>> Best,
>> Luc
>>
>> --
>> You received this question notification because you are a member of
>> yade-users, which 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
>>

--
Luc Sibille
Université Joseph Fourier / IUT1 de Grenoble
Laboratoire 3SR UMR CNRS

Tel lab.: +33 (0)4 76 82 63 48
Tel IUT: +33 (0)4 76 82 53 36