Messages

121

Fluent / Re: Convergence of FLUENT calculations involving combustion and radiation

« on: February 13, 2012, 08:52:54 PM »

Steady state calculations are independent of the initial condition specified. However, the use of combustion and/or radiation models introduces significant nonlinearities in the transport equations and a poor initial condition may even cause divergence of the solution. To enhance solver robustness and stability and decrease overall solution turnaround times, here is a suggested solution procedure:

To start with, run the calculation with only the flow equations turned on (cold flow solution) for about 100 iterations or so until the solution shows reasonable convergence. In this step, use the "Solution Controls" GUI panel (Solve->Controls->Solution...) to activate or deactivate equations.

Next, activate the calculation of the energy equation as well as the species equations (or the PDF equation if you are using the PDF combustion model).

122

Fluent / Re: Error: > (greater-than): invalid argument [2]: wrong type [not a number]

« on: February 12, 2012, 12:37:08 PM »

This error occurs when FLUENT gets information from the Cortex (GUI). FLUENT is expecting to get the data in a specific format, but gets another. This generally occurs when FLUENT attempts to read a case file from a LATER (or very OLD) version of FLUENT. Typically, data structures are backward compatible, but only for the most recent version.

It is a good idea to update your cases every time FLUENT is released to avoid the problem associated with this type of software divergence.

If you have a very old case, such as a FLUENT 6.0 case, you may be able sequentially update the cases, but you will need all versions of Fluent (6.1, 6.2, 6.3) on your operating system.

123

Fluent / Re: How do I measure the time it takes to iterate in Fluent?

« on: February 12, 2012, 12:33:25 PM »

If you are running the parallel version of the code, you can use the
Parallel->Timer feature.

Note: You can run the parallel version of the code on only one processor to use this functionality to measure fluent operating on one computer node. There is additional overhead though using the parallel version in this fashion, and the results will not be exactly the same as the method mentioned below.

For the serial solver, you can measure the time spent iterating in Fluent through the use of the scheme file (appended)
(After downloading, please rename the file: benchmark.scm)


Use the Graphical User Interface to load the file, benchmark.scm.
File->Read->Scheme

After the case is set up and ready to run, enter this command to start and time the iterations in the Text User Interface. Please pay close attention to the syntax and replace the string NO_OF_ITERATIONS with the desired number of iterations to be performed:

