fvSchemes: first and second order schemes

[TheodoreGalanos]

Hello everyone,

I have been having a few issues with our automatic generation of fvSchemes according to non-orthogonality of the mesh.

The problem is mostly related to the simple box simulations that I, and I can imagine a lot of users, have been performing. In some cases cell count was so low that snappyHexMesh doesn't even run. Despite that though, and despite the very low quality meshes created, max non-orthogonality would still come out extremely low since these meshes are indeed almost perfectly orthogonal (a lot like lego), only in such cases it is not a sign of quality. The automatic tool then assigns second order schemes to these cases which at least in some cases seem to make a lot of the test simulations diverge.

This functionality is better suited for 'final' stages of meshing, when the models have reached a certain level of quality and have a number of cells representative to their geometry details and scope. Then, non-orthogonality is indeed a more accurate measure of mesh quality and the component is useful.

I propose we add two options related to fvSchemes, aside from the updatefvScheme component: first-order and second-order schemes. These are again simply standard dictionary files. First order schemes can and should be used in the beginning of the simulation runs. They are faster, more robust, but also not accurate. Second order schemes can and should be used at the later part of the simulations to achieve the final solutions. They are slower, more accurate, and less robust.

Usually one would run a simulation with first order schemes for a few hundred iterations and then switch to second order schemes to achieve final solution. But the exact number of iterations differs from case to case. Therefore, a second good functionality would be to allow users to simply input a kind of ratio or multiplier for first order and second order schemes. That, in combination with the endTime given, is used to calculate the running time for both first and second order schemes. I will provide the fvScheme files tomorrow.

The second functionality I mentioned is already there in OF and we can accomplish it the same way during run-time. What we need to do is have both fvSchemes dictionaries in the /system folder and switch from one to the other by renaming one to the appropriate OF name and the other to a dummy name.

Let me know what you think of the above.

Kind regards,
Theodore.

[mostaphaRoudsari]

@TheodoreGalanos are you suggesting to create two separate workflows to updated fvSchemes?

If we're going to implement this we need to have a better workflow from inside GH. IMO renaming the files manually is not the best approach. We have to merge all of them in one place or propose two easy to distinguish workflows.

For instance we can calculate the number of mesh cells and if the number of mesh cells and if it's quite low then give a warning to the user for using orthogonality or something like that?

[TheodoreGalanos]

@mostaphaRoudsari

Hmm I see what you mean, merging all in one place does make a lot of sense development wise. What I had in mind, CFD wise, is to offer the user the chance to not only select (semi)manually the type of scheme but also change it during run-time since OF allows us that. The way OF does that, through a function object, is to change dictionary that is literally swap files. But if we can get BF to save all the changes at once we don't need multiple files.

Concerning the scheme option, how I imagined it is an input, different from fvSchemes which can still work for later meshing stages. This input takes two values: first order and second order. It would also be neat if the user could extract parameter and get a button connected that can switch from one to the other. What do you think?

As for the number of cells I am really not sure how to make that work. Meshing is very tricky and extremely case sensitive, hard to find a rule of thumb. By providing this versatility we at least give the user a chance to select a different scheme if he/she runs into divergence problems with the automatic method of updatefvSchemes.

Hope this makes sense.

Kind regards,
Theodore.

[mostaphaRoudsari]

@TheodoreGalanos let's chat about this once you get a chance. I'm still not clear what would be the best solution to have this next to the component that we have already. Which one is going to overwrite which? and where do you see this component come into play?
I assume right before the solution. In that case, it will overwrite the changed made based on meshing and there is no easy way to go back.

[TheodoreGalanos]

@mostaphaRoudsari I think it's just an input on the recipe components, if that is where we now moved the run case inputs. This allows the user to change (on the fly) from first order to second order schemes. This change is not only based on mesh quality, which is what we originally introduced and as you can see really doesn't work across all cases, but also based on solution strategy from the user side (e.g. fast, robust first order schemes for first 200 iterations - slow, more accurate second order schemes for the rest).

It shouldn't influence meshing or overwrite anything on the polyMesh folder. It will only change smth within fvSchemes file. Let me know what you think. Also, let me know when you want to discuss things again.

Kind regards,
Theodore.

[mostaphaRoudsari]

@TheodoreGalanos thanks. I understand that it only changes the fvscheme but here is the problem (at least in my opinion):
Imagine a case in which the user uses the other component update fvSchemes based on orthogonality. Then if s/he applies the first and second order schemes during the run it will overwrite the updated values and there is no way back. My question is how would you merge these inputs with the ones based on meshing? At the minimum, we should have a workflow to let the user switch between the two methods (mesh-based vs first/second orders) while the analysis is running.

[mostaphaRoudsari]

Added! Check indoor example file.

[gamemakerh]

sorry. @mostaphaRoudsari I forgot to update my post. I've found this part from your other post eralier today. but still thank you for support.