[boffin5]

This is a follow-up to my post regarding the method to get rid of edges around the domain. I was charged up with finding a way to do it, but my balloon deflated when I tried to run the case.


In paraView, the mesh shows up, but none of the flow parameters such as p and U. The pulldown just shows color stuff. And then I get a paraview error message as shown in the attached image. It says that there are problems in my boundary conditions, but I copied them verbatim from the motorBike tutorial, so I know that there must be some other problem. But what is it? I think the answer must be something simple that I will be embarrassed about, but I am still stumped.


Help!

[Bloerb]

This error occurs if paraview can't find a boundary condition for all fields. The issue is that you definied custom variables for example internalField kOmega and used includeEtc to abbreviate some of them etc...now once you solve your case these are automatically added from the solver for all solution time steps...the issue is that your custom definitions in the zero folder can't be read by paraview. Either fully write out all of them or skip the zero folder when reading in the case.


Or simply open the case in paraview and switch to the next time step. The error will still be there but once you are past the 0 folder everything should work.

[boffin5]

Thank you again Bloerb, for your help!

I am still working the p & U not showing in paraView problem, with some progress, but it's still a mess.

In my previous post, I had mentioned this paraView error: 'unsupported directive includeEtc.' Also shown in the message was:
'expected number, string or (, found pressure.'

In this particular case, openFoam is not recognizing '#includeEtc "caseDicts/setConstraintTypes"' for some reason.

So my first attempt was to add ' export PATH=~/OpenFOAM/OpenFOAM-8/etc/caseDicts/:$PATH' into my .bashrc file. It ddn't work.

