[sushant]

Hi all,

When I run any case in sprayFoam (OF 2.1.x) the introduced mass after the end of injection is never equal to the specified totalMass in constant/sprayCloudProperties. This applies also to the unmodified aachenBomb case, the introduced mass grows over time and becomes constant at ~ 1.8mg whereas a value of 6.0mg is specified.

I am running the Sandia spray H constant-volume case, which is very similar to the tutorial aachenBomb. The case is non-reactive, with chemistry/combustion turned off. The liquid penetrations predicted by sprayFoam agree very well with the measured values. However the vapour length is way behind what you would see in the measurements: it is under-predicted by as much as two-thirds. Again the output shows the introduced mass as ~2.7mg, which is further confirmed by an integration of the term "rho*C7H16" in Paraview at the last time step (which is far beyond the end of injection). I have set totalMass = 17.8mg in the sprayCloudProperties.

I changed the totalMass (by a lot of trial and error) to 44.77mg, and the introduced mass comes close to 17.76mg and results are comparable. My mass flow rate profile for the spray H case is:
(
(0.0000 1.0)
(0.0068 1.0)
)

For the unmodified aachenBomb (2.1.x), totalMass 11.1mg results in injected mass ~ 6mg at the end.

I must be going wrong somewhere to have to resort to this. Am I missing or misunderstanding something, does the totalMass mean something else? How can I get the correct amount of mass into the system to get an acceptable vapour length?

(Pressure convergence criterion is absolute tolerance = 1E-06)

Regards,
Sushant

P.S. I calculate vapour length as the farthest cell along the injection axis that has C7H16 > 1E-06, directly in the solver by using a cell loop (very slow) or from Paraview's 'plot over line' after solving.

[sushant]

Dear all,

On OpenFOAM 1.6-ext dieselFoam does not have this problem, i.e. the injected amount matches the one specified.

However, the aachenBomb tutorial in 1.6-ext has 'mass' specified as 2mg. When this is increased to 6mg, the solver crashes midway because temperature (lower) goes below 200K and JANAF limits are crossed.

There was a discussion on the forum about replacing therm.dat (because C7H16 in it had a common-temperature of 1391K) with an entry that has a common-temperature of 1000K. I tried using this modified therm.dat (which by the way solves the issue with the reacting case on 2.1.x) but it does not help here.

I would really appreciate any suggestions as to where I am going wrong.

Best regards,
Sushant

[pushkaraj]

hi sushant,

I also had same doubt as you posted here....
did u g get any clue taht how the mass flow rate profile in spray cloud properties is calculated?
it is also not matching with total mass
i addd all mass flow rate values as given n it comes around 211.89.

plz share if you had any idea

regards,
Pushkaraj

[sushant]

Hello pushkaraj,

Your problem is slightly different and hopefully easier to solve. You can search around on the forum, there are many posts about the specification of the mass flow rate profile including a very good explanation by niklas. It does not matter what the values add up to because it is normalized later by the totalMass.

My issue is that the totalMass specified is not attained at the end of the simulation: liquid mass + gas mass of fuel in the closed volume ends up much less than specified.

Regards,
Sushant

[sushant]

This is also seen on OpenFOAM 2.0.x (dieselFoam), integrating the fuel mass inside the closed volume (aachenBomb) much after the spray has all evaporated, falls well short of the specified totalMass: again ~1.8mg for 6mg specified.

I have tried tightening the pressure tolerance in both 2.0.x and 2.1.x but it doesn't seem to help. Does anyone have any idea where things are going wrong? I would really really appreciate any suggestions.

Regards,
Sushant

[ris]

With regards to injection of mass, I had the same problem of a smaller amount being injected in OF2.1.x running sprayEngineFoam. I managed to solve the problem by reducing the parcelsPerSecond variable in the sprayCloudProperties file. Try reducing this value to 2e+6 and see what happens.

ris.

[sushant]

Hi ris,

This solves the issue! That's indeed what was wrong with my case setup.

Thanks a ton,
Sushant

[carl_xw4]

