[gschaider]

Originally Posted by lrunber

Thanks, I see the problem was the example solver based on 1.7. I have 1.7 installed so I copied the /usr/lib/OpenFOAM-1.6-ext/src/swak4Foam to /opt/openfoam171/src and ran Allclean & Allwmake.
Now InterFoamWithSources compiles fine, however, the utilities e.g. funkySetFields are only in the 1.6-ext bin, and since the src was not included in the ubuntu packages I proceeded to:

DL the utilities from: https://openfoam-extend.svn.sourcefo...oam/Utilities/
and proceed to paste into: /opt/openfoam171/applications/utilities/swak4Foam
After running wmake on the utilities (had to change /Make/options as in previous post), I can succesfully run mixingThing case.

Thanks for the great programs

That's the way it is: swak4foam supports no distro completely. For 1.6-ext those two examples do not work, for 1.7 the finiteArea stuff does not work

Seriously: I also built a swak4foam-package for 1.7.1. The problem is that I can't distribute it via launchpad because launchpad instists (which is a good thing) to rebuild packages from the sources. To do so it has got to install openfoam171 in a virtual machine and I don't know how to do that with a package which is not on the official ubuntu-severs and not in a launchpad-PPA. And I don't have the time to repackage 1.7 (especially as the debian-directory was removed from the 1.7-git - there are stil traces of it there)

BUT: if you have the sources (the version from mercurial. Probably also works with the one from SVN) you can always build your own debian package and install it locally (just make sure that your shell is set to the OF-distro that you want to build for and say "make dpkg")

[mabinty]

Dear Bernhard!

