Do not spend your time
The subject is somewhat impolite,
but some people who have same problem with me can understand.
First of all, Thanks for developers and sorry for the subject.
I spent almost 2 years to perform combustion simulation by OpenFOAM.
Engine, premixed flame and coal combustion furnace....etc
OpenFOAM combustion library can simulate few cases.
However, almost cases have a same error.
"Janaf thermo error"
Many users report this error for various cases
and try to solve this problem, but nobody can answer the solution for error.
At first, I think that
"It's a user's fault, OpenFOAM maybe OK for a GOOD mesh, small CFL, appropriate BCs and numerical schemes"
HOWEVER, It's NOT a user's fault.
This error always exist even though there are perfect mesh and setup.
JANAF is just a table. It just return specific heat value for a given temperature that comes from enthalpy equation.
I can't think other cause of this error except this.
"OpenFOAM combustion libraries are naturally instable."
OpenFOAM can be the best numerical analysis tool for a future, at present time, it's not.
Please, Do NOT spend your time to perform combustion using OpenFOAM
If you still want to doing, there is alternative chemistry library for OpenFOAM using cantera which is more stable according to original developer.
However, It only support OpenFOAM 1.5.x
I know nothing about combustion in OF, and I feel sorry for difficulties you have met, however every software have bugs/errors, especially OpenFOAM is not MS Word/Excel that is used/maintained by well paid programmers, it could be that if you spend some little time, you can solve that weird bug but it is not guaranteed, it might be a gamble for you if you want to decide whether to spend more time on this, but this is the nature of research, I think you are not using this for a project in your company, correct? Because compared to the population of users of Word/Excel, there are really too few users of OF.
I think you at least gave some information about the error from OF, may it be answered by someone else, and you also provided an alternative chem library.
I'm not expert of combustion, as a consequence I cannot comment on the specific topic.
However, you could provide a test case where you meet the problem, so others interested can check it and try to find what the actual cause of the problem is (probably of numerical origin).
I searched the forum and I didn't find any thread opened by you on this topic. You could attach a small example that causes the problem here, so to have a concrete case to discuss.
I know this Janaf error is really frustrating sometimes and they are unfortunately not that unusual. Most of the times I have experienced them it has been the out-of-range (both high and low) problem. Mostly I have been able to work around by isolating which cell that failed and find out why. Sometimes it's been inadequate BC's and sometimes I have found that using different discretization helps.
The janaf error problem was also one of the motivations behind the canteraChemistry effort. I did not use cantera with openfoam a lot, so I cannot comment on how useful it is in practical use.
If there is a bug it would be good to locate it, but instability does not always equal bugs, it can also be pure sensitivity (for instance to scalar overshooting). As Alberto suggests, it could be useful if you provided a test case which you never managed to solve, and the community could possibly provide some help.
I'm not an expert of combustion too ,but I think I was very familiar with the OpenFOAM lagrangian library ,thermoDynamicModel library ,and some other OpenFOAM library.
Firstly,according to my experience ,I beleve the lagrangian and thermodynamic library is not as good as other OpenFOAM libraries :the lagrangian library is overused of C++ ,the thermoDynamicModel library is overcomplexed 。In thermoDynamicModel ,there are so many *thermo ,such as hPsiMixtureThermo hPsiThermo ,why didnt the writer just write hPsiMixtureThermo and treat hPsiThermo as a one component hPsiMixtureThermo ?
secondly ,I think OpenFOAM is good at incompressible , ico thermo ,and dynamicMesh . snappyHexMesh has great parallel efficient .
thirdly ,I think OpenFOAM have more advantage than its lack .It is free, open source ,and have acceptable accuaracy,good paralle efficency ... and so on .
my english is bad ,sorry for that .
I am experiencing the same problems with janaf, using FireFoam. Even the tutorial originally provided by FM Global crashes because of the validity range of Janaf. Well, the mesh is simple and the case 2D which does not make sense in LES, but after spending months launching simulations, I get this error most of the time. Yes, tuning schemes and the mesh sometimes makes the computation converge but the sensibility to the parameters is very very high.
I must say OpenFoam is a fantastic code, I learnt so much about CFD thanks to its structure, but I lost hundreds hours because of this instability which sometimes made me nervous and desapointed so I understand karam's reaction. That would be really nice to do something for solving it. Unfortunately, I am changing of research topic but some people here will continue on it and I will try to underline the problem and hopefully something could be done in the future.
Anyway, thanks again to the developers for this work.
I really get annoyed with this kind of thing - did you guys ever wonder if you are doing the case setup right and WHY your temperature drops below 200K (this is minus 100 Celsius, which is pretty cold for combustion).
In ALL cases of this kind that I have ever seen, there has always been a problem either with the boundary conditions or discretisation settings. Further to that, why don't you ever consider dozens of publicly related cases which show excellent combustion results with OpenFOAM - see for example the IC engine work in Milan and dozens of other LES-combustion simulations. There is absolutely nothing wrong with the thermodynamics setup in OpenFOAM, but combustion is a difficult subject and the user needs to be sensible and careful in setting up a case.
If you are so desperate, why don't you apply to the Summer School next year and spend 2 weeks in Zagreb working through the cases you consider problematic - I am sure we will resolve every single issue in about 3 days.
I guess its diffusion.
Recently I set up a case that was a box, with half of it, full of N2 and half of it full of Ch4, and defined no reaction in the case. all the boundaries are wall, and the starting temperature is 300K. So only mass diffusion happens in this case ( and enthalpy diffusion due to mass diffusion), but when the case is started, I get the same error. Checking the results, shows that when the diffusion happens, the temperature is raised or dropped ( based on ch4 or N2 part). I want to know what causes this. Optimistically the code is right, so this diffusion could be the problem in my cases. Did anyone have the same problem before?
Can anybody tell me how to solve this?
Usually you encounter instabilities in thermo models at the beginning of the simulations or time step, or when some sudden change happens in the solution, which means when the solution is not converged yet.
A better setup of the case helps a lot, and probably the code could be improved adding some automated check to prevent this kind of instability (something has actually been done in compressible codes for example).
However, to understand what is going on in your case, you should publish an example that can reproduce the problem, so someone can look into it.
Could you describe this more, Because I`m still thinking in terms of discretization. I did the same thing in Fluent, and there was no problem with any of those two cases.
I did that cube test, because my bunsen burner case has diffusion and this temperature drop still appears even if I have a steady flow. To check the diffusion mechanism in solver, I created that cube with pure diffusion. the problem appears when Its between N2 and a fuel like Ch4, but it did not appear with N2 and O2 or N2 and H2.
So either the formulations in code is wrong -Optimistically it's not- or the discretization methods creates this instability.
I`m still checking the source code to find out how this discretization should be and I`m looking for the enthalpy formulations in books, too see if the code is missing something.
Any Idea with my case setup? If you need to see my case, send an email to me, 'cause I cannot upload it here.
Well, there is a third option :-)
Either the code and the discretization are correct, but you encounter some problem due to the solution being far from convergence. For example, is the code binding variables while iterating? Does the solution process become more robust reducing the time step? Additionally, what does your checkMesh say? :-)
P.S. You should have my email address in your mailbox.
I agree. A minimal working example (showing the problems) would be a good start! Remote diagnosis are mostly too hard otherwise.
EDIT: P.S.: I really dislike the title of this thread, also because its creator needed 4 threads to come to this quite ultimate conclusion :(
Short update: the problem was a too large Courant number for the kinetics in the Bunsen case, and the fact reaction was not actually completely off in the cube case.
We talked about this by email with Sahm, and hopefully now his case should run.
I've been running in to a similar problem as well and I still have not been able to isolate the issue. Out of curiosity Alberto, could you please explain what it means that the reaction was not completely off?
The reaction model was not disabled in the dictionary, for the case without reaction.
|All times are GMT -4. The time now is 16:37.|