Originally Posted by sushant

Hi ris,

This solves the issue! That's indeed what was wrong with my case setup.

Thanks a ton,
Sushant

Hi Sushant and Ris,

I am having the exact same problem. I ran my case perfectly in dieselFoam 20x but facing this issue after I migrate to sprayFoam 21x. That means the total number of parcel that can be injected is somehow constrained?

Please advise. Thanks in advance.

Carl.

[ris]

Hi Carl,

Change the parcelPersecond value in sprayCloudProperties to 200e+6 and reduce the minParticleMass in sprayCloudProperties to 1e-21. this will give you a larger number of parcels.

regards,

ris

[sushant]

Or you can use 2.2.x, where it should run without any changes needed. See: http://www.openfoam.org/mantisbt/view.php?id=785

[dreamilam]

Hi sushant,
can u pls share the "Sandia spray H constant-volume" case if you don't mind??

[RJ87]

Originally Posted by sushant

Or you can use 2.2.x, where it should run without any changes needed. See: http://www.openfoam.org/mantisbt/view.php?id=785

Hi sushant,

Are you sure that the mass problem is resolved?
I'm trying to simulate spray H as well. The mass I'm injecting is 17.5mg.
It stops at somewhere around 13.4mg. I tried using both pressure driven velocity and flow rate profile. They both comes to almost the same result.

I'm using openfoam 2.2.x. Do you happen to know where the problem comes from?

[Mentalo]

At the moment i'm experiencing the same problem on my project. I'm using OpenFoam 2.2.x and the introduced mass is way off the value I specified in the sprayCloudProperties.

Are there any new informations about the problem?

[Mentalo]

After some trial and error i found out that unlike described in the OpenFoam-Wiki http://openfoamwiki.net/index.php/Co...ertiesNParcels
the amount of parcels have a great influence over the injected mass. Seems that the problem from OF 2.0.x reoccurred.

[RJ87]

Does anyone happen to know why Aachen bomb is set to constant volume false and at the same time specific heat and density is set to a value resembles water?

[ENKIME]

Hello Ris
Sorry for bother you, but I have one similar problem and I read you're answer and seems correct for Sushant.
I want to change the mass in the spraycloudproperties the original mass is 6.0e-6 and I need to be 4.0e-5, 40 mg, and when I try to run the code, the code break saying FOAM Warning :
From function janafThermo<EquationOfState>::limit(const scalar T) const
in file /home/opencfd/OpenFOAM/OpenFOAM-2.2.2/src/thermophysicalModels/specie/lnInclude/janafThermoI.H at line 108
attempt to use janafThermo<EquationOfState> out of temperature range 200 -> 6000; T = 157.091

I trying changing, at you're advise, the parcels per second but the error continuous.
Any advice my friend.

Kind regards

[rrschor]

Hi all,

I "fixed" my problem from total mass injection. When i run the case with 4 process it gave me 30% less mass at the end, but with just 1 processor it goes without problems.

Also increasing the number of parcels per second gave me an better solution. I'm still working on it but I recommend that you use one processor only (when running sprayFoam from OpenFOAM 2.4.x).

Best regards,

Roberto

[Likun]

Dear Foamers,

Regarding the missing mass problem of the sprayFoam, I think the following might be the reason and solution.

In most spray simulations, also the case for sprayFoam, you don't really trace every single droplet, because it is extremely time consuming. So the concept of 'parcel' is introduced. A 'parcel' represents several real droplets that have identical properties, e.g. position, velocity, diameter, ect.

The critical question for using the parcel method is that how many real droplets does one parcel represent? OpenFoam provides three methods to determine this number (nParticle): 'mass', 'number' and 'fixed'. And the user can chose between these three methods by specifying the 'parcelBasisType' parameter in 'sprayCloudProperties':

parcelBasisType mass; // number, fixed

'mass' and 'number' respectively mean that all parcels contain the same amount of liquid mass or same number of real droplets. The 'mass' method is most widely used, also in the sprayFoam tutotial case. To be simple, we don't discuss the reason here.