In a search, I found comments from you, responding to a similar problem (sorry, can't find it now). In your reply, you said that the contents of the setConstraintTypes file could be added to each boundary condition in /0. This I did, and the openFoam complaints went away! Here is the p file in 0:

FoamFile
{
    version     2.0;
    format      ascii;
    class       volScalarField;
    object      p;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

#include        "include/initialConditions"

dimensions      [0 2 -2 0 0 0 0];

//internalField   uniform $pressure;
internalField   uniform 0;

boundaryField
{
    //- Set patchGroups for constraint patches
    //#includeEtc "caseDicts/setConstraintTypes"

    inlet
    {
        type            zeroGradient;
    }

    outlet
    {
        type            fixedValue;
        value           $internalField;
    }

    ground
    {
        type            zeroGradient;
    }
    
     frontier
    {
        type            slip;
    }

    wing
    {
        type            zeroGradient;
    }

cyclic
{
    type  cyclic;
}

cyclicAMI
{
    type  cyclicAMI;
}

cyclicACMI
{
    type  cyclicACMI;
    value $internalField;
}

cyclicSlip
{
    type  cyclicSlip;
}

conformalCoupled
{
    type  conformalCoupled;
}

empty
{
    type  empty;
}

cyclicRepeatAMI
{
    type  cyclicRepeatAMI;
}

processor
{
    type  processor;
    value $internalField;
}

processorCyclic
{
    type  processorCyclic;
    value $internalField;
}

symmetryPlane
{
    type  symmetryPlane;
}

symmetry
{
    type  symmetry;
}

wedge
{
    type  wedge;
}

}

I also found that openFoam was not recognizing 'include/initialConditions', so I had to change all the BC's to remove that reference, and put in all the actual values. You can see this in the above file.


In this particular case, why are these changes necessary? Who knows? They seem to be a clumsy measure for a problem that shouldn't be there.


So after all these changes to satisfy the paraView gripes, here is what happens:


p and U are now showing, but when I pick the 'run' triangle at the top, they do not increment, but just stay at the initial condition. The attached image just stays unchanged.


However! I am tracking the forces in this case, and in postProcessing, I see this output:

# Force coefficients
# liftDir     : (0.000000e+00 0.000000e+00 1.000000e+00)
# dragDir     : (1.000000e+00 0.000000e+00 0.000000e+00)
# pitchAxis   : (0.000000e+00 1.000000e+00 0.000000e+00)
# magUInf     : 2.000000e+01
# lRef        : 1.420000e+00
# Aref        : 7.500000e-01
# CofR        : (7.200000e-01 0.000000e+00 0.000000e+00)
# Time          Cm              Cd              Cl              Cl(f)           Cl(r)         
0               -3.110116e-06   3.447695e-04    -8.214199e-06   -7.217215e-06   -9.969833e-07
1               -1.182160e-01   1.696657e-01    -2.737468e-01   -2.550894e-01   -1.865738e-02
2               -6.849332e-02   8.714572e-02    -1.539839e-01   -1.454853e-01   -8.498621e-03
3               -4.967265e-02   3.516505e-02    -1.091358e-01   -1.042406e-01   -4.895274e-03
4               -3.744147e-02   2.635948e-02    -8.024028e-02   -7.756161e-02   -2.678671e-03

So the data is incrementing, but paraView is not updating the image. Even if I skip time zero, it doesn't update.


Can you help me understand this snafu?

[Bloerb]

In this particular case, why are these changes necessary? Who knows? They seem to be a clumsy measure for a problem that shouldn't be there.

You need to change those, because ParaView is made by another software company. The openfoam devs are simply providing a plugin. So when you enter paraFoam that is a very short script that simply creates an empty dummy file case.foam and tells paraview to open that file. Hence you could just install paraview on any system, add an empty file with a .foam ending to your case folder and paraview will know to check a constant folder for a polyMesh and how to read that, as paraview is shipped with a reader plugin for .foam files. If you define abbreviations and custom variables like includeEtc this fails. This is why the default is to skip the zero time step folder. Because it does normally not include any result files, but might have those custom definitions. You could ofcourse say that is lazy work of the plugin creators and the devs might add those to the next paraview version. If that isn't already the case for includeEtc...but they can't cover every custom variable definition possible.


Nevertheless...
If you do have a writeInterval set so that an actual time step folder is written each time they should be read when opening paraview. You might have to use the refresh button in paraview or restart it once the results are there.

[boffin5]

Hi Bloerb,

Thanks again; I am fortunate to receive help from knowledgeable people such as yourself.

I solved my #include files problem by taking the mesh, along with the flow parameters, and plugging them into an older case that actually worked properly. Now it was okay, and I didn't have to include all of those caseDicts in the BC files.

Note to self: If you have a case where everything works properly, DO NOT UNDER ANY CIRCUMSTANCES, delete it, but rather place it in an archive for safe keeping.

But, whereas the older case gave proper results for flow past a body, when I made the substitutions, I got very strange results for the U flowfield, as seen in the attached image. I kept all the BC file structures the same, and despite my specifying the velocity as 40 m/sec., it looks as though the flow is just meandering around at some slow value. Regarding the p results, they just stay the same and do not update. Also attached is an image showing the domain definition. This domain came from salome, and included the definitions for inlet, outlet, ground, wing and frontier.

Here are my boundary condition files, in the hopes that obvious mistakes can be seen:

for k:

#include        "include/initialConditions"

dimensions      [0 2 -2 0 0 0 0];

//internalField   uniform $turbulentKE;
internalField   uniform 0.24;

boundaryField
{
    //- Set patchGroups for constraint patches
    #includeEtc "caseDicts/setConstraintTypes"

    //- Define inlet conditions
    #include "include/fixedInlet"

    outlet
    {
        type            inletOutlet;
        inletValue      $internalField;
        value           $internalField;
    }

    ground
    {
        type            kqRWallFunction;
        value           $internalField;
    }

    wing
    {
        type            kqRWallFunction;
        value           $internalField;
    }
    
    frontier
    {
        type            slip;
    }
   
}

for nut:

dimensions      [0 2 -1 0 0 0 0];

internalField   uniform 0;

boundaryField
{
    //- Set patchGroups for constraint patches
    #includeEtc "caseDicts/setConstraintTypes"

    inlet
    {
        type            calculated;
        value           uniform 0;
    }

    outlet
    {
        type            calculated;
        value           uniform 0;
    }

    ground
    {
        type            nutkWallFunction;
        value           uniform 0;
    }

    wing
    {
        type            nutkWallFunction;
        value           uniform 0;
    }
    
     frontier
    {
        type            slip;
    }

}

for omega:

#include        "include/initialConditions"

dimensions      [0 0 -1 0 0 0 0];

//internalField   uniform $turbulentOmega;
internalField   uniform 1.78;

boundaryField
{
    //- Set patchGroups for constraint patches
    #includeEtc "caseDicts/setConstraintTypes"

    #include "include/fixedInlet"

    outlet
    {
        type            inletOutlet;
        inletValue      $internalField;
        value           $internalField;
    }

    ground
    {
        type            omegaWallFunction;
        value           $internalField;
    }

    wing
    {
        type            omegaWallFunction;
        value           $internalField;
    }
    
    frontier
    {
        type            slip;
    }

}

for p:

#include        "include/initialConditions"

dimensions      [0 2 -2 0 0 0 0];

//internalField   uniform $pressure;
internalField   uniform 0;

boundaryField
{
    //- Set patchGroups for constraint patches
    #includeEtc "caseDicts/setConstraintTypes"

    inlet
    {
        type            zeroGradient;
    }

    outlet
    {
        type            fixedValue;
        value           $internalField;
    }

    ground
    {
        type            zeroGradient;
    }

    wing
    {
        type            zeroGradient;
    }
     
    frontier
    {
        type            slip;
    }
   
}

and for U:

#include        "include/initialConditions"

dimensions      [0 1 -1 0 0 0 0];

//internalField   uniform $flowVelocity;
internalField   uniform (40 0 0);

boundaryField
{
    //- Set patchGroups for constraint patches
    #includeEtc "caseDicts/setConstraintTypes"

    #include "include/fixedInlet"

    outlet
    {
        type            inletOutlet;
        inletValue      uniform (0 0 0);
        value           $internalField;
    }

    ground
    {
        type            fixedValue;
        value           $internalField;
    }

    frontier
    {
        type            slip;
    }

    wing
    {
        type            noSlip;
    }
    
    
}

I'm finding OpenFoam to be like whac-a-mole; as soon as I solve one problem, another one pops up!

Any idea what is going on with my U field? Again, sincere thanks for all the help you have given me.