[shildenbrand]

Hi all,

I have following problem:
I want to simulate how a liquid runs out of a (car) door sill. The door sill is kind of box-shaped, but unfortunately only kind of: The left and the right side have different heights, the left side and right side are not perpendicular to the bottom, with each side being differently. Unfortunately I am not allowed to post picture here.

The door sill itself is located in a larger box which is my computational area.

I now want to impose a initial condition for alphawater such that the door sill is filled to a certain percentage with my liquid.

Basically I need to know which cell is inside the door sill and which cell is outside.

I generate my mesh using snappyHexMesh and reading in STL data.

With funkySetFields I can make a logical expression in the form of "(pos().x > 1.487) && (pos().x < 3.052)" [...] but that is not sufficient.

Any ideas anyone?

Thanks,
Stefan

[gschaider]

Originally Posted by shildenbrand

Hi all,

I have following problem:
I want to simulate how a liquid runs out of a (car) door sill. The door sill is kind of box-shaped, but unfortunately only kind of: The left and the right side have different heights, the left side and right side are not perpendicular to the bottom, with each side being differently. Unfortunately I am not allowed to post picture here.

The door sill itself is located in a larger box which is my computational area.

I now want to impose a initial condition for alphawater such that the door sill is filled to a certain percentage with my liquid.

Basically I need to know which cell is inside the door sill and which cell is outside.

I generate my mesh using snappyHexMesh and reading in STL data.

With funkySetFields I can make a logical expression in the form of "(pos().x > 1.487) && (pos().x < 3.052)" [...] but that is not sufficient.

Any ideas anyone?

Thanks,
Stefan

Sorry. Without even a sketch it's hard to understand what you're saying.

And in case of "I am not allowed to post of picture here" consider getting a support contract with someone who can help you. The topic (car) and the town (Stuttgart) suggest that you're not working for someone who can't afford it

[shildenbrand]

Originally Posted by gschaider

Sorry. Without even a sketch it's hard to understand what you're saying.

And in case of "I am not allowed to post of picture here" consider getting a support contract with someone who can help you. The topic (car) and the town (Stuttgart) suggest that you're not working for someone who can't afford it

Ok you're right. Without a sketch - hard to understand. So I tried this sketch (cut through the configuration):IMG_0310.jpg

And by the way - no- I am not working for the company you are assuming, neither directly nor doing project work for them.

[akidess]

Much better. Is the outer basin essential, or could you just drain into "infinity" instead?

[shildenbrand]

Hi Anton,


for the first period of the process (which is the draining part) it is not necessary, for the second period (when the last drops come out) I need at least the bottom side.

Stefan

[akidess]

An idea might be to just have the door sill alone and initialize it, and then use mapfields to a domain containing the outer box.

[shildenbrand]

Originally Posted by akidess

An idea might be to just have the door sill alone and initialize it, and then use mapfields to a domain containing the outer box.

I thought about that, too, but the problem is that the door sill has many holes and gaps. If I tried to mesh it separately, I'd have to close all holes.
I think about it again - thanks for your idea!

[gschaider]

Originally Posted by shildenbrand

I thought about that, too, but the problem is that the door sill has many holes and gaps. If I tried to mesh it separately, I'd have to close all holes.
I think about it again - thanks for your idea!

Is there a way to mark the "inner" region in the mesher and then write it out as a cellZone/cellSet? Because then setting the liquid only inside would be as simple as "(zone(inner) && pos().z<maxZ && pos().z>minZ) ? 1 : 0"

[shildenbrand]

I have tried the following:

Wrap the door sill only with large meshsize (-> holes get closed), use convex hull (-> really big holes get closed). This gave me a coarse closed volume, which I could use in snappyHexMesh.

Next steps:
- funkySetFields (as before, only looking at the z-axis)
- mapFields to my "old" fine case

When looking now at my initial solution at t=0 I am quiet happy with the result.
However, my computation now diverges quickly (which did not happen before - my previous initialization were two approximated boxes with different height).

@Bernhard: I have found no way to generate a cellset of the inside of the door sill - so far I tried only opensource-software to prepare the surfaces and SHM to generate a volume mesh.


