[streamline90]

Dear Foamers,

I am currently working, for my master thesis dissertation, on a RANS simulation of a high speed train. In particular the focus of my analysis is on the pantograph, which is the component on the roof of the train whose main task is to collect current from the high voltage line.

Since I was extending the validity of a model proposed in the past by a colleague, I did the simulations with the same version of OF used by him ( OpenFOAM v2.3.0 ). Everything went good and I did get a good correspondence with the experimental results.

Unfortunately, the HPC ( high performance computing ) service which I used, decided to update the openFoam version to the latest one v1706. Since I have still to perform some simulations, which will be compared to the first one, I decided to re run the first simulation on the new version of openFoam.

With my great surprise, even by using the same exact scripts used in the previous version, all my aerodynamic forces are a bit different now and there is no correspondence with the experimental results anymore.

So the question now is: is it possible that changing only the OF version we get different results?

I am sorry if the question is not clear or you need more information to understand. In this case let me know and I will more than happy to provide further information.
I trust in your patience and kindness, there the risk I loose a valuable work for which I spent a lot of months with the hard to face consequence of further postponing my graduation.


Thanks a lot for your attention,

Luca

[alexeym]

Hi,

Answering your explicit question: yes, it is possible. Case can even converge [when run] with one version and diverge with another.

Guess, implicit part includes: "what shall I do to get the same results with another version?". For this it is necessary to learn more about your case: solver, schemes, convergence criteria, mesh quality.

[streamline90]

Hi alexeym ,

thanks for your reply. It may seem a stupid question, but how can the solution change when we use the same algorithm and convergence criteria? I've always used simpleFoam, but the two version converge to two different values... and we are not talking about small differences which could be due do a different initialization of the solution... I have also obtained a force of 20N instead of 30N obtained with the older openFoam version...

I ask you this question, because it's gonna be hard now to replicate the same result, as I've already done a convergence analysis and the solution seems to be not affected by an additional refinement of the mesh...

Thanks,

Luca

[Taataa]

As Alexeym said it's possible and for this reason I always compile OF on clusters myself and maintain it exactly the way I do on my own machine so I can always get the results that I want. Compilation shouldn't take more than 2 or 3 hours on a cluster.

[alexeym]

Hi all,

@streamline90

So, it seems you are in the mood to talk. OK.

Well, what if, algorithm slightly changed between 2.3.x and 5.x? Also at this point it becomes even more interesting, since we compare Foundation's 2.3.x and ESI's 1706. So in addition to 2.3.x -> 5.x evolution you have additions by ESI team (yet it seems particularly simpleFoam is not changed).

In addition, it is TVA, so velocities are relatively high, flow is turbulent. Turbulence library is COMPLETELY rewritten between 2.3.x and 5.x. And models with the same name can give different results depending on version.

Your mesh is completely orthogonal? What if non-orthogonal correction was changed in between versions? And more generally, what if implementation of certain schemes was changed between versions?

Just recently I had small issue: laminar pimpleFoam case converged fine on Foundation's 5.x and did not on ESI's 1706. And it turned out, that ESI's 1706 has issues with Crank-Nicolson scheme implementation, which lead to convergence problems. Though at a surface: the same algorithm, the same orthogonal mesh, the same scheme names.

Mesh convergence analysis is fine, when you know, that your schemes are really 1st or 2nd order. What if your schemes are 0-order (like Gauss linear on non-orthogonal meshes) and just give you wrong results on any mesh?

[Santiago]

Originally Posted by streamline90

Hi alexeym ,

thanks for your reply. It may seem a stupid question, but how can the solution change when we use the same algorithm and convergence criteria? I've always used simpleFoam, but the two version converge to two different values... and we are not talking about small differences which could be due do a different initialization of the solution... I have also obtained a force of 20N instead of 30N obtained with the older openFoam version...

I ask you this question, because it's gonna be hard now to replicate the same result, as I've already done a convergence analysis and the solution seems to be not affected by an additional refinement of the mesh...

Thanks,

Luca

Luca, in principle it shouldnt change. Like any other software, FOAM has bugs. One that has been widely, but quietly, known is the overdissipative character of ddtcorr in pisoFoam. Some details are given by Jasak in a presentation made in Portugal last year.

One that i remember was regarding the implementation of the dynamic smagorinsky model in OF2.1, made by Weller, which was implemented wrong.

My .02 cents are to stick with things that you have proven they work. I just recently migrated to foam-extend after working with v.2.1. Migrate only when deemed necessary.

[streamline90]

Hello guys,

thanks for sharing your thoughts on the subject, I really appreciate.

