[stephan]

Hi Hrvoje,

in which cases do we need vectorial materialconstants? actually i would think of pure diagonal tensors instead?!
in case of tensors would it be acceptable to demand
appropriate 3x3 tensor even for 2d cases from the user?
regards
stephan

[stephan]

hi,

jens did some promising calculations with the new interpolation in 1d/2d with scalar materialconstants and we are looking for testcases for non isotropic materialconstants. maybe someone in the forum has a nice idea? of course we would need an analytical solution to compare with or at least a solution from a different solver to check against.
so we are on the way...
thanks in advance
stephan

[hjasak]

Hello Stephan,

I do appreciate that in your problem diffusivity is scalar and doing a harmonic mean is trivial. However:
- in OpenFOAM we try to write generic operators and generic laplacian swallows tensorial diffusivity without trouble.
- you are in templated code and instantiation should be allowed for all types (scalar, vector, tensor...). Thus, it is better to live in generic terms
- we also need to worry about Galilean invariance in interpolation and now is the right time for it.

I think my idea of doing harmonic magnitude weights satisfies all issues, so it's just a question of trying it out now.

As for the test case, try any porous medium with ortho-tropic properties not aligned with grid lines (eg. use a tet mesh) - that should be hard enough.

Enjoy,

Hrv

[jwp]

Hi all!
A question: do you think the conjugateHeatFoam solver can be modified to a steady-state solver?

Jens

[hjasak]

Yes - throw away the ddt terms; for the fluids solvers look at simpleFoam and for the energy equation make sure you relax it right. The solid side will have alpha = 0.99 or similar, while the relaxation factor in the fluid will be more normal (e.g 0.7-0.8).

Looking forward to seeing your results,

Hrv

[jwp]

Thanks first.
Still I have problems, to relax the several coupled equations; like TEqns(0).relax() ?!?
Maybe I have it in few minutes - maybe you have another good hint for me ...

Jens

[jwp]

T.relax() and Tsolid.relax() is the right way, isn't it?

[hjasak]

Hello All,

I have checked in the new harmonic interpolation on the interface, as discussed before. Mike (and, of course, anyone else who is interested - sorry for calling out your name Mike), could you please update the SVN and try re-running the cases - in all I've tried it seems OK.

Please let me know,

Hrv

[mike_jaworski]

Hrv,
I am updating now and will report back as soon as possible. I apologize for not being able to help more lately. Finding online tools and information lacking, I just recently (3 days ago) received a C++ primer and have been working through it so I can be less of a bump on the log.

Regards,
Mike J.

[mike_jaworski]

Hrv,
Unfortunately, I can't report success. Are there additional key-words or new specifications for the fvSchemes or fvSolution files that I need to enter? If not (I skimmed the tutorial files but nothing jumped out at me) then I'm still showing the "moving solution" in the fluid domain with changing solid properties where it shouldn't be changing (as described above). I continue to work on my (lack of) C++ knowledge so hopefully I'll be able to diagnose this better than I have so far.

Regards,
Mike J.

[stephan]

hi michael,

hrv was faster in showing up the right source but since jens tested at least for scalar cases an implementation which was exactly what hrv described and i guess, hrv did it the way he wrote it above the problem might be elsewhere.
are you using the tolerances which you posted in the casefile? (like 10^-5 for T) jens had problems finding real steady solutions with these settings.
the solution simply "looked" steady since the Initial residual was pretty much the same than the
Final residual- which was simply still not steady state.
did you actually compared the time to reach steady state in FOAM with the anylytical solution?
setting the tolerances to something like 10^-12 gave real nice pic's?!
regards
stephan

[hjasak]

Heya Mike,

Easy test: set DT in fluid to be 1e-3 and 1 in solid and look at the patch field for regionCoupling patch in one of your results (not the zero field). I get:


internalField uniform 0.001;