Thanks for you answers, I have now a better initial condition - although a different new problem

[gschaider]

Originally Posted by shildenbrand

@Bernhard: I have found no way to generate a cellset of the inside of the door sill - so far I tried only opensource-software to prepare the surfaces and SHM to generate a volume mesh.

SHM has the ability to generate cellZones. See the snappyHeater (or so) tutorial

[shildenbrand]

Hi all,

just a quick update:

I've played around with cellSets (separately or within SHM) but none of this seems to work in my case. The (as of today) best way to generate an initial condition for alphawater seems to be:
- generate a closed version of the door sill
- funkySetFields with pos().z < <some value>
- go to the "big" case
- mapFields <from closed version>
- funkySetBoundaryField with expression "internalField(alphawater)"

--> the liquid looks pretty good afterwards, unfortunately I get convergence problems due to the mapping (I assume)

Stefan

P.S. Is there any way to include the boundary condition "constantAlphaContactAngle" within swak4Foam?

[gschaider]

Originally Posted by shildenbrand

P.S. Is there any way to include the boundary condition "constantAlphaContactAngle" within swak4Foam?

What do you mean with "include"?

[shildenbrand]

Originally Posted by gschaider

What do you mean with "include"?

If I use funkySetFields on 0/alphawater, where I use the BC (for example)

Schweller_Schweller_links
{
type constantAlphaContactAngle;
theta0 50;
limit gradient;
value uniform 0;
}

funkySetFields complains about the used type, gives me a overview about the correct ones (e.g. zeroGradient and some 50 others) and stops. I have to change the type to zeroGradient, use funkySetFields, and switch back to constantAlphaContactAngle.

By "include" I mean: How and where do I include $FOAM_SRC/transportModels/twoPhaseProperties/lnInclude such that funkySetFields does not complain anymore?

[gschaider]

Originally Posted by shildenbrand

By "include" I mean: How and where do I include $FOAM_SRC/transportModels/twoPhaseProperties/lnInclude such that funkySetFields does not complain anymore?

Thanks for the clarification. But you see the point? It was clear to you because you were confronted with the problem before you wrote that posting. But everyone else is lacking that context. You wouldn't be happy with the answer "That is OK. The boundary condition is not in the runtime-selection table" instead of the one below (and there ARE people who'd confronted with that answer would say "Ah. Of course. Libs in controlDict. Only have to find the right library")

Originally Posted by shildenbrand

If I use funkySetFields on 0/alphawater, where I use the BC (for example)

Schweller_Schweller_links
{
type constantAlphaContactAngle;
theta0 50;
limit gradient;
value uniform 0;
}

funkySetFields complains about the used type, gives me a overview about the correct ones (e.g. zeroGradient and some 50 others) and stops. I have to change the type to zeroGradient, use funkySetFields, and switch back to constantAlphaContactAngle.

The "problem" is that constantAlphaContactAngle is a "special" boundary condition that is not present in the finiteVolume library. And FSF only links against this (would be hard to link it against every library that holds some boundary conditions). The good new is that you can "inject" additional BCs if they are in a library: just add that library to the libs-list in the controlDict then the runtime-selection-table will know about it and FSF can read and write this BC. The name of the library that has this boundary condition starts with "libtwoPhase" (which it is differs between OF-versions. Have a look in $FOAM_LIBBIN and experiment)

[shildenbrand]

Thank you very much for your help - it actually was "libtwoPhaseProperties.so" I had to declare in my controlDict.
You're right about the description of the problem (in text or by a sketch). I'll try my very best in the future.

[shildenbrand]

Hi all,

my final comment for future reference. The way I get my computation converging is slightly different as posted above. It is

- generate a closed version of the door sill
- funkySetFields with pos().z < <some value>
- go to the "big" case
- mapFields <from closed version>
- generate cellZone of cells near walls of door sill

faceSet f0 new patchToFace <Patches>
cellSet c0 new faceToCell f0 any
cellZoneSet c0Zone new setToCellZone c0

- use funkySetFields with condition "(zone(c0Zone))" to set alpha=0 there
- run case

Apparently my divergence problems came from alpha=1 at some outlet holes in the door sill.

Thanks again for the help.
Stefan