[Zvex]

Hello,

I am not sure if it is not implemented already, but I haven't found any straight possibility to fully customly choose cell center coordinates for calculations. Maybe I am wrong?

If they are calculated during preprocessing once, and then are used for ALL calculations as a part of mesh - then it looks simple, just change it as a part of preprocessing. But do I need to calculate face centers aswell or it has nothing to do with cell centers for calculations?

If they are calculated dynamically as a part of scheme implementation, where should I look for it? I saw somewhere in sourcecode somesort of cell center giving function: it looked complicated, as splitting volume into pyramids and then averaging its weighted centers, but, I guess, it has nothing to do with the centers, that are used for calculations, since in comments it was told that it is deprecated. Maybe i should change scheme realization algorithm, but all my tryings to clarify the place, at which that code intervention should be made, failed, so I don't know where to start yet, any hints to do that would be awesome ...

I really need it, because i've constructed a mesh with triangle prisms, with acute triangles - so using Voronoy points as cell centers would solve problems with errors because of non-orthogonality.

So forcing OpenFOAM to use my custom cell centers in ALL calculations - is it possible? And at wich point of code should I implement that modification?

Thank you
regards,
Andrej

[marupio]

Cell centres are calculated and stored by the fvMesh object, and automatically used by the discretization schemes. If you want to force OpenFOAM to use your custom cell centres for some reason, it would be a pretty big job.

You may be able to get away with defining a new set of discretization schemes within the finiteVolume library, or you may have to create your own library finiteVolumeWithBizzareCellCentres.

Why do you want to use your own custom cell centres if OF already calculates them?

[Zvex]

we don't achieve a convergence of an order 1/N, where N is the number of volumes ... We have made a hand-made solver on pure c++, and achieve it by taking centers as Voronoy points.

So we need it, because we've constructed a mesh with triangle prisms, with acute triangles - so using Voronoy points as cell centers would solve problems with errors because of non-orthogonality.

"are calculated and stored by the fvMesh object" - is it done only once after reading a mesh?

As a see for now a syntaxis

mesh.C()[cell_index].x();

let's to access the cell center coordinate, there are two methods: returning it as a const, and just returning by reference. So the second one should let us to change it. But I am not sure if it will be enough and it will be calculating everything correctly

[marupio]

The cell centres are created when they are first requested (lazy evaluation). For a regular fvMesh, they are never recalculated. dynamicFvMesh must recalculate them, but I haven't looked at the code. I guess you could just create a copy of the finiteVolume library and change the cell centre calculation code, but, as you say, it may not be enough.

Will off-centre cell centres theoretically impact other parts of the code that just assume centroid locations? For instance, body forces would now also have a moment that are not accounted for. Would this also confuse non-orthogonality corrections and inverse distance calculations? Off the top of my head, I don't know.

[Zvex]

Originally Posted by marupio

The cell centres are created when they are first requested (lazy evaluation). For a regular fvMesh, they are never recalculated. dynamicFvMesh must recalculate them, but I haven't looked at the code. I guess you could just create a copy of the finiteVolume library and change the cell centre calculation code, but, as you say, it may not be enough.

Will off-centre cell centres theoretically impact other parts of the code that just assume centroid locations? For instance, body forces would now also have a moment that are not accounted for. Would this also confuse non-orthogonality corrections and inverse distance calculations? Off the top of my head, I don't know.

In our case there will be no non-orthogonality - that is the main reason for this thread ... there is no need for any corrections, if we use Voronoy points on acute triangles (prisms) mesh. There will be no incorrect distances, since the whole mesh is made of acute triangle prisms - Voronoy points will be always inside triangles.

I guess I'll just try to track the cell centers and check if they will change during calculations.

[marupio]

fvMesh will never let the cell centres change.

Also, the finiteVolume library is littered with non-orthogonality corrections. I'd suggest you copy and rename this library, modify the cell centre calculations, and go through all the discretization schemes, stripping non-orthogonality corrections. They're easy to spot... any discretization or interpolation that looks more complicated than the theory says, it's likely non-orthogonality correction doing it.

Then copy a solver, e.g. simpleFoam, and rename it, link it instead to your custom fv library.

[Zvex]

Originally Posted by marupio

fvMesh will never let the cell centres change.

Also, the finiteVolume library is littered with non-orthogonality corrections. I'd suggest you copy and rename this library, modify the cell centre calculations, and go through all the discretization schemes, stripping non-orthogonality corrections. They're easy to spot... any discretization or interpolation that looks more complicated than the theory says, it's likely non-orthogonality correction doing it.

Then copy a solver, e.g. simpleFoam, and rename it, link it instead to your custom fv library.

Thank's for tips, ill try to do somehting as soon as I will finish some other jobs

[Zvex]

I've just added a new method, that brakes encapsulation rules and allows to change centers. So all OpenFOAM functionality is kept, but inside my program I can add a second postrocessing after the mesh is read, just by reading center points from my file. It is a dirty solution, but very cheap, and easy to "turn on/off" original OpenFOAM functionality, so for our purposes this solution is pefect.

Results:
1) turning on/off any nonorthogonality corrections has zero effect on results
2) I've got the same convergence speed as in hand-made solver
3) Mesh centers are read from meshs tructure, and modifying it was enough. You were right, it is constant during calculations

Thank you for the tips again, my problems are solved .