MULESImplicit fvSolution syntax in OF-1.6 (or 1.6.x)
 

Hi,
Has anyone managed to use MULESImplicit (like a modified interFoam, or similar) in OF-1.6? I had it working in the previous version, and now it gives me errors like solver not found, etc. A sample fvSolution file that works on 1.6 for MULESImplicit would be great.
Thanks,
Sean McIntyre

Hi
Even I am facing the same problem?
Have you found the solution ...I m sorry my c++ knowledge is limited...
I understood there was change by looking into MULES template file but could not understand how to update the fvSolution files
Thanks
Sachin

MULESImplicit
 

Hi all,

Could you find out how the setting of Alpha1 and MULESImplicit as solver should be, in the fvSolution?

Please keep here posted from your findings,

Best regards,
Hamed

One step forward, perhaps?
 

Using the following syntax, the solver does no longer complain on MULESImplicit missing:

alpha1
{
MULESImplicit
{
maxIter 1000;
nLimiterIter 10;
maxUnboundedness 1;
CoCoeff 0.2;
solver PBiCG{ preconditioner DILU; tolerance 1e-10; relTol 0;};
};
}

Instead I get:
keyword solver is undefined in dictionary "/home/ribe/OpenFOAM/ribe-1.6/run/naca15_test_case/system/fvSolution::solver"

Removing the keyword solver from within the MULESImplicit gives:
keyword solver is undefined in dictionary "/home/ribe/OpenFOAM/ribe-1.6/run/naca15_test_case/system/fvSolution::MULESImplicit"

Other tests I've tried yields different error messages.

A possible work around is to change to MULES::explicit in alphaEqn.H and then you don't need a specification for alpha1 in fvSolution. I don't know how this affects the stability of the solver though.

/Rickard

That sounds about right. I was getting that same thing.

Till now, no report about successfully using interPhaseChangeFoam of OF-1.6 occurs. Maybe there is a bug at this point of OF-1.6, but at this time I don't know what and where it is.

Best regards,
Chiven

The only real difference I could see is the occurrence of three nested dictionaries in 1.6, instead of only two in 1.5.x, but I can't directly see why this should be a problem.

Hello!
I have the same problem and the same error messages.
The difference from version 5 to 6 in MULESTemplates.C is the definition of
MULEScontrols:

const dictionary& MULEScontrols =
mesh.solverDict(psi.name()).subDict("MULESImplicit");

instead of

dictionary MULESSolver(mesh.solverDict(psi.name()));
const dictionary& MULEScontrols =MULESSolver.subDict("MULESImplicit");

But it does exactly the same thing as before: it reads the dictionnary "MULESImplicit
and I don't see why the following lines yield to an error message in OpenFOAM-1.6!

solve
(
psiConvectionDiffusion + fvc::div(lambda*phiCorr),
MULEScontrols.lookup("solver")
);

It may be a bug?

Aurelia

Hi, everybody, Henry has revised the MULES, the new MULESTemplates.C file and the updated dambreak case for OF-1.6 are attached.

enjoy,
Chiven

Kunz's model PK dambreak
 

Hi Chiven, I can not understand why Kunz's mode can been used to solve the "dambreak" problem....

Are you joking?

Hi, Sandy, I don't consider the physical means, only give a setting sample for running the codes of the solver.

Best regards,
Chiven

Where should i change the mulestemplates.c to fix this error:

Now, I am using OF 1.6.x. This bug has been fixed up. You can revise the file and recompile OF 1.6

What? I am very new to this, i dont quite follow, but should i just change the new mulestemplates.c for the old ones in the finitevolume folders, and then source the .bashrc file? Would that be enough? I didnt compile OF to begin with, how would i go about doing that?

Really, thank you!

If you could not compile OF 1.6, you also can not change the Mulsetemperature.C file. You have to install the OF 1.6.x as like as me, if you really need to use the implicit MUSLE to solve.

Yes, now i understand, i had panicked (i barely got OF-1.6 to work yesterday). Now im compiling OF-1.6.x, lets hope it works. Thank you!