[TAKEDA dql]

Dear everyone,
Is there anyone who know about the overlapping grid in CFX? For example, I want to simulate the flow around the circular cylinder. And I have generated the grid_1 of the cylinder, as shown in fig1. Now, I need to interpolate the flow quantities into an independent rectangular block of grid_2 in every time step so that I can just get the data in grid_2 to save my disk space. From the fig2, It can be noted that the the grid_2 is just an overlapping grid and have no connections with the grid_1.
So would you please tell me how can I set the .def in CFX_Pre to solve the problem? Many thanks!

[evcelica]

Why not slice it up so you have a mesh region that size at that location?

[AtoHM]

Yes, you should integrate your second mesh into the first one and use a mesh locator to extract desired values in this location.

[TAKEDA dql]

Originally Posted by evcelica

Why not slice it up so you have a mesh region that size at that location?

Dear evcelica,
Thanks for reply. Because the second mesh is not compatiable with the first one. And the mesh requested in that region need to be homogeneous. So I need to generate an new one.

[TAKEDA dql]

Originally Posted by AtoHM

Yes, you should integrate your second mesh into the first one and use a mesh locator to extract desired values in this location.

Dear AtoHM,
I think the suggestion that you proposes is really reasonable, but could you please tell me how to make this come true in CFX, or how to set the command in CFX-Pre and CFX-solve? Thanks anyway!

[Gert-Jan]

I think what you can do is:

1) run the calculation with mesh 1
2) Create a new def-file with mesh 2
3) interpolate the solution (.res-file) of mesh 1 on mesh 2 in a interpolation-only run. You can do this as follows:

1) Open the CFX-Launcher (You cannot find this in Workbench)
2) Go to Tools and open the command line
3) type cfx5interp

It will give an error since you need to give more information. Out of my head, the string should be something like:

cfx5interp -res mesh1.res -def mesh2.def

For mesh2.def this will give you an initial guess from mesh1.res. You can open this .def-file with initial guess in CFD-Post, which allows you to get the data you want (I think).

To find all options available for cfx5interp you can type: cfx5interp -help|more

Hope this alternative route helps, Gert-Jan

[AtoHM]

Excellent hint from Gert-Jan, I would go with that for the start. Mind that this will give you only an interpolation onto your mesh, which can be off when the mesh resolutions differ greatly.

With my suggestion, you would have to go back to meshing, this is not a task for Pre. Use whatever you used for meshing these regions, set up your model as you need it and use different mesh types/resolutions as you like. It should be possible to have some mesh locator or something else you can use in Pre to get output for. To clear that up, I did not do something similar before, but I am confident it can work somehow that way.

[Gert-Jan]

A challenge will be that the original question is regarding a transient case. My suggestion works for a single results file, but not for a transient one with a lot of -trn-files, since the interpolator does not work with these trn-files.

And the main driver is to save information on a smaller grid, which occupies less hard disk space....... Is that still the main driver? I think every workaround requires a lot of work with only limited hard disk savings, not?

For transient cases, normally you only save trn-files. If you:
1) do not save the mesh in these trn files;
2) only limit yourself to the most crucial variables (pressure and velocity);
3) do not save every timestep

then, wouldn't that be sufficient? If not, why not buy a larger HD. These are quite cheap.

[TAKEDA dql]

Originally Posted by Gert-Jan

A challenge will be that the original question is regarding a transient case. My suggestion works for a single results file, but not for a transient one with a lot of -trn-files, since the interpolator does not work with these trn-files.

And the main driver is to save information on a smaller grid, which occupies less hard disk space....... Is that still the main driver? I think every workaround requires a lot of work with only limited hard disk savings, not?

For transient cases, normally you only save trn-files. If you:
1) do not save the mesh in these trn files;
2) only limit yourself to the most crucial variables (pressure and velocity);
3) do not save every timestep

then, wouldn't that be sufficient? If not, why not buy a larger HD. These are quite cheap.

Dear Gert-Jan,
I'm glad to see your detailed and significant suggestion. Because the mesh 1 is too large(the grid points is about 14 million) to save in every time step. However, I really need the density field in the region of mesh 2 of every time step, which can be used for further calculation and turbulence statistic(time-averaged or r.m.s ). So if I can interpolate the results of mesh 1 onto mesh 2 during the calculation process and then just save trn-files of mesh 2, that will cost little! Unfortunately, I know little about the CEL of CFX, and don't know whether CFX has the function like that.

[Gert-Jan]

I don't think this is possible. Your solver is a parallel process that runs continously. The interpolator is a serial process that sets an existing results file on a new definition file as an initial guess. This is done before the solver starts. Meaning, both a completely different processes. The solver can't do the interpolation.

The only option I can think of is to only write density to a trn-file. And use the "lowest Speed Most Compression"-option. Or buy an additional HD.

Maybe you can ask ANSYS if there is a workaround which allows you to save trn-files of only the data in a specific domain/volume. Meaning, you should give the elements in the block of interest in Mesh 1 a name, and use this in Pre for the definiton of a new domain (maybe a sub domain is already sufficient). Then only save the data in this block/domain.

This option is not there. But you can always ask. Sometimes there is more possible then we all know.