@alexeym
Your answer is really detailed and I am gonna check the schemes, hoping this is not taking me too much time.
It took me a lot to create a validated case, and since the graduation is in April and I still need to write down my dissertation I have to think about the best solution.

Maybe, as suggested by @Santiago, the best solution would be to stick with the case which has proven to be valid. The problem, in this case, would be that I couldn't proceed with my research, as further results cannot be compared.

If anyone has time to go through them, I attach below the setup files for the latest case submitted in OFv1706.

I am working on my own with OF since a year and as a mechanical engineer, I don't have such a wide background in fluid mechanics and CFD: feel free to warn me about even the stupidest of the errors and please be patient if I have done childish mistakes.
(there are also the log files of the meshing and solving process)

https://drive.google.com/open?id=1JY...btdGVl2MHf9miv

Thanks a lot and have a great day!

Luca

[alexeym]

@streamline90

Let me clarify one thing first: did you analyse your flow field or you have just compared output of forces/forceCoeffs function objects? What if in fact just description format of these function objects was changed?

Now to your files:

- Do you plan to view your files in text viewer? Otherwise it is not quite clear why would you like to write files in ASCII format. Also why precision is 7? Why not 12? Or 15? In fact your non-orthogonality can be caused by write precision.

- "Gauss linear" is OK only for orthogonal meshes. On non-orthogonal meshes (especially your 70 degrees of non-orthogonality) it has certain problems (you can search forum for references, also there is NASA paper: https://ntrs.nasa.gov/archive/nasa/c...0140011550.pdf).

[streamline90]

Originally Posted by alexeym

@streamline90

Let me clarify one thing first: did you analyse your flow field or you have just compared output of forces/forceCoeffs function objects? What if in fact just description format of these function objects was changed?

I extracted the output of the forces functionObject and saw the convergence value for each macrocomponent, since the focus of my dissertation is on the uplift force on the pantograph head ( which is computed with the virtual work principle, composing all the contributions of the aerodynamic forces acting on the moving components of the pantograph )

Originally Posted by alexeym

@streamline90

Now to your files:

- Do you plan to view your files in text viewer? Otherwise it is not quite clear why would you like to write files in ASCII format. Also why precision is 7? Why not 12? Or 15? In fact your non-orthogonality can be caused by write precision.

As a matter of fact I was told by my professor not to modify the original scripts made by a colleague who was working on the same topic before me. I inherited the files from him... do you suggest then to use a precision of 12 or 15?

Originally Posted by alexeym

@streamline90

- "Gauss linear" is OK only for orthogonal meshes. On non-orthogonal meshes (especially your 70 degrees of non-orthogonality) it has certain problems (you can search forum for references, also there is NASA paper: https://ntrs.nasa.gov/archive/nasa/c...0140011550.pdf).

Can I kindly ask you to modify the fvSchemes to show me how, according to you, is better?

[alexeym]

Originally Posted by streamline90

I extracted the output of the forces functionObject and saw the convergence value for each macrocomponent, since the focus of my dissertation is on the uplift force on the pantograph head ( which is computed with the virtual work principle, composing all the contributions of the aerodynamic forces acting on the moving components of the pantograph )

So, in fact, you have never compared flow directly. You only looked at post-processed values, and the problem could just be in slightly modified configuration of forces function object (or maybe there is a bug in the function object) and has nothing to do with algorithms and discretisation schemes. Neat.

As a matter of fact I was told by my professor not to modify the original scripts made by a colleague who was working on the same topic before me. I inherited the files from him... do you suggest then to use a precision of 12 or 15?

I would suggest binary instead of ascii, since it does not have possible rounding problems. Yet, it depends. If you plan to post-process data with in-house developed tools, which can only deal with ASCII output, then you have no choice. Set it to 12.

Can I kindly ask you to modify the fvSchemes to show me how, according to you, is better?

See attached files. In fact I have just changed gradient schemes to leastSquares and increased order of discretisation schemes for k and omega. If there is a problem with convergence, revert to upwind. In fvSolution I have increased number of non-orthogonal correction iterations.

[streamline90]

Dear alexeym,

thank you very much for your help and suggestions.
I'll try to run a modified case with the new dictionaries and I'll let you know about the results.
Thanks again and have a nice day.

Luca

[raptorishungry]

Hello Luca! I am having the exact issue. I validated my particle simulations with OpenFOAM 3.0.1, but the HPC system has v1706 and the deposition results are way off. Did changing the schemes fix it for you?

[streamline90]

Hello Adithya! In the end I didn't try to change the schemes since my HPC allows to recover previous versions of openFoam so I have been using OF v2.3.0 again.
I am sorry I can't help you, in case you see significant changes please let us know!
Have a great day,

Luca