CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Running, Solving & CFD

Incorrect introduced mass in sprayFoam?

Register Blogs Community New Posts Updated Threads Search

Like Tree14Likes

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   August 24, 2016, 04:48
Default
  #21
New Member
 
yagmur
Join Date: Apr 2012
Posts: 7
Rep Power: 14
criolla is on a distinguished road
Dear User,

I also tried to reduce parcelspersecond in my case, it didnt work. The mass introduced is very less than the amount that must be injected . I use Rommler Distribution dmin 3e-5 dmax 4e-5 d 3.5e-5 n=3. I am not sure if I represent well all droplet size?

Thanks in advance,
criolla is offline   Reply With Quote

Old   July 4, 2017, 04:04
Default incorrect introduced mass in sprayFoam (OF 4.1)
  #22
Member
 
Sadegh Ebadi
Join Date: Apr 2015
Posts: 75
Rep Power: 11
omid20110 is on a distinguished road
Hello everybody,
I also have the same problem with the introduced mass, it is lower than what I had defined!
I'm using OF 4.1 (latest version of OpenFoam), I thought that the problem sushant had mentioned should have been solved by now! But I see it's just working for aachen bomb tutorial! I know that there should be a harmony between totalmass, massprofile, and ParcelsPerSecond parameters but some how I am confused by the way they relate to each other.
I have attached my sprayCloudProperties file. I would appreciate any idea to solve this problem.
Attached Files
File Type: zip sprayCloudProperties.zip (3.1 KB, 9 views)
omid20110 is offline   Reply With Quote

Old   July 5, 2017, 03:43
Default
  #23
New Member
 
Golden
Join Date: Jun 2017
Posts: 4
Rep Power: 9
goldersantu is on a distinguished road
Hello everyone,
I am doing a combustion things smallpoolfire, I added the chemkin folder and also given the path of chemkin file and transport properties in thermophysical properties. But it showing following error:
From function static typename Table::iterator Foam::basicThermo::lookupTherm
o(const Foam::dictionary&, Table*) [with Thermo = Foam:siReactionThermo; Table
= Foam::HashTable<Foam::autoPtr<Foam:siReactionThe rmo> (*)(const Foam::fvMesh
&, const Foam::word&), Foam::word, Foam::string::hash>; typename Table::iterator
= Foam::HashTable<Foam::autoPtr<Foam:siReactionThe rmo> (*)(const Foam::fvMesh
&, const Foam::word&), Foam::word, Foam::string::hash>::iterator]
in file /home/buzz2/pawan/OpenFOAM/OpenFOAM-v1612+/src/thermophysicalModels/
basic/lnInclude/basicThermoTemplates.C at line 73.
goldersantu is offline   Reply With Quote

Old   April 4, 2018, 16:31
Default
  #24
Member
 
Sadegh Ebadi
Join Date: Apr 2015
Posts: 75
Rep Power: 11
omid20110 is on a distinguished road
Greetings to all,
As a response to this post
I have tried many parameters in order to find their effect on the injected mass. For example I tried changing number of parcels but nothing special had changed in the mass injected. After all I have tried my case with different geometries: A full cylinder and a 30 degree sector of that cylinder. I figured out that in the case of full cylinder the injected mass at the end of simulation is the same as the mass specified in spraycloudProperties. And the mass in the case of 30 degree sector of the cylinder is proportional to the mass of full cylinder. Clearly, in the spraycloudProperties we specify the full geometry mass (here, full cyilinder) and when our geometry is 30 degree sector, the injected mass is 30/360=1/12 of the specified mass.
If we specify the mass 6.0 mg in the case of full cylinder we get this 6.0 mg as injected mass, but in the case of 30 degree sector of the cylinder we get 6.0/12=0.5mg at the end of the simulation.

Good Luck
omid20110 is offline   Reply With Quote

Old   July 10, 2020, 01:38
Default
  #25
Member
 
Riddhideep Biswas
Join Date: May 2020
Posts: 30
Rep Power: 6
Rid@foam is on a distinguished road
Quote:
Originally Posted by Likun View Post
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':
Code:
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:
Code:
 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:
Code:
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:
Code:
                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

Thanks a lot. Your suggestion is really helpful.
Does all the parcels injected throughout the simulation has the same mass?
Or only parcels injected at a particular time step has same mass and parcels at different time steps can have different mass?
Rid@foam is offline   Reply With Quote

Old   July 10, 2020, 01:39
Default
  #26
Member
 
Riddhideep Biswas
Join Date: May 2020
Posts: 30
Rep Power: 6
Rid@foam is on a distinguished road
Quote:
Originally Posted by Likun View Post
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':
Code:
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:
Code:
 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:
Code:
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:
Code:
                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

Thanks a lot. Your suggestion is really helpful. I still have a question.
Does all the parcels injected throughout the simulation has the same mass?
Or only parcels injected at a particular time step has same mass and parcels at different time steps can have different mass?
Rid@foam is offline   Reply With Quote

Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
mass flow in is not equal to mass flow out saii CFX 12 March 19, 2018 06:21
sprayFoam crashes lukasfischer OpenFOAM Running, Solving & CFD 3 July 14, 2013 12:08
Water subcooled boiling Attesz CFX 7 January 5, 2013 04:32


All times are GMT -4. The time now is 18:17.