Fixed Twall not working with T_modes

[KulaLAForU]

Dear all,

I found this weird difference between T_t and T_v in 2T model with hypersonic flow over sphere cases, especially when I used fix grid with no-slip condition andFixed T_wall, and I do check the source code it has some treatment to the T_v when setting it as a fixed T_wall.

Thank you for the help. Jianshu Wu

[uqngibbo]

Hi Jianshu,

I think this happens because a very dissociated flow has not many molecular species in it, which means the vibrational thermal conductivity k_v is very low. The problem should improve with increased grid resolution, or failing that, fixing the species on the wall to force some recombination.

Nick,

[KulaLAForU]

Thanks for your help, but sorry Nick I'm still don't get it, the T_wall is provided, shouldn't T_v in the boundary layer exhibit a similar increasing pattern as T_t? And I reruned the calculation with refined mesh and boundary layer, and fixed the species on the wall but still showing the strange T_v near the wall.

Jianshu

[uqngibbo]

Can you try adding "catalytic_type" = "fixed_composition" to your WallBC_NoSlip_FixedT?

[KulaLAForU]

I added that but still didn't see any changes. Could you please explain how to calculate data in the wall (like specific heat at const volume for vib-elec energy and K_v) by using ghost cells after setting Fixed T?

I tried to use my 3weeks beginner knowledge of D to print equations for each ghost cell in order to locate them, But I lost my clue after the line 'dest_cell.fs.copy_values_from(src_cell.fs);' at line 99 in 'extrapolate_copy.d'. I'd be extremely grateful for any help you could provide

[uqngibbo]

Hi Jianshu,

Unfortunately getting details out of the depths of the code can be hard. Can you tell me what radius and flow condition you are simulating? It might be easier if I just check it for you.

Also, can you perhaps try adding, in addition to the catalytic type and wall_massf_composition, the following two lines:

config.mass_diffusion_model = "ficks_first_law"
config.diffusion_coefficient_type = "binary_diffusion"

That should definitely fix the problem, albeit at the cost of introducing a catalytic boundary, which you might not want.

[KulaLAForU]

Thanks!! I'll try it now.

The radius is 6.35mm and flow conditon like these:

I've completed the K_eq calculation for Park's 2T model and added it into the source code with A1-A5 parameters, so it would be great if I could have the flexibility to choose the non-catalytic BC arbitrarily.

Have a good weekend Nick, thanks again Jianshu Wu

[KulaLAForU]

It's still not fix the problem.......

[uqngibbo]

Hi Jianshu,

I've tried replicating this problem and it looks like you just need more resolution. This screenshot shows the convergence of the T_modes with three different levels of wall clustering, resulting in a first cell height of 2e-6 (light blue), 0.19e-6 (blue), and 0.096e-6 (dark purple) meters.

Note that the T_modes is converging toward the expected behaviour, though it still doesn't reach the same level of convergence as the T.

That said, it's important to understand that the T_modes is being set to 293 K at the interface where the wall is. The visualisation you see in paraview is just the data in the cells, and even though the first cell isn't close to 293 K, that doesn't neccessarily mean that there is a problem, because the code is still using the gradient between the first cell and the wall to compute the heat transfer.

I'd recommend trying to run with tighter wall resolution. The geometric cluster function might be helpful for that:

f_radial = GeometricFunction:new{a=0.001, r=1.2, N=nj+1, reverse=true}
grid = StructuredGrid:new{
   psurface=psurf, niv=ni+1, njv=nj+1,
   cfList={north=cf_radial, south=cf_radial}
}

This cluster function starts with a cell that is 0.001 of the block edge length, the grows by a factor of 1.2 each step away from the wall. The N argument is just the number cells along the block edge you are clustering.

Let me know if you have any more questions. It seems like this is just a particularly difficult case to simulate, because your sphere is so small and the velocity so high.

[uqngibbo]

For reference, the a values I used were 0.001, 0.0001, and 0.00005 for those three simulations.

[KulaLAForU]

Thanks!! Now I have to go learn how to speed up the calculations, 0.00005 for my Mac will take days to finish the calculation.

[uqngibbo]

Okay best of luck.

[KulaLAForU]

Hi may I ask how to use the e4mpi? I refined the mesh and then it's : Step= 9680 t= 1.024e-06 dt= 1.994e-10 cfl=0.50 WC=5163.3 WCtFT=1067418.2 WCtMS=421555.1

So I wanna using MPI method to speed up the calculation but I followed the doc and example but :

[uqngibbo]

Hi Jianshu,

The MPI solver is invoked a little differently, instead of:

e4shared --job=JOBNAME --run --tindx-start=last

Use

mpirun -np 4 e4mpi --job=JOBNAME --run --tindx-start=last

Here I have assumed you have four cores on your machine, but you can change the -np argument to match your hardware.

[KulaLAForU]

Thanks, but: mpirun -np 4 e4mpi --job=lehr --run --tindx-start=last prterun was unable to find the specified executable file, and therefore did not launch the job. This error was first reported for process rank 0; it may have occurred for other processes as well.

NOTE: A common cause for this error is misspelling a prterun command line parameter option (remember that prterun interprets the first unrecognized command line token as the executable).

Node: DeaTh-NoTE-Studio Executable: e4mpi

[KulaLAForU]

It showes the 'e4mpi' command can not be found, I guess it may by something I didn't install well

[uqngibbo]

You might have to rebuild the code to get e4mpi made. Try

$ cd
$ cd gdtk/src/eilmer
$ make FLAVOUR=fast WITH_MPI=1 install

[KulaLAForU]

Thank you very much!

Have a good day!