CFD Online Discussion Forums - Error: undefined in dictionary ...fvsolution.solvers

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)

- OpenFOAM Programming & Development (https://www.cfd-online.com/Forums/openfoam-programming-development/)

- - Error: undefined in dictionary ...fvsolution.solvers (https://www.cfd-online.com/Forums/openfoam-programming-development/188726-error-undefined-dictionary-fvsolution-solvers.html)

akesm

June 5, 2017 22:24

Error: undefined in dictionary ...fvsolution.solvers

Hello

I have coded a new solver based on interFOAM, the new solver gets wmake(ed) fine, no errors. When I want to run a case with the solver I get the error as

--> FOAM FATAL IO ERROR:
keyword H is undefined in dictionary "/home/Dropbox/OpenFoam/system/fvSolution.solvers"

file: /home/Dropbox/OpenFoam/system/fvSolution.solvers from line 22 to line 63.

From function const Foam::dictionary& Foam::dictionary::subDict(const Foam::word&) const
in file db/dictionary/dictionary.C at line 642.

FOAM exiting

I am confused since "H" should not appear in my "fvsolution" file, it is just a parameter coded in my solver, so I believe there should not be a requirement for a keyword as H.

Can you give me a hint on how to find the problem and resolve the issue?

If you want I can even send you the new solver that I have written for your review.

Thanks

akesm

June 6, 2017 13:58

Actually now I just define H in the "fvsolutions" similar to say "U" as

Code:

H

    {

        solver          smoothSolver;

        smoother        symGaussSeidel;

        tolerance       1e-06;

        relTol          0;

    }

And my modified solver works fine.

My surprise is that, why there should be the need for defining H, because H in my solver is not solved actually and it is defined, it is basically a Heaviside function, so no need for specifying solver.

Probably I have messed up somewhere and that's why OF considers H as a parameter that needs to be solved, but I cannot find out where I have made this mistake.

Any hints helping to find this bug would be appreciated.

Thanks :)

Lookid

June 6, 2017 16:28

Hi,

Far from being an expert :D, did you set up H in createFields ? How is it coded in the solver.C file ?

akesm

June 6, 2017 21:07

in createfields.H it is as

Code:

Info<< "Reading field H\n" << endl;

    volScalarField H

    (

        IOobject

        (

            "H",

            runTime.timeName(),

            mesh,

            IOobject::NO_READ,

            IOobject::AUTO_WRITE

        ),

        mesh,

        dimensionedScalar("H",dimless, 0.0)

    );

and in the solver.C it is as

Code:

// update Heaviside function

   forAll(mesh.cells(),celli)

   {

      if(psi[celli] < -epsilon.value())

         H[celli] = double(0);

      else if(epsilon.value() < psi[celli])

         H [celli] = double(1);

      else

         H[celli] = double(0.75);

   };

So not a magic behind, I don't know why it needs sth to be specified for it in the solver!

alexeym

June 7, 2017 02:37

Hi all,

@akesm

And these are the only additions you have made? Is there a possibility that as a result of copy-paste you have another field named H in registry for which you actually solve linear equation? (variable name for the field in your solver could be named differently).

akesm

June 7, 2017 16:54

Thanks for your reply.

But my new solver is based on interFoam, which does not have any field named as H, so I barely think that my introduced parameter H is being mistaken with an already existing field named as H.

If it helps I can post, or upload either my solver or the changes I have made!

alexeym

June 7, 2017 17:10

Well, it YOU, who has strange behaviour of new solver. So it is up to YOU to decide either you are happy with small addition to fvSolution file, or you would like to resolve this problem. Either the thread can be closed, or you post a link to your repository with code, so people can take a look and figure out why OpenFOAM(TM) needs addition to solvers dictionary in fvSolution file (and maybe propose solution).

akesm

June 7, 2017 17:25

Now when I am looking carefully, at a point of my code I give H to explicit solve in the way below

Code:

MULES::explicitSolve(H, phi, phiH, 1, 0);

I think this is the reason, that like alpha in the interFoam solver for H should be specified as well.

All times are GMT -4. The time now is 07:22.