Since we have chosen to give all the injected parcels the same mass (m_p), it is important to see how this m_p is determined during the simulation. In the 'sprayCloudProperties', one also have to provide the total mass to be injected with the parameter 'massTotal' and the flow rate profile as function of time with parameter 'flowRateProfile'. These two parameters together determine the mass of liquid to be injected at each time step (m_ti). There is also a parameter 'parcelPerSecond', which gives the number of parcels to be injected within one second. So the number of parcels to be injected each time step (nParcel_ti) can be determined by the current time step. Now, at a certain time step we have m_ti kg liquid to be injected, and this liquid mass has to be carried equally by nParcel_ti parcels. So the liquid mass that each parcel carries can be easily determined as:

 mParcel_ti = m_ti / nParcel_ti

Now comes the import information. Since in most applications, a poly-dispersed spray is required, means that the droplets have to be injected according to a certain size distribution. This size distribution can be specified for example by the 'RosinRammlerDistribution'. This means that the nParcel_ti parcels injected at time step t all represents different size of real droplets, some represent small droplets, and some for large ones.

In the specified size distribution, there is always a maximum value, 'D_max', referring to the largest droplet to be injected. And there will be, at least one, injected parcel (parcel_Max_ti) that represents these largest droplets. As we discussed above, all parcels carry the same amount of liquid mass, so the number of real droplets represented by this parcel_Max_ti canbe determined as following:

nParticle_Max_ti = mParcel_ti / m_max = 6*mParcel_ti/(pi*D_max^3)

This 'nParticle_Max_ti' is exactly the reason for the missing mass in some cases. Because it is possible that nParticle_Max_ti becomes less than 1, mean this parcel represent less that one real droplet. But in the source code 'InjectionModel.C', there are some lines as below:

                if (pPtr->nParticle() >= 1.0)   
                    {
                        parcelsAdded++;
                        massAdded += pPtr->nParticle()*pPtr->mass();
            
                       if (pPtr->move(td, dt)) 
                        {
                            td.cloud().addParticle(pPtr);
                        }
                        else
                        {
                            delete pPtr;
                        }  
                    }
                    else
                    {
                        delayedVolume += pPtr->nParticle()*pPtr->volume();
                        delete pPtr;
                    }

This means that only parcels that represent at least one real droplets will be injected into the domain, otherwise this parcel is deleted. In the above situation, the parcel that represents largest droplet are not added to the simulation! And this is why the actual introduced mass is less than the specified one. And this is also why reducing the 'parcelsPerSecond' helps solve the problem.

The solution for this problem is to carefully specify the value for 'parcelsPerSecond' in order to guarantee that all the parcels represent at least one real droplets.

Hope this is clear, and it can clarify things a bit.

PS: Reading the source code can always help to reveal some mysteries!

Best,
Likun

[acaist]

Originally Posted by rrschor

Hi all,

I "fixed" my problem from total mass injection. When i run the case with 4 process it gave me 30% less mass at the end, but with just 1 processor it goes without problems.

Also increasing the number of parcels per second gave me an better solution. I'm still working on it but I recommend that you use one processor only (when running sprayFoam from OpenFOAM 2.4.x).

Best regards,

Roberto

Thank you a lot, your suggestion is very helpful. What's more, It spire me to re considerate the problem and carefully think the mesh decomposition. Finally, I find that mass loss for some reason in parallel way might be the injection position located in the top center of the bomb be decomposed in wrong way, which is decomposed by utilities decomposePar in simple way.,such as n(2,2,2). We should note that the injection is Y direction (0,-1,0),.
In this way, the injection position split into 2 parts(I guess), cause injection mass lost. My suggestion to fix the problem is that modify the constant/decomposeParDict, make n(3,3,3) or n(3,3,1) or n(3,1,1) to avoid the injection position being split.
Sorry for poor english.

[sajjadli]

hi my friends
when we use coneInjection model in sprayFoam, the quantity "massTotal" in sprayCloudProperties is th total mass that inject from each hole or it is the total mass that inject from all of the holes?