Learning Forum

[not.lah.enough]

Hi all,

I am running into a very weird problem when simulating a three-phase VOF case, consisting of water, liquid ammonia, and vapor ammonia. The problem statement is shown in the illustration below. Liquid refrigerated ammonia (initial temperature at inlet below boiling point of -33.4 C) enters the water column from below. The water temperature is set at 30 C, so it's well above the boiling point of ammonia that heat transfer into the ammonia phase would ensure the liquid ammonia is vaporized rather immediately, before subsequently dissolved into the surrounding water.

Instead, despite the relatively rapid temperature increase above the boiling point throughout the ammonia phase, almost no liquid ammonia turned into vapor (taken at t = 1.5s, snapshots from left to right: temperature, ammonia vapor, water fractions).

Could someone let me know what's missing here? Thanks in advance.

[Rob]

Staff are not permitted to open/download files so I can only work on information in posts and images. 

Assuming the mesh resolution is OK, how are you setting the phase change? 

[not.lah.enough]

 

The setting for the multiphase phase change is given below:

Note that the inlet velocity (from the protruding tube) where the liquid ammonia enters the water column is 5.2 m/s. Initial ammonia temperature is -33.4 C. Inlet diameter and distance between the water surface (top of the domain) and inlet tube are 0.2 m and 4 m, respectively.

Additional variables for force setup:

Surface tension NH3 liquid-NH3 vapor 0.021 N/m
Surface tension NH3 liquid-water 0.041 N/m
Surface tension NH3 vapor-water 0.072 N/m

 

[Rob]

The frequency constants don't look anything like default. Given the way the VOF model works, can you shift enough mass from ammonia liquid to vapour to form a coherent free surface? For phase change other than VERY fine meshes I always use Eulerian. 

[not.lah.enough]

 

Regarding the frequency constants, I decided to estimate the value (based on the formulae in the Theory Manual) since they aren’t available in the literature as the inverse second unit. So about the evaporation constant, did you imply I have to increase the evaporation frequency (like, into the magnitudes of millions or above)?

I will try to switch to the Eulerian model (it gotta take quite a long time due to the three-phase case) and keep you updated as soon as I get any meaningful results.

 

Edit: Just did yet another VOF run with an evaporation frequency rate of 40 million s-1, still no evaporation occurred. 

 

[not.lah.enough]