boundaryField
{
movingWall
{
type zeroGradient;

left
{
type zeroGradient;
}
right
{
type regionCoupling;
remoteField DT;
value uniform 0.001998;
}
}

and

internalField uniform 1;

boundaryField
{
topAndBottom
{
type zeroGradient;

left
{
type regionCoupling;
remoteField DT;
value uniform 0.001998;
}
}

So, they are the same and equal to harmonic average. Do you get the same?

Hrv

[mike_jaworski]

Hrv and Stephen (and others),
Changing the tolerance did the trick. I must admit to be quite befuddled by this since in my brain, 1e-5 is already a very small number and why is the solution still moving at that level? My intuition is not geared in this way, apparently. The cutoff is 1e-07 (for 100x Copper diffusivity) as shown here for planar stagnation flow:

https://netfiles.uiuc.edu/mjaworsk/shared/OpenFOAM/Similarity-Stagnation/residua ls.png

Hrv, the calculation does come up correctly on my solution as well.

Happily,
Mike J.

[hjasak]

Thanks Mike - so, may I call this problem "resolved"?

As for small numbers, we reun double precision most of the time and this gives you 14 significant places and with large jump in diffusivity there are issues with residual normalisation.

Happily as well,

Hrv

[stephan]

hi,

nice that i could help even without contributing source fast enough...

regards
stephan

[mike_jaworski]

Hrv,

Yes to the resolved. At least from my perspective.

The only thing left, I suppose, is figuring out how to make it run parallel. I just started looking at this but it looks like the decomposePar utility will need some updating to make it compatible. I started assembling a decomposeParDict stuff for a case I'm trying to run and I got this error:

--> FOAM FATAL IO ERROR : keyword attached is undefined in dictionary "/home/mjaworsk/OpenFOAM/mjaworsk-1.4.1-dev/run/tray3Dcoolant/coolantPipe1Decomp /processor0/constant/polyMesh/boundary::pipeWall1"

file: /home/mjaworsk/OpenFOAM/mjaworsk-1.4.1-dev/run/tray3Dcoolant/coolantPipe1Decomp/ processor0/constant/polyMesh/boundary::pipeWall1 from line 50 to line 54.

From function dictionary::lookupEntry(const word& keyword) const
in file db/dictionary/dictionary.C at line 154.

FOAM exiting

I guess it needs some lecturing on what "attached" means. I'm considering splitting the meshes up before making the necessary changes to the boundary file manually, but I'm wondering what will happen if my fluid and solid meshes get decomposed at different locations and how that will affect things. Any thoughts on this so far?

Regards,
Mike J.

[suredross]

Hi all,
i am supposed to run a modified icofoam case but with dimensionless quantities.i got all the necesary equations in dimensionless form(on paper) but i do not know how to incorporate these into the code?also changing the dimensions of the initial conditions to zeros doesn't seem to work.any help is gladly welcome.

thanks
davey

[mike_jaworski]

Hi all,

I got an email asking about running conjugateHeatFoam in parallel. I wrote a lengthy reply and I figured I'd post my progress here. Unfortunately I'm still learning C++ so this is all likely a hack sort of job, but the solver is running in parallel (apparently).

First, decomposePar doesn't know what to do with regionCouple types in the "boundary" file, nor regionCoupling boundary conditions in the "T", "DT" files of your initial time file. You can, however, run the decomposePar utility if they have the "standard" types and boundaries. So, I manually edited them back to the original files and ran the utility.

Now, in each of the processor<n> directories, you have to edit the constant/polymesh/boundary file to do regionCoupling as well as the files in the initial time subdirectory. You also have to supply the symbolic links to the solid mesh (which is not decomposed). In addition, you have to make a "system" subdirectory for each processor and link this back to the solid mesh's system directory.

After this, you should be able to run your case in parallel using the standard command (e.g. mpirun -n 2 conjugateHeatFoam <root> <case> -parallel).

I wasn't smart enough to set things up to run on a small case to test, so mine is still running. I believe you'll have to undo (copy from backup!) the files edited to get it running in parallel so that reconstructPar will know what to do with the case files. Since my case is very big, it'll be a while before I know if it's really working or not, but it appears to be coming along fine.

Regards,
Mike J.

[mabinty]

Hi all!

I d love to try the conjugated heat transfer solver but the http://openfoam-extend.wiki.sourceforge.net/ link to download the development version mentioned in a previous post does not work (when I tried). I even searched the sourceforge page but couldn t find it.

Can anybody give me a hint where to get the CHT solver?

Thanx in advance!!

Mabinty

[gschaider]

Seems like that Wiki is somehow broken. In the meantime you can get Hrvs dev-version with

svn checkout https://openfoam-extend.svn.sourceforge.net/svnroot/openfoam-extend/trunk/Core/O penFOAM-1.4.1-dev/

Bernhard