Thanks for your reply. I visualized the cellSet in paraFoam (supports both cellSets and zellZones) and could see that the described problem comes from my set-up and not from swak. Fortunatelly I could solve that (please see http://www.cfd-online.com/Forums/ope...tml#post307325) and the simulation runs ... but only on single CPU . When parallelizing on 4 CPUs wired things happen as it seems that decomposePar originally doesn t decompose cellSets. For that I found a patch here http://www.cfd-online.com/Forums/ope...epar-sets.html (from you). I hope it also works with OF-1.7.1, anyway I ll try out and report.

Regards,
Aram

Originally Posted by gschaider

The message you highlighted is not the problem. It just says "because I'm at t=0.1 I had a look in 0.1/air/polyMesh/sets and the cell set wasn't there so I'm going for the one in constant" which is actually what you want anyway.

About the headSource being in the wrong place I have no idea. Have you tried to visualize it without using swak? Either in paraFoam (I think that supports sets) or if you're using the native reader (I think that only supports zones) by converting it with setsToZones. If THAT is in the right place then it is a swak-problem otherwise I'd guess it is a problem with the setup

[gschaider]

Originally Posted by mabinty

Dear Bernhard!

Thanks for your reply. I visualized the cellSet in paraFoam (supports both cellSets and zellZones) and could see that the described problem comes from my set-up and not from swak. Fortunatelly I could solve that (please see http://www.cfd-online.com/Forums/ope...tml#post307325) and the simulation runs ... but only on single CPU . When parallelizing on 4 CPUs wired things happen as it seems that decomposePar originally doesn t decompose cellSets. For that I found a patch here http://www.cfd-online.com/Forums/ope...epar-sets.html (from you). I hope it also works with OF-1.7.1, anyway I ll try out and report.

Regards,
Aram

cellSets are a bit of a step-child so I wouldn't count on that. What you can do is decompose first THEN construct the cellSets in parallel.

[mabinty]

cellSets are a bit of a step-child so I wouldn't count on that. What you can do is decompose first THEN construct the cellSets in parallel.

I was also thinking about doing that but for now I have no idea how, as the flag "-parallel" didn t work (actually I think its for creating the cellSet with more than one CPU). Any hint would be greatly appreciated!

Hence, I focused on compiling the decomposeParWithSets and it seems to work for me so far thanks!! I ll report here in case of any troubles.

Cheers,
Aram

[ziad]

Hi Bernhard,

I wouldn't be surprised if you were already busy with it but thought I'd ask anyway. Are there plans to port swak4Foam to 2.0.0?

Cheers,
Ziad

[gschaider]

Originally Posted by ziad

I wouldn't be surprised if you were already busy with it but thought I'd ask anyway. Are there plans to port swak4Foam to 2.0.0?

It is work in progress:
http://sourceforge.net/apps/mantisbt...view.php?id=73
The comment describes what is working and how to get it. Will finish it when I rejoined the ranks of the working people (next week or so)

Bernhard

[sega]

Sorry I can't install the swak4you because wmake outputs

cannot find -lswak4FoamParsers

Any ideas what may be wrong?

[gschaider]

Originally Posted by sega

Sorry I can't install the swak4you because wmake outputs

cannot find -lswak4FoamParsers

Any ideas what may be wrong?

No. To quote Rod Stewart "The first cut is the deepest". I think this is the last in a long line of error messages (if you compiled it with "wmake all").

The difference between compiler messages and Agatha Christie novels is that skipping to the last page doesn't work. The interesting stuff is in the beginning (in the compiler messages)

[gascortado]

Hi, I recently installed OF-1.6-ext alongside OF-1.6.

While using OF-1.6 I modified groovyBC and I was able to compile it by using wmake all without problems.

Now, I need the functions that I created using groovyBC in OF-1.6-ext. I tried the following command:

santiago@santiago-laptop:~/groovyBC$ wmake all

make: *** No rule to make target `/usr/lib/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude/mixedPointPatchField.H', needed by `groovyBCPointPatchFields.dep'. Stop.

As I mentioned before, everything is cool while compiling under OF-1.6, but not when switching to OF-1.6-ext.

Any idea of what I can do? Is it possible to even compile the "old" groovyBC stuff under 1.6-ext?


I also tried by downloading swak4Foam and compiling just as I did before and I get the following:

santiago@santiago-laptop:~/swak4Foam$ wmake all

No simpleFuctionsObject existing. Press ENTER to continue compilation or abort and download it with the downloadSimpleFunctionObjects.sh script

then when I press enter:

/usr/lib/OpenFOAM-1.6-ext/lib/libgroovyBC.so shadows library that will be compiled. This might break the compilation of the utilities
Set the environment variable I_KNOW_THE_RISCS if you want to continue nevertheless

what do I do in this case? I would really appreciate any help. Thanks

[sega]

Originally Posted by gschaider

No. To quote Rod Stewart "The first cut is the deepest". I think this is the last in a long line of error messages (if you compiled it with "wmake all").

The difference between compiler messages and Agatha Christie novels is that skipping to the last page doesn't work. The interesting stuff is in the beginning (in the compiler messages)

Of course you were right. It was due to the missing bison package.

[gschaider]

Originally Posted by gascortado

Hi, I recently installed OF-1.6-ext alongside OF-1.6.

While using OF-1.6 I modified groovyBC and I was able to compile it by using wmake all without problems.

Now, I need the functions that I created using groovyBC in OF-1.6-ext. I tried the following command:

santiago@santiago-laptop:~/groovyBC$ wmake all

make: *** No rule to make target `/usr/lib/OpenFOAM-1.6-ext/src/OpenFOAM/lnInclude/mixedPointPatchField.H', needed by `groovyBCPointPatchFields.dep'. Stop.

As I mentioned before, everything is cool while compiling under OF-1.6, but not when switching to OF-1.6-ext.

The thing is that you were compiling it in the same directory and there were still some old .dep-files. One of them pointing to mixedPointPatchField.H which does not exist under that name in 1.6-ext.

Solution: 'wclean all' AND rmdepall. Or use different source-directories for different OF-versions

Originally Posted by gascortado

Any idea of what I can do? Is it possible to even compile the "old" groovyBC stuff under 1.6-ext?

Yes it is.

Originally Posted by gascortado

I also tried by downloading swak4Foam and compiling just as I did before and I get the following:

santiago@santiago-laptop:~/swak4Foam$ wmake all

No simpleFuctionsObject existing. Press ENTER to continue compilation or abort and download it with the downloadSimpleFunctionObjects.sh script

then when I press enter:

/usr/lib/OpenFOAM-1.6-ext/lib/libgroovyBC.so shadows library that will be compiled. This might break the compilation of the utilities
Set the environment variable I_KNOW_THE_RISCS if you want to continue nevertheless

what do I do in this case? I would really appreciate any help. Thanks

Please read the README and tell me how the output about the simpleFunctionObjects is unclear in the light of the requirements-section

About the other thing: the script tests for the existence of an old-school groovyBC and warns you (because you might experience very subtle versions of DLL-hell. If you're unlucky you might notice them but your simulation results might be wrong). So either remove the lib or set the environment variable

[gascortado]

Thanks Bernhard for your quick response. I decided to use the old groovyBC since I already modified the source code successfully while using OF-1.6.

Now, I followed your recommendation and executed 'wclean all' AND rmdepall. After that I ran "wmake all" and this time the compilation starts but it runs into an error:

Make/linuxGccDPOpt/groovyBCPointPatchFields.o: In function `Foam::getFvPatch(Foam:ointPatch const&)':
groovyBCPointPatchFields.C.text+0x19b8): undefined reference to `typeinfo for Foam::fvMesh'
groovyBCPointPatchFields.C.text+0x1a1f): undefined reference to `Foam::fvMesh::boundary() const'
groovyBCPointPatchFields.C.text+0x1a48): undefined reference to `typeinfo for Foam::fvMesh'
collect2: ld returned 1 exit status
make: *** [OpenFOAM.out] Error 1

The whole log is attached below. I also tried by copying the groovyBC folder and renaming it groovyBC-1.6-ext and followed the same procedure but with no luck (same error). I will really appreciate any hints on how to proceed now. Thanks again

[gascortado]

I was able to fix the problem by using wmake libso. Thanks anyway

[claco]

Dear Bernhard,

I want to simulate the tutorial present in
tutorials/incompressible/pimpleFoam/TJunctionFan with the following modification.

I would like to simulate a non uniform fan, that is a fan that imposes a pressure jump dependent from the radius (supposing a circular fan).

Supposing that the radius_internal=0.5 [m] and radius_external=1.6[m], I would like to give a pressure jump according to the following expression=

100 [Pa] if the cell center is coincident with the internal radius, and 500 [Pa] if the cell center is coincident with the external radius, with a parabolic variation law (let assume a your own expression) on the intermediate cells.

Now the question is: can You please give me the correct expression I have to introduce in the 0/p file (using the swak4Foam tools), in place of the original expression reported below?

fan_half0
{
type fan;
patchType cyclic;
jump 100;
f 2(100 -0.1);
value uniform 0;
}
fan_half1
{
type fan;
patchType cyclic;
jump 100;
f 2(100 -0.1);
value uniform 0;
}
where a constant pressure jump is modelled?

Moreover, I also would like to model the fan swirl. That is, on fan_half1 the velocity is the same on fan_half0, but added with a swirl, that is a tangential velocity that goes from 1 [m/s] on the inner radius, up to 6 [m/s] on the external radius, once again with a parabolic variation law.
I think now the 0/U file has to be changed with respect to the original one, which is

fan_half0
{
type cyclic;
}
fan_half1
{
type cyclic;
}

Is it possible to do that? Can You kindly give me the correct expression to be introduced in the U file?


Thank You,

Claudio.

[gschaider]

Originally Posted by claco

Dear Bernhard,

I want to simulate the tutorial present in
tutorials/incompressible/pimpleFoam/TJunctionFan with the following modification.

I would like to simulate a non uniform fan, that is a fan that imposes a pressure jump dependent from the radius (supposing a circular fan).

Supposing that the radius_internal=0.5 [m] and radius_external=1.6[m], I would like to give a pressure jump according to the following expression=

100 [Pa] if the cell center is coincident with the internal radius, and 500 [Pa] if the cell center is coincident with the external radius, with a parabolic variation law (let assume a your own expression) on the intermediate cells.

Now the question is: can You please give me the correct expression I have to introduce in the 0/p file (using the swak4Foam tools), in place of the original expression reported below?

It's not that simple. groovyBC is based on the mixed boundary condition and the fan-BC is quite a different beast. So the solution involves a bit C++-programming (I call it groovyvieing the BC): create a BC that inherits from the original BC. Then add a jumpExpression to the BC. Evaluate that and assign the result to the jump-Field of the parent class and then let the parent class do its usual thing. Of course that assumes that the parent class internally uses a field instead of a scalar.

Examples of such groovified BCs live in swak in the groovyStandardBC-library and I gladly accept contributions there

[Anne Lincke]

Hey,

I am using swak very often for getting expressions/functions on the boundary which I define in controlDict.
Thanks a lot for this useful tool!
Nevertheless I have one question: Does swak work when running the simulation in parallel?
I have noticed that the values for a swak expressions are different, depending on if they are computed parallel or serial....

I would appreciate a lot an answer.

Kind Regards
Anne

[gschaider]

Originally Posted by Anne Lincke

Hey,

I am using swak very often for getting expressions/functions on the boundary which I define in controlDict.
Thanks a lot for this useful tool!
Nevertheless I have one question: Does swak work when running the simulation in parallel?
I have noticed that the values for a swak expressions are different, depending on if they are computed parallel or serial....

I would appreciate a lot an answer.

Kind Regards
Anne

How different? I mean: slightly different or completely wrong?

In principle swak is parallelized ... in all places that I'm aware of, but of course something may have escaped me. If the results are completely wrong then this may be the case. If the differ only slightly (several digits behind the comma) then I would put the blame on the "Parallel computations are not exactly the same as serial ones"

If you think that the problem is swak then I would appreciate a bug report at the OF-extend Mantis. With a small example case to reproduce it if possible.

BTW: which OF-version are you using?

[Anne Lincke]

Hey Bernhard,
thank you for the fast answer.
The first value is for example
4.4901153e-07
and the other value is
4.4901141e-07

The difference is small, but the values are small itself.
I am using the version 1.7.0

Probably these are the normal differences between parallel and serial computations. I just wanted to be sure if swak is fitting for parallel computing.

[gschaider]

Originally Posted by Anne Lincke

Hey Bernhard,
thank you for the fast answer.
The first value is for example
4.4901153e-07
and the other value is
4.4901141e-07

The difference is small, but the values are small itself.
I am using the version 1.7.0

Probably these are the normal differences between parallel and serial computations. I just wanted to be sure if swak is fitting for parallel computing.

Yeah. Calculate the relative error between the two values. Its order of magnitude is probably in the the order of magnitude of the solver tolerances you specified. So numerically they are equal

[Anne Lincke]

Okay, that makes sense.
The magnitude of the relative error is of order e-06 (basically x* e-07)
The function depends only on temperature.
In fvSolution I have set

T
{
solver smoothSolver;
smoother GaussSeidel;
tolerance 1e-06;
relTol 1e-03;
}

So the error is within the tolerance.
Thank you for the explanation!