[mer]

Hi,
Did the latest version of FunkySetFields.r7568 work with OF 1.4.1. I try to compile it, but there are some errors?

I hope that I find a quick response.

Djemai

[gschaider]

Hi Djemai!

That's right. That version only compiles with 1.4. Get the svn-version with the command described above the file that you downloaded

Bernhard

[mer]

Thank you Bernhard.

[mer]

Hi all,
I have recently compiled funkySetfields for OF 1.4.1, but when I run the utility I get some errors:
-------------------------------------------------
#0 Foam::error::printStack(Foam:stream&) in "/home/mer/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/home/mer/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#2 Uninterpreted: [0x6d6420]
#3 Foam::sqrt(Foam::Field<double>&, Foam::UList<double> const&) in "/home/mer/OpenFOAM/OpenFOAM-1.4.1/lib/linuxGccDPOpt/libOpenFOAM.so"
#4 Foam::tmp<foam::geometricfield<double,> > Foam::sqrt<foam::fvpatchfield,>(Foam::GeometricFie ld<double,> const&) in "/home/mer/OpenFOAM/mer-1.4.1/applications/bin/linuxGccDPOpt/funkySetFields"
#5 .L30835 at ValueExpressionParser.C:0
#6 ValueExpressionDriver::parse(std::string const&) in "/home/mer/OpenFOAM/mer-1.4.1/applications/bin/linuxGccDPOpt/funkySetFields"
#7 doAnExpression(Foam::fvMesh const&, Foam::word const&, Foam::string const&, Foam::string const&, Foam::Time const&, bool, bool, Foam::dimensionSet const&, bool, Foam::List<foam::word> const&) in "/home/mer/OpenFOAM/mer-1.4.1/applications/bin/linuxGccDPOpt/funkySetFields"
#8 main in "/home/mer/OpenFOAM/mer-1.4.1/applications/bin/linuxGccDPOpt/funkySetFields"
#9 __libc_start_main in "/lib/i686/nosegneg/libc.so.6"
#10 Foam::regIOobject::readIfModified() in "/home/mer/OpenFOAM/mer-1.4.1/applications/bin/linuxGccDPOpt/funkySetFields"
Floating point exception
-------------------------------------------------
Did anyone have an idea how to resolve this problem?

Thanks
Djemai

[gschaider]

What is the expression you're calculating? Is there a sqrt in it? By any chance a squareroot of a negative value? Because that is my suspicion when I look at #4 in your stacktrace

[mer]

Hi Bernhard,
Yes in my expression there is a sqrt, but there is no negative value inside because all terms are powered to 2. simply it is an equation of a sphere add to other positive terms.

Djemai

[gschaider]

Could you please post the expression anyway? The problem is definitly happening during the evaluation of the sqrt. On possibility to check: Let the utility calculate the expression INSIDE the sqrt and check the result (for NaNs etc)

[tspon]

Hi Bernhard,

I downloaded your svn-Version of funkySetFields from the wiki and renamed all files in order to get C-Files etc.
But I do not know how to compile. I already tried "bison ValueExpressionParser.yy" to get .tab-Files but doesn't help (version 2.3). I also tried a wmake but it stopped and make writes: no rule to make target "funkySetFields.dep".
Could you please help me?
I use OF1.4.1.

Regards,
Thomas

[mer]

Hi Bernhard,
Excuse me to take your time. Yes, it is my error. I put a sqrt in place of sqr inside the expression: sqrt(sqr(pos().x -2.*pow(10.,-2.))+sqr(pos().y -2.*pow(10.,-2.))+ sqr(pos().z -3.*pow(10.,-2.)))<=0.0001 ? 1:0
But I have another problem. using this expression with funkySetFields it doesn't initiate my field. I verify the same equation with setGammaDamBreak and it works. What is the problem.

[mer]

Hi Thomas,
I have compiled the last svn-Version of funkySetFields without any errors. To be sure that you are in the good way:
1) try to see if you have bison: bison -V
2) don't forget to run insertGenerated.sh
3) wmake should be inside the
funkySetFields directory with the presence of Make directory.
Hope this will help.