Just did the Eulerian simulation, and the result gets even weirder. Still no vapor formed even when the evaporation frequency increased to 4 million s-1 even though the temperature around the inlet (note that this is water phase temperature) increased to whooping 1500 K (I stopped the simulation when this happened, at physical time of around 0.1s. Perhaps I still missed something here?

Here’s the multiphase setting for the Eulerian simulation:

Inlet boundary condition:

Initialization setting:

Note that I added an initialization patch at the region just above the inlet (which the simulation immediately crashed without), which entails vertical (z-direction) velocity of liquid ammonia.

 

Edit: The evaporation didn’t also occur regardless of the evaporation frequency input (I tried all the way to outrageously high values like 4e+11 s-1). I guess for some reasons (maybe in three-phase or more cases) the evaporation transfer is inadvertently turned off, no?

 

 

 

 

 

 

[Rob]

Please can you post an image of the mesh around the inlet? The diverging contour suggests you may need to do some refinement. 

[not.lah.enough]

Ouch!! It seems you’re right. The cell size in the refined region (along the expected region passed by the ammonia column) was set at 0.05 m. I’ll try to refine the near-inlet region and get back to you soon.

 

Edit: Increased the resolution at the expected ammonia liquid path (including the inlet region) to 0.015 m. Still almost no evaporation observed.

 

 

[Rob]

Have a look at adaption in the Fluent solver. That may avoid the need to remesh. 

[not.lah.enough]

Pardon, did you mean Adaptive Mesh?

[Rob]

Yes, we can refine a mesh in Fluent using adaption. It's usually done to catch unexpected or moving details (shock waves or free surface) but can also be used to refine a mesh where it wasn't sufficient in the first place. Adaption is often less efficient computationally, but is much quicker. 

[not.lah.enough]

Unlike previous versions, the setting for the adaptive mesh is much less straightforward in v2022R2- the option for VOF predefined criteria somehow can’t be chosen. Did I miss something?

 

 

[Rob]

No, but here you want to adapt by region to start with. 

[not.lah.enough]

Anyway, I decreased the inlet velocity (thus flow rate as well) to 0.104 (2% of the original case, so basically almost to a trickle) to supposedly give more time for the liquid ammonia to vaporize. Still no vaporization was observed despite the temperature in the ammonia bubble way exceeding the evaporation temperature.

[Rob]

How does the mesh look? Did you patch a layer of liquid ammonia next to the inlet? 

[not.lah.enough]

Here’s the mesh near the inlet after refinement. Note I haven’t yet used adaptive mesh (somehow Fluent didn’t allow me to activate the VOF adaptive mesh, even if I switched back from Eulerian to VOF multiphase – is this a bug in the code?), but I refined only the near-inlet region just in case the adaptive mesh could be activated. 

Here’s the screenshot showing that VOF adaptive mesh somehow automatically turned off and became unselectable (unlike in previous versions). I think applying adaptive mesh could obviously decrease the total cell count and allow the use of smaller cell sizes (like well below 0.01 m) to capture the interphase phase change, so basically I’m stuck with this problem.  

 

 

 

 

 

 

 

[Rob]

Shouldn't be an issue, the preset criterion are based on the VOF model. It's possible switching models on/off has broken the set up, but I've not observed that before. 

Try running with what you have. The dynamic adaption is only really needed when the free surface moves, when it's fairly static it's more cpu efficient to run on a fixed mesh. 

[not.lah.enough]

Reverted back to 2D model to allow refinement at the center of the domain. Here’s the mesh structure around inlet, with size of 0.006 m.

 

The simulation worked well at first (I used small time step of 0.0001 and adaptive time step to speed up the calculation later on), which was sufficient for a while), until the vaporization stated to kick in. As soon as some vapor built up, the Courant number shot up to above 250 (perhaps due to sudden surge of vapor formation?), as well as the residuals, which resulted in the simulation to crash.

