[duguyoudi]

Hi everyone,


I met a problem when I try to set the initial field using funkySetFields. I am sorry that I can't upload the file since it's too big. Please see the screenshot I uploaded. The mesh was generated by snappyHexMesh with 5.3 million cells. The expression I used is

expressions
(
  u0
  {
     field U;
     expression "vector(3.824*pow((pos().z/0.08),0.28),0,0)";
  }
);

I tested to initialize the background mesh generated by blockMesh (0.16 m cells). Everything is fine.



Anyone knows how to solve this problem?


Leo

[gschaider]

Originally Posted by duguyoudi

Hi everyone,


I met a problem when I try to set the initial field using funkySetFields. I am sorry that I can't upload the file since it's too big. Please see the screenshot I uploaded. The mesh was generated by snappyHexMesh with 5.3 million cells. The expression I used is

expressions
(
  u0
  {
     field U;
     expression "vector(3.824*pow((pos().z/0.08),0.28),0,0)";
  }
);

I tested to initialize the background mesh generated by blockMesh (0.16 m cells). Everything is fine.



Anyone knows how to solve this problem?


Leo

The "problem" is that this is a binary file (see header and your controlDict). These are supposed to look like this

[duguyoudi]

Hi Gschaider,


Thank you for your reply.


I have checked the header of funkySetFieldsDict and controlDict. Both files are ascii. I am not sure if funkySetFields converts ascii file to binary file if the size of the file is big. I find that the boundary conditions in the same file ./0/U are ascii format. Does the inconsistent data format lead to openFoam failing to read the initial field?


Best,


Leo.


For someone who is interested in non-uniform initial field, the following code may be helpful.


internalField #codeStream
{
codeInclude
#{
#include "fvCFD.H"
#};

codeOptions
#{
-I$(LIB_SRC)/finiteVolume/lnInclude \
-I$(LIB_SRC)/meshTools/lnInclude
#};

codeLibs
#{
-lmeshTools \
-lfiniteVolume
#};
code
#{
const IOdictionary& d = static_cast<const IOdictionary&>(dict);
const fvMesh& mesh = refCast<const fvMesh>(d.db());
vectorField U(mesh.nCells(), vector(0, 0, 0));

forAll(U, i)
{
const scalar z = mesh.C()[i][2];
const scalar Uref=3.824;
const scalar zref=0.08;
const scalar alpha=0.28;
U[i] = vector(Uref*pow(z/zref,alpha), 0.0, 0.0);
}

U.writeEntry("", os);
#};

};

[gschaider]

According to your screenshot it is a binary file. funkySetFields does not change that setting. It is irrelevant what the headers of those files say. Important is the setting writeFormat in your controlDict. That seems to have been binary at the time funkySetFields was run (maybe you changed it later)

Originally Posted by duguyoudi

Hi Gschaider,


Thank you for your reply.


I have checked the header of funkySetFieldsDict and controlDict. Both files are ascii. I am not sure if funkySetFields converts ascii file to binary file if the size of the file is big. I find that the boundary conditions in the same file ./0/U are ascii format. Does the inconsistent data format lead to openFoam failing to read the initial field?


Best,


Leo.


For someone who is interested in non-uniform initial field, the following code may be helpful.


internalField #codeStream
{
codeInclude
#{
#include "fvCFD.H"
#};

codeOptions
#{
-I$(LIB_SRC)/finiteVolume/lnInclude \
-I$(LIB_SRC)/meshTools/lnInclude
#};

codeLibs
#{
-lmeshTools \
-lfiniteVolume
#};
code
#{
const IOdictionary& d = static_cast<const IOdictionary&>(dict);
const fvMesh& mesh = refCast<const fvMesh>(d.db());
vectorField U(mesh.nCells(), vector(0, 0, 0));

forAll(U, i)
{
const scalar z = mesh.C()[i][2];
const scalar Uref=3.824;
const scalar zref=0.08;
const scalar alpha=0.28;
U[i] = vector(Uref*pow(z/zref,alpha), 0.0, 0.0);
}

U.writeEntry("", os);
#};

};

[duguyoudi]

Hi Gschaider,


Thank you for your help.



It's my mistake. I thought the writeFormat only controlling output format of openfoam solvers.

Leo