optional compilation of LBM engine
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(
and
IF(ENABLE_LBMFLOW)
SET(
SET(
MESSAGE("LBMFLOW is still experimental, building and running LBM engine are at your own risk!")
ELSE(ENABLE_
SET(
ENDIF(
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
|
#1 |
Try to use
ADD_DEFINITIONS
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:/
>
> 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(
>
> and
>
> IF(ENABLE_LBMFLOW)
> SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DLBM_ENGINE")
> SET(CONFIGURED_
> MESSAGE("LBMFLOW is still experimental, building and running LBM engine are at your own risk!")
> ELSE(ENABLE_
> SET(DISABLED_FEATS "${DISABLED_FEATS} LBMFLOW")
> ENDIF(ENABLE_
>
> 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
|
#2 |
Using
ADD_DEFINITIONS
did not change anything.
Now I have additionnal informations during the compilation, i.e. at make step (with the option -DCMAKE_
-- 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_
there is nothing else about LBM...
I tried also to define ENABLE_LBMFLOW=ON by default with:
OPTION(
as it is done for instance for the PFV engine, but there is still
ENABLE_
... oh, actually:
ENABLE_
but
ENABLE_
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
|
#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
|
#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:/
>
> Status: Answered => Open
>
> Luc Sibille is still having a problem:
> Using
> ADD_DEFINITIONS
> did not change anything.
>
> Now I have additionnal informations during the compilation, i.e. at make step (with the option -DCMAKE_
> -- 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_
> there is nothing else about LBM...
>
> I tried also to define ENABLE_LBMFLOW=ON by default with:
> OPTION(
> as it is done for instance for the PFV engine, but there is still
> ENABLE_
>
> ... oh, actually:
> ENABLE_
> but
> ENABLE_
> 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:/
> Post to : <email address hidden>
> Unsubscribe : https:/
> More help : https:/
Revision history for this message
|
#5 |
touch path/to/
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:/
>
> 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:/
> Post to : <email address hidden>
> Unsubscribe : https:/
> More help : https:/
Revision history for this message
|
#6 |
touch path/to/
I removed /trunk/
Thanks for your help Anton, consequently I have just committed the LBM engine.
Luc
Revision history for this message
|
#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:/
>
> Status: Answered => Solved
>
> Luc Sibille confirmed that the question is solved:
> touch path/to/
> I removed /trunk/
>
> Thanks for your help Anton, consequently I have just committed the LBM
> engine.
>
> Luc
Revision history for this message
|
#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
|
#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
|
#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
|
#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
|
#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
|
#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
|
#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
|
#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:/
>
> 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:/
> Post to : <email address hidden>
> Unsubscribe : https:/
> More help : https:/
>
Revision history for this message
|
#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:/
>
> 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:/
>>
>> 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:/
>> Post to : <email address hidden>
>> Unsubscribe : https:/
>> More help : https:/
>>
--
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