View Issue Details

IDProjectCategoryView StatusLast Update
0000346OpenFOAM[All Projects] Bugpublic2011-12-08 16:42
ReporterdkxlsAssigned Toadministrator 
Status resolvedResolutionsuspended 
PlatformLinux x86_64OSLinux OpenSUSEOS Version11.4
Product Version 
Fixed in Version 
Summary0000346: no boiling in lagrangian spray (i.e. lagrangian intermediate) library
DescriptionThe evaporation model in the lagrangianIntermediate library does not have a routine for boiling liquids.

Hence, also the lagrangianSpray is not valid for cases where the liquid reaches boiling conditions, which is in fact the case for a lot of applications (in fact all engine applications). This makes the lagrangianSpray library unusable for almost all use-cases of the dieselSpray library.

There is no warning about that in the release notes or the top level solver and the simulations will even start just fine but crash due to too high temperatures in the droplets!

When running the exactly same case with a significantly lower ambient gas temperature (T=400 or T=600) everything works fine. However, even in these cases it seams the results seam to be wrong!

Solution: Add a condition for boiling fuel in the LiquidEvaporation submodel as it is done in the standardEvaporationModel in the dieselSpray library!

Meanwhile you should add a warning to the release notes of OpenFOAM 2.0 that the lagrangianSpray library should not be used to replace the dieselSpray library!
Steps To ReproduceRunning the aachenBomb tutorial with high ambient gas temperatures (T>=800).
TagsNo tags attached.



2011-12-08 14:35


Thanks for your report.

There is indeed no boiling modelling included in the intermediate library's liquidEvaporation model. This functionality may be added in the future, or can be requested under a support contract.


2011-12-08 16:28

reporter   ~0000834

This is _not_ a feature request!! This is a rather severe bug!
Here some more comments on that, since it is obviously not really clear:
The lagrangian intermediate libraries do not consider the case of a boiling liquid at all! Boiling needs, at least, to be considered in the evaporation and the heat transfer sub-models. Maybe at some other places as well, I have not yet checked the code totally!

Why this is important: If boiling conditions are reached the droplets evaporate very fast (i.e. within one time-step, but that of course depends on the implementation of the boiling routine) and therefore the droplet would be taken out of the domain. This leads to a maximum temperature a droplet would reach, which is usually well below the temperatures of the thermodynamic data available in the code.
In the sprayFoam solver this is not the case and therefore the droplets heat up continuously and may reach temperatures of 12000K which is not only totally off, but also causes the calculation to crash!
Such conditions are basically always present in engine applications and therefore the sprayFoam solver is not able to replace the dieselFoam solver! Even worse, it produces rubbish in almost all possible applications! But not enough, if the conditions are such that the droplets heat up but stay below the max. values in the available thermodynamic data, the calculation does not even crash and the user would not know that something is wrong, where again the results are rubbish! So instead of doing simulations with the sprayFoam solver one could write randomly zeros and ones to a file, the meaning would be pretty much the same!

Of course if one does not want to simulate engine cases but rather some low temperature, non-evaporating spray cases the sprayFoam solver might work nicely! But that should be mentioned in the documentation/ release notes/ description of the solver!


P.S.: It's a pity to see that the implementation of the lagragianSpray libraries was done in such a sloppy way, since the lagrangian intermediate libraries otherwise have some nice advantages over the dieselSpray libraries and I very much liked to work with it!

Issue History

Date Modified Username Field Change
2011-11-24 11:04 dkxls New Issue
2011-11-25 12:45 user2 Priority urgent => normal
2011-11-25 12:45 user2 Severity crash => feature
2011-12-08 14:35 user2 Note Added: 0000833
2011-12-08 16:28 dkxls Note Added: 0000834
2011-12-08 16:41 administrator Status new => closed
2011-12-08 16:41 administrator Assigned To => administrator
2011-12-08 16:41 administrator Resolution open => fixed
2011-12-08 16:42 administrator Status closed => resolved
2011-12-08 16:42 administrator Resolution fixed => suspended