[srv537]

I am trying to simulate a case of 100×35 mm rectangle with the 8x25mm obstacle on the top side (Atmosphere). This obstacle will move left to right leaving 5mm space to vertical wall with Initial water level is 20mm

The case files are given in the attachment

The obstacle is moving but it is not affecting the water phase.
I dont know what is the problem, i have attached complete case file.

Thank you,
Saurav


Modified by Tobi: Please use code tags instead of quotes and if you upload all files, there is no need to show it here.

[Phicau]

Hi

try this in U:

obstacle
{
        type            movingWallVelocity;
        value           uniform (0 0 0);
}

Best,

Pablo

[srv537]

Originally Posted by Phicau

Hi

try this in U:

obstacle
{
        type            movingWallVelocity;
        value           uniform (0 0 0);
}

Best,

Pablo

I tried this but its not working

[NablaDyn]

Originally Posted by srv537

I tried this but its not working

Hey Saurav,

did you make any progress?

I'm having a similar problem:
A moving piston in an IC engine. I'm working with the movingWallVelocity boundary condition in rhoPimpleFoam but the results are unsatisfactory. I use prescribed mesh motion, which means I have a 'manually' deformed mesh for each time step (i.e. ), so no 'dynamic mesh deformation' in typical OpenFOAM terminology). More specifically: I have a single mesh for each time step onto which I map the corresponding flow field from the preceding time step solution. The piston moves in -direction with the time dependent velocity . I tried the moving wall boundary condition with the following values:

• uniform (0 0 0)
• uniform (0 1 0)
• uniform (0 0)

Maybe we can join our efforts...

[Tobi]

Hi all,

I was just trying your case and I got the expected results. The only thing I changed is to move the obstacle down because otherwise the water level will not really rise up (gap is 5mm). With that, I get the results I expect. However, I was trying to use the PIMPLE algorithm here, it fails! So one should make a bigger workaround in order to proof that everything is fine. I used the library you are using once for a two stroke engine but it is not possible with the existing features to connect the channels with the moving piston (tried with ACMI). However, keep us up to date.

@NablaDyn. If I got you correct, you have for each time step a mesh and you map the things from one time step to the other, right? Are you taking the fluxes into account? I mean, the normal mapping should not work in an conservative way, right?

[NablaDyn]

Originally Posted by Tobi

Hi all,

I was just trying your case and I got the expected results. The only thing I changed is to move the obstacle down because otherwise the water level will not really rise up (gap is 5mm). With that, I get the results I expect. However, I was trying to use the PIMPLE algorithm here, it fails! So one should make a bigger workaround in order to proof that everything is fine. I used the library you are using once for a two stroke engine but it is not possible with the existing features to connect the channels with the moving piston (tried with ACMI). However, keep us up to date.

@NablaDyn. If I got you correct, you have for each time step a mesh and you map the things from one time step to the other, right? Are you taking the fluxes into account? I mean, the normal mapping should not work in an conservative way, right?

Hi Tobi,

first, thanks for your swift help. Yes, exactly. A missing flux restriction for the moving wall is what I seem to experience. The solution behaves as if the only 'driving force' of fluid flow is numerical error introduced by the mapping from one mesh onto another. But this is also what puzzles me, since I used to think the movingWallVelocity BC would do just that (flux 'elimination') .

[Tobi]

If you map one solution (mesh 1) to another mesh (mesh 2) then there is no consistency of fluxes. The mapFields application will not take care of flux conservation, it is just mapping the data. This is a wrong approach and cannot be used only and only if you modify the application to ensure flux consistency.

[NablaDyn]

Originally Posted by Tobi

If you map one solution (mesh 1) to another mesh (mesh 2) then there is no consistency of fluxes. The mapFields application will not take care of flux conservation, it is just mapping the data. This is a wrong approach and cannot be used only and only if you modify the application to ensure flux consistency.

Sorry for the late reply, I have been away from office for some days. Yes, of course I am aware that mapping won't do so. Instead, I was hoping the movingWallVelocity patch would somehow manage the conservation correction, as I'm not familiar with the specific principles of that boundary wrapper. Well, now I know better and already switched to coldEngineFoam which is doing quite a nice job. Modifying solvers will surely not result in any significant benefit compared to using the existing library in my case.

So thanks for your clear hints and support.

Best regards,

Martin