Djemai

[gschaider]

Hi Djemal!

At first: it should be possible to write 2e-2 instead of 2*pow(10.,-2). This would a) make the expression simpler and b) reduce the computation time (because 2*pow(10,-2) will be computed for every cell. Have you tried to make the radius (which is 2 orders of magnitude smaller than the coordinates of the midpoint) much larger? I mean: how large are your cells? With that difference in magnitudes it might be possible, that no cell-center fits your condition

Bernhard

----

Hi Thomas!

Did you download it using svn or via the web-browser? Because I was weondering why there was any need to rename the C-files?

Bernhard

[tspon]

Hi Bernhard an Djemai,

thanks for your help. It works now. I had some problems with my browser, therefore I had to rename all the files. But after downloading them from anonther pc the files remained unchanged and wiki-instructions worked fine.

Regards,

Thomas

[tspon]

Hi Bernhard and Djemai,

it works now. I had some problems with my browser therefore I had to change the filenames. But using another pc the files remained unchanged and wiki instructions worked fine. Thanks for your help and the quick replies.

Regards,
Thomas

[gschaider]

Hi Thomas!

With SVN-Archives the browser is only good for looking at the stuff. Use the svn-command to actually "download" it.

Bernhard

[mer]

Hi Bernhard !
thank you, I understand and it works.
Djemai

[sega]

I used funkySetFields to create a spherical initial condition:

funkySetFields . . -field gamma -expression 1 -condition "pos().x*pos().x + pos().y*pos().y <= 1" -time 0

I didn't had the chance to say if the condition is right, because there was this error:

--> FOAM FATAL ERROR : This mesh contains patches of type empty but is not 1D or 2D
by virtue of the fact that the number of faces of this
empty patch is not divisible by the number of cells.

From function emptyFvPatchField<type>::updateCoeffs()
in file fields/fvPatchFields/constraint/empty/emptyFvPatchField.C at line 1

Looks like there is a problem with the mesh.
Does anybody know, what went wrong?

blockMeshDict

[7islands]

Hi Sebastian,
You can read the error message straightforwardly: patch (1 2 14 13) is missing in leftAndBottom.

And don't forget to scale the expression given to FSF, e. g. pos().x*pos().x + pos().y*pos().y <= 0.02*0.02,
since there's convertToMeter 0.01; in your blockMeshDict.

Takuya

[sega]

Hello Takuya.

Of course. That solved the problem.
But the simulation is not running as planned.

As this has nothing to do with funkySetFields I will talk about it in another thread the next days.

Thanks. S.

[ngj]

Hi all

Lately I have been working with waves over submerged bars, and I have experienced a problem when initializing the gamma-field. I am using hex-cells and initializing with setFields (SF), but as I can see that the problem would arise from using funkySetField (FSF) as well. The problem is seen in the following figure:



SF and FSF initializes based on the cell center coordinate, thus a cell might be partly full but the fraction of gamma is only set to either 0 or 1, which results in the step-like feature of the attached figure.

I am considering making a routine - even though it might be some time into the future, as its priority is very low - which calculates the wet and dry fractions of these partially full cells. This would enable an initialization of the surface, which is perfectly flat and thus the fast moving surface waves, which I am struggling with at the moment, will be history.

Thus my questions are two-fold:

1. Would people be interested in such a tool?

2. The mesh generator has some routine to calculate the cell volumes based on an arbitrary shape. Could any of you point me to where it happens, as I am not strong in calculating the volume of arbitrarily shaped cells.

Best regards,

Niels

[gschaider]

Hi Niels!

Maybe a quick fix could be the following expression in funkySetFields (havn't got the time to try this out so the syntax might be slightly wrong):

"average(fpos().y < 0 ? 1 : 0)"

This constructs a face-field according to the criterium and then creates the cell field by averaging the values on the faces. This should smoothen things out a bit

All the functions are described on http://openfoamwiki.net/index.php/Co...funkySetFields

Bernhard

PS: Let me know if you have any problems. This part of FSF is not too well tested