[100GJR]

Hi all,

I am working on a project where the concept of a virtual/equivalent/notional nozzle/injector is implemented in a single cylinder engine to reduce simulation time.
Essentially what this concept entails is that the flow out of the injector is initially underexpanded, which causes high velocities and thus also small timesteps to keep up with the CFL limit. This underexpanded flow can be estimated using analytical relations, which use the conditions in the stagnation point (outside of engine) and the ambient pressure (in the cylinder) to estimate the conditions of the flow downstream where the flow behaves closer to fully expanded.

The way I would implement this in a constant pressure environment would be to add a bit of extra geometry downstream of the flow and let the inlet boundary condition be situated on that geometry.

In the engine however, the ambient pressure (in the cylinder) changes over time, and so the conditions and location of the virtual/equivalent/notional nozzle would have to change over time. This would mean that the surface acting as the inlet would also have to have motion properties added to it.

My main question is related to the motion, as I am unsure if this is possible within CONVERGE and if it would be possible, if it would cause significant effects on the accuracy due to numerical issues.
I know UDFs are available to work on such features not part of the standard CONVERGE toolset, but if I were to succesfully write up the code to function as I want, I am afraid this would introduce numerical issues into the domain, as the inlet might shift over cells that previously were part of the flow.

So to summarize:

• Can you make an inlet boundary move using UDFs?
• Should you want to make an inlet boundary move using UDFs or will it do more harm than good?

Thank you in advance for taking the time to help me!

[ksrivast]

Hello Gert,

Currently INFLOW/OUTFLOW boundary types cannot have a motion profile associated with them. There are ways to have INFLOW/OUTFLOW boundary triangles move. One option, as you have pointed out is through UDFs. Another option would be a careful creation of your INFLOW boundary triangles. If the INFLOW boundary is connected to adjacent moving wall boundaries, and all vertices of the INFLOW boundary triangles are shared with adjacent moving boundaries (no triangle vertices in the middle of the INFLOW boundary surface), then as the adjacent walls move, the shared vertices with the INFLOW boundary also move, thereby achieving surface motion.

The above approaches however can lead to some issues. If the INFLOW surface motion was tangential, then it might be fine. But if the boundary motion happens to be normal to the surface, then it would be wrong because we're not accounting for the motion velocity while evaluating fluxes at the boundary. You might have to carefully construct your flow boundary conditions to account for this.

For this problem, we also have an alternative option of using a MASS source in source.in. MASS sources are available in our latest v4 release. You can select your inlet surface as a MOVING WALL boundary and enable a boundary-based MASS source. Specified mass (total or per unit time or per unit volume time or based on back pressure) will be sourced on all cells along the moving boundary.

Hope this helps.

Sincerely,