Is there any way to automatically decrease the time step as soon as the solver detects such sudden changes (so I don't need to stick to something like fixed very small time step, which may take a very long computational time), or any other workaround in this case?

 

 

 

[Rob]

There's adaptive time stepping, but that may be too slow to react to very rapid changes. It's probably safer to up to 0.11s with a fixed step, save and then continue with a smaller time step. Autosave is a very useful feature too.  However, getting to 0.1s in 800 iterations may mean you need a smaller timestep to begin with. 

[not.lah.enough]

 

Sorry for getting back so late (been busy with my other projects). Thankfully, I resolved and finished the laminar case above (halving the domain also helped speed up the calculation) with rather reasonable time step size and smaller cell size along the ammonia’s expected path.

Now that I’ve changed the turbulence setting because the gushing fluid itself is turbulent and later on I will introduce current in the water column. However, it turns out to be much harder to avoid divergence, especially after the vaporization occurs till some time. The turbulence viscosity seems to be the source of the instability, perhaps due to the starkly different time scale between occurring phenomena – ammonia vaporization and vapor ammonia dissolution to water are much faster than let’s say dissolution of liquid ammonia to water. Or maybe compounded by the very different values of viscosity of the three phases as well.

Tried to decrease under-relaxation factor of turbulent viscosity (and later momentum and turbulent kinetic energy and dissipation rate) to lower value, down to 0.3, yet it just prolong the simulation somewhat and it still crashed well before the simulation run supposedly completed.

The multiphase, viscous settings, as well as the monitored vapor VOF values and residuals are seen below.

Note I decreased the URF values to lower than shown below, but still with no avail.

 

[Rob]

You can increase the TI limiter, it's there for a stability control but can be a little low in some instances. Are you hitting the limits all the time, or just at divergence? 

UR factors don't tend to help much in transient cases. One of the older text books even suggests setting them all to one: I've never done that. Instead it's generally recommended to decrease the time step. Which turbulent multiphase option are you using?

[not.lah.enough]

You can increase the TI limiter, it's there for stability control but can be a little low in some instances. Are you hitting the limits all the time, or just at divergence? 

It only hit the limit only just before the divergence. Noted, I will try to increase the limit and will let you know later.

 

... Instead it's generally recommended to decrease the time step. Which turbulent multiphase option are you using?

I decreased the time step to 1.0x10-6 and it was still quite unstable. Note I haven't increased the TI limit just yet.

The turbulent setting I used (as seen in the 1st screenshot) was k-epsilon RNG, with default values.

[Rob]

RNG should be fine, and is usually very stable. 

If you're hitting the limits immediately before divergence then it's the solution that's failing, not the solver, so limits shouldn't help much.

If you calculate how long it takes the flow to pass through a cell how does that compare to the time step? 1e-6s isn't that big a timestep in some models: it's mesh and solution dependent. 

[not.lah.enough]

If you calculate how long it takes the flow to pass through a cell how does that compare to the time step? 1e-6s isn't that big a timestep in some models: it's mesh and solution dependent. 

Exactly my concern too, since 1e-6 s is supposedly short enough anywhere in the domain to capture the transport phenomena. The time to take the fluid (both liquid and vapor) to pass the cells is between around 1e-4 to 1e-2 second, depending on the location in the domain (non-uniform cell size, rather widely different velocity as well).

[Rob]

Have a look at the flow a few time steps before divergence. Are you getting a sudden jump in vapour fraction? 

[not.lah.enough]

Yup, big big time - I tracked the volume average vapor fraction in the domain. That's why the Courant number and continuity residual (as well as k) jumps to extremely high number just before the divergence.

[Rob]

Is it expected? When you change phase the volume has to go somewhere, so you may find you need to reduce the time step for a period until the vapour pocket stabilises. 

[not.lah.enough]

I think the spike is expected as long as it's still under control (not diverging with unreasonable Courant number as shown).

Another problem is that the vapor pockets tend to exist in a very short time (around 0.01 s or less), thus it doesn't have time to stabilize (see the screencap below). Which is kinda expected due to the very high solubility of formed vapor ammonia in water compared to the liquid ammonia in water (like 1000 times as high).

 

[Rob]

Yes, and if you have several competing rate dependent steps the flow time step needs to capture all of it. Which may well explain the stability issues. 

[not.lah.enough]

Just want to follow up the previous progress. I ended up making a new simulation with much smaller dimension (in centimeter scale) to see and confirm the vaporization, as well to know how small the mesh size can be to capture the vapor buildup (essentially a bit like mesh independence analysis). I used VOF for this purpose because I expect the mesh size must be small enough (like 0.1 mm or below). Afterwards, I will apply the largest mesh size possible that reaches the mesh independency in selected regions where vaporization is expected to occur in the larger (meter scale) domain.

I used the same setting as previous simulation, but unexpectedly the initialization gave warning of "Negative Latent Heat Input Detected". Predictably, the simulation diverged almost soon after the calculation initiated. Never encountered this error before, and the previous simulation with very similar setting (down to the multiphase and properties, etc) never gave me the warning. Any workaround to solve this problem (I suppose this is a bug)?

[Rob]

Negative latent heat tends to mean you've got the phase order wrong in the multiphase panel. Fluent doesn't know the difference between a gas & liquid so relies on you setting the "from" and "to" phase correctly - switch them round and that error ought to go away. It's a setting I always have to check as whilst it's a 50-50 chance I nearly always get it wrong.....