Fluent6: Patch: Doesn't treat previous time step data fields! Tracer transport calculation irreproducible!


I'm doing unsteady tracer transport in a frozen flow field.
I patch the initial conditions and run the calculation. Sensible results.
I re-patch the same initial conditions and run the same calculation, get Nonsense results!
I investigated thoroughly and found that the Patch functionality in Fluent6 (6.0.20) doesn't reset the data fields for the previous time step (and that before -- the M1 and M2 fields). This has been reproduced on DEC alpha for both User Defined Scalars and Species mass fractions.

A workaround is to use a UDF to patch the data field for the previous time step data with the values that have been patched (using the Fluent GUI) into the data field for the current time step.
The following UDF performs this task for all User Defined Scalars and all Species mass fractions (depending on which of the two DEFINE_ON_DEMAND routines you use).
Run the UDF *after* you have patched the values you intend to start from.
NOTE: It may be necessary to repeat the procedure (patching AND running the UDF) after the first time step has been calculated, because the UDF will only treat data fields that have already been allocated in memory. It may happen that FLUENT only allocates data fields when the first iteration is calculated.
=============================================================================

#include "udf.h"

#ifdef STRUCT_REF
#define PRINT printf
#else
#define PRINT CX_Message
#endif


void
patch_unst(Svar sv, Svar sv_m1, Svar sv_m2)
{
Domain *d = Get_Domain(1);
Thread *t = NULL;

thread_loop_c(t, d)
{
cell_t c = -1;
if (NNULLP(THREAD_STORAGE(t, sv)))
{
if (NNULLP(THREAD_STORAGE(t, sv_m1)))
{
PRINT("Patching SV_M1 for SV %5d in Zone %5d.n",
sv, THREAD_ID(t));
begin_c_loop(c, t)
{
C_STORAGE_R(c,t,sv_m1) = C_STORAGE_R(c,t,sv);
}
end_c_loop(c, t)
}
if (NNULLP(THREAD_STORAGE(t, sv_m2)))
{
PRINT("Patching SV_M2 for SV %5d in Zone %5d.n",
sv, THREAD_ID(t));
begin_c_loop(c, t)
{
C_STORAGE_R(c,t,sv_m2) = C_STORAGE_R(c,t,sv);
}
end_c_loop(c, t)
}
}
}

thread_loop_f(t, d)
{
face_t f = -1;
if (NNULLP(THREAD_STORAGE(t, sv)))
{
if (NNULLP(THREAD_STORAGE(t, sv_m1)))
{
PRINT("Patching SV_M1 for SV %5d in Zone %5d.n",
sv, THREAD_ID(t));
begin_f_loop(f, t)
{
F_STORAGE_R(f,t,sv_m1) = F_STORAGE_R(f,t,sv);
}
end_f_loop(f, t)
}
if (NNULLP(THREAD_STORAGE(t, sv_m2)))
{
PRINT("Patching SV_M2 for SV %5d in Zone %5d.n",
sv, THREAD_ID(t));
begin_f_loop(f, t)
{
F_STORAGE_R(f,t,sv_m2) = F_STORAGE_R(f,t,sv);
}
end_f_loop(f, t)
}
}
}
}

DEFINE_ON_DEMAND(ondmd_uds_ptch_unst)
{
int s = -1;

for (s = 0; s < n_uds; s++)
{
patch_unst(SV_UDS_I(s), SV_UDSI_M1(s), SV_UDSI_M2(s));
}
}

#define SV_YI_M1(i)((Svar)(SV_Y_I(i)+SV_Y_0_M1-SV_Y_0))
#define SV_YI_M2(i)((Svar)(SV_Y_I(i)+SV_Y_0_M2-SV_Y_0))

DEFINE_ON_DEMAND(ondmd_spec_ptch_unst)
{
int s = -1;
int n_species = MIXTURE_NCOMPONENTS(mixture_material(Get_Domain(1)));

for (s = 0; s < n_species; s++)
{
patch_unst(SV_Y_I(s), SV_YI_M1(s), SV_YI_M2(s));
}
}

A new, much simpler workaround is now available for FLUENT 6.2, beginning with 6.2.11:
In FLUENT 6.2, if you type in...
(rpsetvar 'patch/m1-m2? #t)
...before you do a patch, the previous time step data will be patched to the same values as the current time step data, which fixes the problem reported here.

This has been introduced into the code at a time that precluded full production testing of all areas potentially affected. It is therefore OFF by default and needs to be enabled as described above. Please be prepared to see unexpected and unwanted behaviour when you use this on any application that differs significantly from the one this has been originally found in, and which is described in more detail in Clarify CR 15008.





Show Form
No comments yet. Be the first to add a comment!