CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM

How to add equations to modular solver in openFoam11

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   September 11, 2023, 20:09
Default How to add equations to modular solver in openFoam11
  #1
New Member
 
Alberto Campuzano
Join Date: Mar 2021
Posts: 14
Rep Power: 5
baezacaljo is on a distinguished road
Dear All


I am looking for help, how to add temperature equation or any other equation to InterFoam solver?, i noticed, that now everything is called modular solver and even the name changed to incompressibleVoF.


i know everything is with classes, however, openFoam is improving faster and now i am a bit lost.


Finally the version is OpenFoam11



thanks in advance

Last edited by baezacaljo; September 11, 2023 at 20:11. Reason: typos
baezacaljo is offline   Reply With Quote

Old   September 12, 2023, 01:09
Default
  #2
Member
 
Tatsuya Shimizu
Join Date: Jul 2012
Posts: 42
Rep Power: 14
LongGe is on a distinguished road
Hello baezacaljo

I would add to the class method "thermophysicalPredictor" in "incompressibleVoF.C".
The solver "foamRun" always calls this class method.


OpenFOAM-11/applications/modules/incompressibleVoF
Code:
void Foam::solvers::incompressibleVoF::thermophysicalPredictor()
{}

OpenFOAM-11/applications/solvers/foamRun/foamRun.C
Code:
        // PIMPLE corrector loop
        while (pimple.loop())
        {
            solver.moveMesh();
            solver.fvModels().correct();
            solver.prePredictor();
            solver.momentumPredictor();
            solver.thermophysicalPredictor();
            solver.pressureCorrector();
            solver.postCorrector();
        }
__________________
Our Work: https://www.idaj.co.jp/product/ennovacfd/openfoam_gui/
Powered by Ennova : https://ennova-cfd.com/
Ennova's Channel Partners : http://www.wolfdynamics.com/
LongGe is offline   Reply With Quote

Old   September 12, 2023, 06:41
Default
  #3
New Member
 
Alberto Campuzano
Join Date: Mar 2021
Posts: 14
Rep Power: 5
baezacaljo is on a distinguished road
Thank you for your help LongGe

Now I assume I have to copy both folder the one called incompressibleVoF and compile it. And the other other one that contains the solver foamRun.C and compile it, right?

Finally in the controlDict file in solver I have to write myFoamRun, right?


By the way, i was reading the code carefully and the fie incompressibleVoF.C already has


Quote:
void Foam::solvers::incompressibleVoF::thermophysicalPr edictor() {}

and the file incompressibleVoF.H has



Quote:
// Member Functions //- Called at the start of the PIMPLE loop virtual void prePredictor(); //- Construct and solve the energy equation, // convert to temperature // and update thermophysical and transport properties virtual void thermophysicalPredictor();

Hence, i am not getting the code.


is the incompressibleVoF.C and foamRun considering the temperature already?


Best regards

Last edited by baezacaljo; September 12, 2023 at 10:38. Reason: lack of information
baezacaljo is offline   Reply With Quote

Old   September 12, 2023, 19:34
Default
  #4
Member
 
Tatsuya Shimizu
Join Date: Jul 2012
Posts: 42
Rep Power: 14
LongGe is on a distinguished road
Hello

Since "foamRun" is simply a client using the "solver" class, you do not need to make any changes. All you have to do is copy "incompressibleVoF" and create your "yourincompressibleVoF". The controlDict is as follows.

Code:
application     foamRun;
solver          yourincompressibleVoF
foamRun" always calls the class method "thermophysicalPredictor()". This is as I have shown before. The following is the inheritance relation of the "incompressibleVoF" class. The "thermophysicalPredictor" is declared as a pure virtual function in the "fluidSolver" class.

Code:
incompressibleVoF->twoPhaseVoFSolver->twoPhaseSolver->VoFSolver->fluidSolver

virtual void thermophysicalPredictor() = 0;
The class "incompressibleVoF" must implement "thermophysicalPredictor", but "incompressibleVoF" does not solve the temperature, so its implementation is empty. And you will be the one to specifically do this implementation.
__________________
Our Work: https://www.idaj.co.jp/product/ennovacfd/openfoam_gui/
Powered by Ennova : https://ennova-cfd.com/
Ennova's Channel Partners : http://www.wolfdynamics.com/
LongGe is offline   Reply With Quote

Old   September 13, 2023, 20:33
Default
  #5
New Member
 
Alberto Campuzano
Join Date: Mar 2021
Posts: 14
Rep Power: 5
baezacaljo is on a distinguished road
Thank you LongGe


So rry for the late reply i was testing and writing the code, look this is what i achieved so far (see attached files), however, in the case of the Make folder and the other two folder, do i have to modify them and then COMPILE THEM? or what to do?


i only modify the folder name from incompressibleVoF to incompressibleVoFTemp and the files stick with the same name incompressibleVoF.C and incompressibleVoF.H but with some modifications.


