[baezacaljo]

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

[LongGe]

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

void Foam::solvers::incompressibleVoF::thermophysicalPredictor()
{}

OpenFOAM-11/applications/solvers/foamRun/foamRun.C

        // PIMPLE corrector loop
        while (pimple.loop())
        {
            solver.moveMesh();
            solver.fvModels().correct();
            solver.prePredictor();
            solver.momentumPredictor();
            solver.thermophysicalPredictor();
            solver.pressureCorrector();
            solver.postCorrector();
        }

[baezacaljo]

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

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

and the file incompressibleVoF.H has

// 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

[LongGe]

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.

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.

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.

[baezacaljo]

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

[LongGe]

Hello

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

For example:

class incompressibleVoFTemp
:
    public twoPhaseVoFSolver
{

...
...

    //- Runtime type information
    TypeName("incompressibleVoFTemp");

Other changes will need to be made to ctor and dtor as well....

[K.C.]

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

foamRun -solver {nameOfMyOwnSolver}

while the .so was declared inside of my controlDict with

libs("{pathToMyLibrary.so}");

and I also tried

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

and my last attempt was to extend the searchPath for libraries with

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.

[Danubi]

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

[Large Epic Simulations]

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?

[Danubi]

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".

[Large Epic Simulations]

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:

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.

[Danubi]

Hi LES,
For the code to recognize new modules (libraries), you must include them in controlDict, under the libs subdict:

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

[Large Epic Simulations]

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!

[Danubi]

Sometimes elegance is expensive!
Have a great day

[Large Epic Simulations]

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