(benchmark '(iterate NO_OF_ITERATIONS))

example to run for 10 iterations:

(benchmark '(iterate 10))

The results will be of the form:

cpu-time: cortex=0.04, solver=0.3
elapsed-time: 0.51880407

This shows the elapsed, wall clock time for the iterations and the cpu-time used in the solver and cortex. The cortex is the process controlling the solver and user interface.

Scheme File :

;;;save this as benchmark.scm
;;; Copyright 1991-1994 Fluent Inc.
;;; All Rights Reserved.
;;;
;;; This is unpublished proprietary source code of Fluent Inc.
;;; It is protected by U.S. copyright law as an unpublished work
;;; and is furnished pursuant to a written license agreement. It
;;; is considered by Fluent to be confidential and may not be
;;; used, copied, or disclosed to others except in accordance with
;;; the terms and conditions of the afore mentioned agreement.
;;
;; Reports CPU times of Cortex and solver processes for specified function.
;; Example: (benchmark '(iterate 50))

(define (benchmark thunk)
(let ((t0/cortex)
(t0/solver)
(t0/clock)
(t1/cortex)
(t1/solver)
(t1/clock)
(result))
(set! t0/clock (time))
(set! t0/solver (cx-send '(cpu-time)))
(set! t0/cortex (cpu-time))
(set! result (eval thunk user-initial-environment))
(set! t1/cortex (cpu-time))
(set! t1/solver (cx-send '(cpu-time)))
(set! t1/clock (time))
(format "cpu-time: cortex=~a, solver=~a~%elapsed-time: ~a~%"
(- t1/cortex t0/cortex)
(- t1/solver t0/solver)
(- t1/clock t0/clock))
result))

124

Fluent / Re: How to calculate heat transfer rate within UDF?

« on: February 12, 2012, 12:26:21 PM »

Use the following macros

1. BOUNDARY_HEAT_FLUX(f,tf) to obtain the total heat transfer rate
2. BOUNDARY_RAD_HEAT_FLUX(f,tf) to obtain the radiation heat transfer rate
3. F_DO_QA(f,t,nb) to obtain the absorbed radiation flux when using the DO model

Note that "FLUX" in the macro is a mis-nomer and it gives the total heat transfer rates in watts and NOT the heat flux in watts/m2.

C_ABS_COEFF(c,t) gives you the absorption coefficcient at a cell. This is not the same as the absorbed radiaiton flux at the wall.

125

Fluent / Re: How to identify cells at the interface for heat and mass transfer in VOF Fluent?

« on: February 11, 2012, 01:57:53 PM »

While modeling heterogeneous mass and heat transfer using the VOF model, it is often required to define a mass transfer coefficient only in cells that contain the interface.
For a simple two phase model, it is easy to locate cells on the interface by looking at the phase fraction value. The phase fraction will be either zero or one inside the individual phases but will have intermediate values in cells on interface

Hence, the DEFINE_MASS_TRANSFER udf macro can use a test like the following to locate cells that contain the interface:

vof_cutoff = 0.05;
if ( (C_VOF(c,t) > vof_cutoff ) && (C_VOF(c,t) < (1 - vof_cutoff) )
{ < cell is on the interface> }
else
{ < cell is inside a phase> }

The DEFINE_MASS_TRANSFER macro is described in the UDF Manual:

http://hpce.iitm.ac.in/website/Manuals/Fluent_6.3/fluent6.3/help/html/udf/node57.htm

126

Fluent / Re: Droplet breakup model for steady dpm tracking

« on: February 11, 2012, 01:33:15 PM »

Although steady DPM tracking is more computationally efficient than unsteady tracking, there are certain limitations. One of those limitations is that the spray models for breakup are not available for steady tracking. To incorporate droplet breakup into their models while maintianing the computational efficiency afforded by steady tracking, some users have turned to implementing breakup models using UDFs. However, care must be taken to ensure that this is done properly.

The provided udf permits the droplets to breakup one time when they cross the x=0.1 m plane, and the breakup results in two equally sized daughter droplets. These aspects can of course be modified, but it is important that P_DIAM(p) and P_MASS(p) are specified correctly. P_MASS0(p) must also be included if 2-way coupling is enabled in the discrete phase model.

NOTE: This steady breakup udf works for FLUENT 6.3.31 and later versions.


/* breakup udf for steady tracking
/*
/* this example breaks up the droplets one time when they
/* cross the x = 0.1 m plane.
/*
/* one dpm scalar is required
/*
/* NOTE: This steady breakup template works for FLUENT 6.3.31 and later versions. */


#include "udf.h"

#define BREAKUP_SMALL 1e-8

void assign_init_mass_to_tp_and_p(Tracked_Particle *tp, real mass_factor)
{
#if RP_NODE
Injection *I = tp->injection;
Particle *p = NULL;
#endif

P_INIT_MASS(tp) *= mass_factor;

#if RP_NODE
if (dpm_par.unsteady_tracking)
return;

loop(p, I->p)
if (p->part_id == tp->part_id)
P_INIT_MASS(p) *= mass_factor;
#endif
}

DEFINE_DPM_SCALAR_UPDATE(steady_breakup,c,t,initialize,p)
{
real mass_factor = 0.5; /* drop breaks in half */

if (dpm_par.unsteady_tracking)
return;

if (initialize)
{
p->user[0] = 0.;
}
else
{
if ((p->user[0] < BREAKUP_SMALL) && (P_POS(p)[0] > 0.1))
{
P_DIAM(p) /= pow( 1/mass_factor, 0.33333 ); /* assume droplets break in half */
P_MASS(p) *= mass_factor;
P_MASS0(p) *= mass_factor; /* necessary if 'interaction with continuous phase' is enabled */
p->user[0] = 1.;
assign_init_mass_to_tp_and_p(p,mass_factor);
}
}
}

127

Fluent / Re: Error: Divergence detected in AMG solver: x-momentum

« on: February 11, 2012, 01:13:47 PM »

One reason could be that the geometry is not correct. Do a Mesh->Check to make sure you don't get

Checking for nodes that lie below the x-axis.
WARNING: Invalid axisymmetric mesh: 6 nodes lie below the x-axis.

and
WARNING: Mesh check failed.


For axisymmetric, the axial direction should be x and radial is positive y. Even if the y starts with -1e-32, it will fail.

To fix this:
Use Mesh->Translate and move the geometry so ymin is +ve.

128

Fluent / Re: How can I compute gradient of VOF simulation

« on: February 08, 2012, 10:19:17 AM »

You can use UDF for this purpose, see below:

/*************************************************************************
UDF used to calculate gradient for post-processing

User defined scaler (UDS) and user defined memory (UDM) are used.
For any UDS, fluent will automatically calculate the gradient. So,
We need to pass the variable to UDS, and fluent will caculate the
gradient for you. UDM is used to save the results.

Steps to take to make it work
1. Read in the converged case and data
2. Link the udf (Define->User Defined->Functions->Intepreted)
3. Hook adjust funtion (Define->User Defined->Function Hooks->Adjust Function)
4. Define UDM (Define->User Defined->Memory 1)
5. Define UDS (Define->User Defined->Scalars 1)
6. Turn off all equations (Solve->Controls->Solution)
7. Do one iterations
8. Execute store_gradient (Define->User Defined->Execute On Demand)

**************************************************************************/


# include "udf.h"
# define domain_ID 2

DEFINE_ADJUST(adjust_gradient, domain)
{
Thread *t;
cell_t c;
face_t f;

domain = Get_Domain(domain_ID);

/* Fill UDS with the variable. */
thread_loop_c (t,domain)
{
begin_c_loop (c,t)
{
C_UDSI(c,t,0) = C_VOF(c,t);
}
end_c_loop (c,t)
}

thread_loop_f (t,domain)
{
if (THREAD_STORAGE(t,SV_UDS_I(0))!=NULL)
begin_f_loop (f,t)
{
F_UDSI(f,t,0) = F_VOF(f,t);
}
end_f_loop (f,t)
}

}

DEFINE_ON_DEMAND(store_gradient)
{
Domain *domain;
cell_t c;
Thread *t;

domain=Get_Domain(1);

/* Fill the UDM with magnitude of gradient. */
thread_loop_c (t,domain)
{
begin_c_loop (c,t)
{
C_UDMI(c,t,0) = NV_MAG(C_UDSI_G(c,t,0));
}
end_c_loop (c,t)
}
}

129

Fluent / Re: VOF simulation diverges, error message Global courant number is greater than 250

« on: February 08, 2012, 10:12:18 AM »

If volume mesh contains tetrahedral elements, use double precision with node based gradient option (Spatial Discretization). Create uniform mesh. In regions where the mesh is refined, ensure that there is a gradual transition to the coarser mesh. Avoid sudden changes in cell size. The maximum skewness of the volume mesh should be less than 0.95 and maximum aspect ratio of tetrahedral cells should be less than 5. In compressible phase calculations, use of non-conformal interfaces can leads to solution instability and divergence. We should not use non-conformal interfaces in the region of liquid-air interfaces. This is one limitation of VOF with compressible calculations. This limitation becomes magnified when you use MDM with VOF (both are explicit schemes)

Phase: Use compressible phase as primary phase.

Viscous model: Check the Reynolds number and use Turbulence model if needed.

Specified Operating density: Switch on the specified operating density and specify the density of lightest phase.

Implicit body force: Turn on

P-V Coupling: Use SIMPLE for compressible calculation and PISO for incompressible.

URF: Use small values. Pressure-0.2, Density-0.5, Body forces-0.5 Momentum- 0.3, Turbulent kinetic energy- 0.8, Turbulent dissipation rate - 0.8, Turbulent viscosity - 1

Use this command for better patching: (rpsetvar `patch/vof ? #t)

If you face the divergence at the beginning of the simulation, start the simulation with very small time step size, and increase after a few time steps if Global courant number is under control. The global courant number is printed in the Fluent console window at every time step.

The Global courant number depends on the mesh size, velocity field, and the time step size used for the transport equations. If CFL exceeds 2 and keeps on increasing, that means your velocity field is increasing or/and the interface is moving through dense cells, and the time step size used is too high. You need to reduce the time step size to bring the Global courant number under control.

For VOF calculations (using the Explicit scheme), FLUENT allows you to use variable time stepping in order to automatically change the time-step when an interface is moving through dense cells or if the interface velocity is high. If there are frequent velocity jumps in your problem, it is better to use the variable time stepping method to control the CFL under limit. The solution will be stable with the variable time stepping method.

If you use the fixed time step, the CFL may exceed the value 2 whenever there is a velocity jump or when the interface is moving through dense cells, and your results will be time step size dependent. If you continue with the same time step size, the results will not be accurate, and this may even lead to divergence. It is better to use variable time stepping method for this type of problems and for compressible VOF calculations.
Variable time stepping method: Here the input will be CFL. The global courant number is constant and the time step size varies with the velocity field. You should give appropriate value for Global courant number (CFL). Because, the time step size for transport equations are calculated from this CFL. You need to specify the Global courant number, minimum time step size, maximum time step size, minimum step change factor and maximum step change factor.

Global courant number: The default value of the Global Courant number is 2, but smaller value may be required for more accurate solution and more stable numerical calculation. In some cases, you need to reduce this up to 0.5 for accurate results. This is because the time step size (so, the CFL) should be small enough to get the accurate results. In some cases you may use CFL greater than 2 depending on the problem.

Maximum Time step size: minimum grid size / maximum velocity in the domain

Minimum Time step size: It should be greater than 1e-10. You cannot use time step size less than 1e-10. This is the limitation of VOF Explicit scheme.

Minimum step change factor: The default value is 0.5.

Maximum step change factor: The default value is 5. It is better to reduce this value to 1.5-2 to avoid the sudden increase in time step size.

If still there is a divergence, check your mesh quality, boundary conditions and physics of the problem.

130

Fluent / Re: How can I remove a particle from a domain using UDF?

« on: February 06, 2012, 06:48:13 PM »

To remove a particles, you need t use the following DPM macro:

p->stream_index = -1;

This command works for all particle types.
The mass and energy of the particle also gets lost along with the particle.

131

Fluent / Re: Conjugate heat transfer problem in Fluent 12. Energy residuals are high.

« on: February 06, 2012, 06:36:03 PM »

Possible causes could be:
=========
1. Poor mesh quality: high size change, and/or high skewness, and/or coarse mesh
2. high jump in thermal conductivity
3. invalid boundary conditions
4. improper mesh scaling

To resolve this you need to:
=========
1. make sure mesh is scaled properly. Go to Mesh --> Scale

2. double-check model setup and boundary conditions

3. reduce explict-relaxation, using the following 3 lines:

(rpsetvar 'temperature/explicit-relax? #f)
(rpsetvar 'explicit-relaxation? #t)
(rpsetvar 'temperature/explicit-relax 0.1)

By default, explicit-relax is set to 1.0.

4. Keep implicit underrelaxation to 1.0, by using the following line:

(rpsetvar 'temperature/relax 1)

It can also be set in the GUI.

5. Use alternative wall formulation, which can be activated using the folloiwng TUI command:

/solve set expert , yes , , ,

6. Ignore secondary gradient on all the cells, but shell conduction walls (if you have them), by using the following rpvar:

(rpsetvar 'temperature/secondary-gradient? #f)

By default, this is #t (true). To obtain the value, type:

(rpgetvar 'temperature/secondary-gradient?)

which will return either #t or #f.

Warning: This may bring some measureable inaccuracy, depending on how skewed the cells are at the wall and how high is the magnitude of the wall heat flux.

7. If you have turned on shell conduction in any of the walls, ignore secondary gradient in shell conduction zones only using the following command:

(rpsetvar 'temperature/shell-secondary-gradient? #f)

This does not cause measurable inaccuracy.

132

Fluent / Re: I am getting unrealistic temperature and velocities for DPM particles.

« on: February 06, 2012, 06:30:39 PM »

If you set the update DPM and continuous phase source terms to update with every iteration then it is likely to happen. To compute the effect of the heat and mass transfer from the DPM particles to the continuous phase you need to do few more continuous phase iteration before the next DPM iteration. When the number of continuous phase iterations are increased to 10 or 20, the solution should be improved to get the acceptable temperature and velocity values for the particles.

Also please note that the particle diameter should be less than the minimum grid length scale.

133

Fluent / Re: How can I record the DPM particles for individual size groups?

« on: February 06, 2012, 06:20:47 PM »

You can record particles for individual size groups using the following way:

Display - > particle tracks
Report type - > Step by step
Report to file
Color by Particle variable (Particle Diameter)

This will write the particle tracking history in a file. The last column gives the particle diameter. From this you can find out the number of particles in a size group. In this way you can find out the particles in a density/mass/temperature etc. group by selecting the variables in the Color By

See below for details:

http://www.aeromech.usyd.edu.au/AMME4210/documents/manuals/fluent_help/html/ug/node765.htm

134

Meshing / How to make sure that mesh is of good quality for FLUENT simulation

« on: February 04, 2012, 09:11:56 PM »

For a good quality mesh, skweness, aspect ratio, and the size change value should be under limit. Aspect ratio and the skewness represent the quality of a single cell, where as the size change represents the ratio of the size of a cell to its neighboring cell.

By definition,
0<Skewness<1
Size change > 0 .
Aspect Ratio >1

For good quality mesh, the skewness must be less than 0.85 (<0.9 is average, >0.95 is poor). There is no limit for the aspect ratio and the size range. However, it is better to limit these two <10. Depending on the problem, region of interest, accuracy of the solution, etc, the limit varies.
Skewness is defined as the difference between the shape of the cell and the shape of an equilateral cell of equivalent volume.

The Size Change specification represents the maximum ratio of the area (for 2-D elements) or volume (for 3-D elements) of an element rela¬tive to its neighboring elements. To calculate the Size Change value for any ele¬ment i, GAMBIT first computes the individual ratios of its area or volume relative to each of its neighboring elements.

By definition, size change > 0 . Size change value 1 represents an element that is surrounded by elements the areas or volumes of which are exactly equal to its own.

The "aspect ratio" is a measure of the stretching of a cell, and is defined as the ratio of the maximum distance between the cell centroid and face centroids to the minimum distance between the nodes of the cell

135

Fluent / Re: UDF to export Discrete Phase Model (DPM) particle properties to a file

« on: February 04, 2012, 08:41:39 PM »

Although FLUENT provides a method of sampling DPM particles as they pass through planes and outlets, there is no simple way to export particle data for all of the particles in the domain. This is especially difficult when running FLUENT in parallel since the particles are located on different compute nodes.
The UDF below can be used to loop through all of the particle in the domain and write selected particle properties to a file. The example shows how to write the diameter, mass, and temperature of the particles, but any properties associated with the DPM particle structure can be exported.


/* dpm_sample.c */
/* */
/* Loop over all particles in domain */
/* */

#include "udf.h"

#define WRITE_FILE TRUE /* text file created if true */

DEFINE_ON_DEMAND(all_unsteady_particles)
{
Injection *I;
Injection *dpm_injections = Get_dpm_injections();
Particle *p;
int counter = 0;
#if WRITE_FILE
FILE *fyle;

fyle = par_fopen("parcels.out","a",1,1);

par_fprintf_head(fyle," DIAMETER MASS TEMPERATURE \n");
#endif /* WRITE_FILE */

loop(I,dpm_injections)
{
loop(p,I->p)
{
counter++;

#if WRITE_FILE
/* data to be written to file goes here */
#if PARALLEL
par_fprintf(fyle,"%d, %e %e %e \n",I->try_id,P_DIAM(p),P_MASS(p),P_T(p));
#else
par_fprintf(fyle,"%e %e %e \n",P_DIAM(p),P_MASS(p),P_T(p));
#endif /* PARALLEL */
#endif /* WRITE_FILE */
}
}

#if WRITE_FILE
par_fclose(fyle);
#endif

counter = PRF_GRSUM1(counter);

Message0("There are %d dpm parcels in the domain. \n",counter);
}