Thanks in advance
Attached Files
File Type: c incompressibleVoF.C (5.7 KB, 12 views)
File Type: h incompressibleVoF.H (6.0 KB, 6 views)
baezacaljo is offline   Reply With Quote

Old   September 13, 2023, 21:13
Default
  #6
Member
 
Tatsuya Shimizu
Join Date: Jul 2012
Posts: 42
Rep Power: 14
LongGe is on a distinguished road
Hello

You will need to create a new class. I don't think you can just copy it.

For example:

Code:
class incompressibleVoFTemp
:
    public twoPhaseVoFSolver
{

...
...

    //- Runtime type information
    TypeName("incompressibleVoFTemp");
Other changes will need to be made to ctor and dtor as well....
__________________
Our Work: https://www.idaj.co.jp/product/ennovacfd/openfoam_gui/
Powered by Ennova : https://ennova-cfd.com/
Ennova's Channel Partners : http://www.wolfdynamics.com/
LongGe is offline   Reply With Quote

Old   May 3, 2024, 10:42
Default
  #7
Member
 
Join Date: Mar 2015
Posts: 36
Rep Power: 11
K.C. is on a distinguished road
I found this thread via Google and have to admit, that I am facing the same problem.


I copied an existing solver module, modified it and then compiled it into an shared library with .so extension via "wclean" and "wmake libso".
Compilation worked fine, but my new solver class is not available to foamRun


I tried
Code:
foamRun -solver {nameOfMyOwnSolver}
while the .so was declared inside of my controlDict with
Code:
libs("{pathToMyLibrary.so}");


and I also tried

Code:
foamRun -libs '("{pathToMyLibrary.so}")' -solver {nameOfMyOwnSolver}

and my last attempt was to extend the searchPath for libraries with
Code:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/{absolutePathToMyLibraryFolder}

In all ways foamRun complains with "solvers table is empty"

So how can I declare to foamRun to use my new created solver module?
The




Kind regards,
K.C.
K.C. is offline   Reply With Quote

Old   July 19, 2024, 01:18
Default
  #8
New Member
 
Dan
Join Date: Nov 2013
Posts: 27
Rep Power: 13
Danubi is on a distinguished road
Hi KC,
I am digging to openfoam modular solvers and found this post.
I was trying to compile my new module, which was basically the incompressibleFluid module changing the name to "testIncompressibleFluid" and trying to include it into the multiRegion case I was testing.
When I compiled it I forgot to modify the name of the class that I was compiling and I was getting an error saying "unknown solver type".
I fixed it by changing the name of the class (that should be the name of the solver in controlDict).
I had to include the libs{"testIncompressibleFluid.so"} in controlDict too.
I didn't need to change the PATH or anything like this.
Hope this helps,
Regards
Danubi is offline   Reply With Quote

Old   November 15, 2024, 05:51
Default Modular solver class
  #9
Member
 
Join Date: Jun 2017
Posts: 43
Rep Power: 9
Large Epic Simulations is on a distinguished road
Hello,


I'm trying my self to develop a new modular solver, so I started from an existing one and managed to compile it and make it run.


Now I would like to add some new solver member functions, and, in order to include them in the solving procedure I had to write a slightly modified foamRun that would include these functions.


Unfortunately the compiler does not recognize them, complaining about the non existence of these class new members.


I made sure that the new library solver is linked and files included.

What am I missing?
Large Epic Simulations is offline   Reply With Quote

Old   November 15, 2024, 09:40
Default
  #10
New Member
 
Dan
Join Date: Nov 2013
Posts: 27
Rep Power: 13
Danubi is on a distinguished road
Hi LES,
I am not an expert in C++, but I think I can provide some light on your problem.
'foamRun' calls the class 'solver', in '$FOAM_SRC/finiteVolume/solver/solver.H', that has several virtual functions, and is a base class for whatever modular solver you are using, such as "fluid", or "XiFluid", or whatever derived module you created yourself.
If I understand properly, the "solver" variable is a reference to a pointer to a "solver class" object, that is the module that you type in system/controlDict, in an entry that has the name "solver"... All very clear
Now, the reason for which your new function won't be working can be perhaps because of the way you are calling it. I think it would be helpful if you can provide more details of the code structure and also the error messages you find.
One thing that I found in this new "modular" approach is that it is more difficult to figure out what are the compilation problems. Some times the compilation errors are not very informative, as they were when I was compiling "solvers" directly, instead of this new "modules".
Danubi is offline   Reply With Quote

Old   November 18, 2024, 12:18
Default
  #11
Member
 
Join Date: Jun 2017
Posts: 43
Rep Power: 9
Large Epic Simulations is on a distinguished road
Hi Danubi, thanks for your nice answer.


I think that the problem is related to the fact that the declaration of the new method is not present in solver.H


indeed I was getting something like:


Code:
error: ‘class Foam::solver’ has no member named ‘myNewFunction’
  127 |             solver.myNewFunction();
So, I tried to declare it in the solver.H and apparently it works.


Now I said my self, that I don't necessarily want to modify and recompile the source code each time I want to implement something new. Therefore I'm creating a derivation of the solver.H which I compile in $FOAM_USER_LIBBIN and use in my custom foamRun application.


Unfortunately I'm getting the same error as K.C. saying that "mySolver tables is empty". As always, everything is properly included in the Make/options and Make/files to include and link what it is required.
Large Epic Simulations is offline   Reply With Quote

Old   November 18, 2024, 14:26
Default
  #12
New Member
 
Dan
Join Date: Nov 2013
Posts: 27
Rep Power: 13
Danubi is on a distinguished road
Hi LES,
For the code to recognize new modules (libraries), you must include them in controlDict, under the libs subdict:
HTML Code:
application     foamRun;

libs (
        "libmyIncompressibleVoF.so"
    );

solver          myIncompressibleVoF;

startFrom       latestTime;
I see a problem with you approach. If you take a look at the code, or even better, at the graph on modular solvers in their website: https://cfd.direct/openfoam/free-sof...dular-solvers/
you will see the dependencies. So, for example, in the case of my example, I have 'myIncompressibleVoF', that I declared as a derived class from incompressibleVoF. This one is derived from twoPhaseVoFSolver, which is derived from twoPhaseSolver, which is derived from VoFSolver, which is derived from fluidSolver that is, finally derived from "solver'.
The best approach for modifying modules, in the current structure, and the way I see it, is by creating derived classes from the bottom of the struture, as I did, deriving my new module from incompressibleVoF.
In this way, you inherit the whole structure, and if you don't like one method in particular from an upper class, you can always overwrite it.

At the same time, if you want to change the general PIMPLE algorithm described in foamRun, you could always generate a new myFoamRun, and use your new algorithm with the existing, or with your customized modules.
The foamRun algorithm is very generic, and encapsulates the general step an algorithm should have to be resolved, defining them as "preSolve", "postSolve", "momentumPredictor", etc, that should give enough spots for us to implement our equations and solutions.
For example, I modified myself the foamMultiRun algorithm because I wanted to iterated several times between different regions. The consequence is that I have to call this new "myFoamMultiRun", instead of the original "foamMultiRun", but the modules that the new solver is calling are the same.

This is why I would ask myself if you really really need to modify the class "solver". In my opinion (again, I am not a C++ expert), you would have to construct again the whole structure of classes that depend on each other to refer to your new "mySolver". I believe that it is a pretty big amount of work, and I would think first if you really need it, and instead, if you could make such new feature simply modifying either your customized module, or finally the solver "foamRun" itself.
Hope this helps,
Regards
Danubi is offline   Reply With Quote

Old   November 18, 2024, 15:51
Default
  #13
Member
 
Join Date: Jun 2017
Posts: 43
Rep Power: 9
Large Epic Simulations is on a distinguished road
Hi Danubi,

I tried including the library in the controlDict file too, and having both mySolver linked and compiled with myFoamRun. It appears that my custom solver.H does not have what it takes.

I actually share pretty much your approach based on inheriting the class at the very bottom of the hierarchy and work starting from that, still I do not understand why solver.myFunction() is not recognized by myFoamRun, while it works when I directly touch the original solver.H

I am really trying to do like that for the sake of elegance, although I do know that the simplest way would be to modify the already existing methods (such as preSolve() and postSolve()) to get what I want (which is basically some fields modification and few MPI operations).

Thank you for your answers!
Large Epic Simulations is offline   Reply With Quote

Old   November 18, 2024, 15:59
Default
  #14
New Member
 
Dan
Join Date: Nov 2013
Posts: 27
Rep Power: 13
Danubi is on a distinguished road
Sometimes elegance is expensive!
Have a great day
Danubi is offline   Reply With Quote

Old   November 19, 2024, 06:53
Default
  #15
Member
 
Join Date: Jun 2017
Posts: 43
Rep Power: 9
Large Epic Simulations is on a distinguished road
This morning I started over and I managed to make the new member function work!


The problem was that the new mySolver module I was creating was starting from the isothermalFluid one, while the one that works comes from the fluid one.


Elegance was not that expensive after all
Large Epic Simulations is offline   Reply With Quote

Reply

Tags
incompressiblevof, interfoam, modular solver, openfoam 11

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Add mesh refinement to solidDisplacementFoam solver j-avdeev OpenFOAM Programming & Development 0 May 10, 2022 13:39
Error SIGSEGV using VOF and UDF JERC_UTFSM Fluent UDF and Scheme Programming 14 November 8, 2021 00:17
Add a pollutant in simpleFoam solver Gohu8 OpenFOAM Running, Solving & CFD 2 July 19, 2017 04:16
How to add temperature to cavitatingFoam solver chodki-c OpenFOAM 9 September 30, 2010 12:21
Navier-stokes equations and iterative solver?? wuliang Main CFD Forum 2 January 13, 2003 23:28


All times are GMT -4. The time now is 03:11.