[marhamat]

Great.
Thanks alot,
Marhamt

[meisam_khan]

hi.marhamat
i have yhis error too...
how you can solve this error:::::
[1] --> FOAM FATAL IO ERROR:
[1] keyword velocityLaplacianCoeffs is undefined in dictionary "/home/meisam/OpenFOAM/meisam-2.2.0/run/gearMain/gearMove/processor1/constant/dynamicMeshDict"
[1] file: /home/meisam/OpenFOAM/meisam-2.2.0/run/gearMain/gearMove/processor1/constant/dynamicMeshDict from line 0 to line 0.
[1]
[1] From function dictionary::subDict(const word& keyword) const
[1] in file db/dictionary/dictionary.C at line 608.

please help me immediately...
best regards

[wyldckat]

Greetings Meisam,

I can't find any indication that "velocityLaplacianCoeffs" exists.

But what I can tell you from the case "movingCone" that was discussed in this thread, uses the following "constant/dynamicMeshDict" content:

FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    location    "constant";
    object      dynamicMeshDict;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dynamicFvMesh   dynamicMotionSolverFvMesh;

motionSolverLibs ( "libfvMotionSolvers.so" );

solver          velocityComponentLaplacian;

velocityComponentLaplacianCoeffs
{
    component       x;
    diffusivity     directional ( 1 200 0 );
}

As you can see, "velocityComponentLaplacianCoeffs" exists.

Best regards,
Bruno

[desmoge]

Good evening guys.

I am currently working on the library developed by E.Helgason at Chalmers in 2009 (the one Xinguang Cui has uploaded in post #6) and I've encountered the exact same problem shown in this thread. The library itself works well until one wants to run it on parallel. In fact, the utility 'decomposePar' runs fine only the very first time, while it fails the following decomposition procedure for the same reason highlighted at the beginning of this thread.

I have personally modified it like has been suggested by B.Santos but I've got no improvements. Later on, I've used the library fixed by Bruno himself and I have experienced the same problem. Here below the message which appears into the log.decomposePar file:

--> FOAM FATAL IO ERROR:
size 0 is not equal to the given value of 121

file: /home/gennaro/Desktop/DynMesh/Santos_PatchDeform/movingCyl1_22x_v3/0.08/pointMotionU::boundaryField::cubeY from line 47 to line 57.

From function Field<Type>::Field(const word& keyword, const dictionary&, const label)
in file /home/gennaro/OpenFOAM/OpenFOAM-2.1.1/src/OpenFOAM/lnInclude/Field.C at line 236.

Since this thread stops here, I assume that the edits actually have worked for somebody.
I'm using OF.2.1.1, is that an issue? I will appreciate any help or hint from people who has worked this thing out.

Best regards

[wyldckat]

Greetings desmoge,

My guess is that you did not restart the case from time "0".

If I remember correctly, the problem for the parallel case was that the original boundary condition class was not able to do a proper parameter writing of the parameters it needs. Consequently, it goes bonkers when it doesn't see the parameters it didn't write in the first place .

You can confirm this hypothesis, by comparing the settings you defined for the patch+field in the time snapshot "0", with the one at "0.08". If I'm not mistaken, you will see in "0/pointMotionU" this:

    cubeY
    {
        type            libMyPolynomVelocity;
        origin          ( 0.75 0.45 0.3 );
        value           uniform ( 0 0 0 );
        RR              0.9;
        freq            25;
        A0              1;
        xAxis           ( 1 0 0 );
        yAxis           ( 0 0 -1 );
    }

But in "0.08/pointMotionU", you'll see something like this:

    cubeY
    {
        type            libMyPolynomVelocity;
        value           121 ( ... );
    }

The ellipsis "..." are only indicating that a big list of values will be present there. But all other parameters are not present. And that is why it has problems for "0.08".

Best regards,
Bruno

[desmoge]

First of all I thank you Bruno for replying to me.

Yes, the problem with the library is exactly the one you have described. In time folders different than 0, it does not write back the parameters it needs to restart the simulation.

The way I have overcome this issue is to decompose the domain just once at the very beginning. Later on, I just reconstruct the domain (without deleting the processor folders) and restart the simulation from the latest time-step.

Before encountering problems with this library, I used to delete the processor folders every time after the domain reconstruction and decompose it again at every simulation restart.

Best regards

[wyldckat]

Originally Posted by desmoge

Yes, the problem with the library is exactly the one you have described. In time folders different than 0, it does not write back the parameters it needs to restart the simulation.

Quick question: Does this still occur with the last version of the library that I shared?

[desmoge]

Yes, that happens to me when I use yours.
So what I did was just to make the edits you have suggested on the original one:

1) I added the "processor" block to the file "pointMotionU"
2) "preservePatches" into decomposeParDict, so that the patches that use "libMyPolynomVelocity" will not be broken between processors.

and then run it in the way I've described above.

[wyldckat]

That's very, very strange!
Are you certain that you ran:

wmake libso

inside the folder of the modified source code for "libMyPolynomVelocity"? More specifically, after every time any change was made to said library?

In addition, are you certain that only 1 version of that library exists?
To check this, run these commands:

ls -l $FOAM_USER_LIBBIN/*Polynom*
ls -l $FOAM_LIBBIN/*Polynom*

Is only one path shown or two paths are shown for two identical library names?