[omid20110]

Hello all,
I want to add a new force to the lagrangian library (lagrangian/intermediate/submodels/Kinematic/ParticleForces).
In my new force I have to use initial diameter of particles. I found a function called d0() that returns const access to initial droplet diameter but when I wanted to compile the new force, it gives an error error.jpg
Now I don't know how can I solve this problem!
Also, there is another function that returns access to the diameter of particles during the simulation. But I just need the initial diameter.


d0()

https://www.openfoam.com/documentati...257ba2ae815818


d()
https://www.openfoam.com/documentati...d09f0f8b80c9eb

[mturcios777]

It looks like the d0() function exists in sprayParcel, not in KinematicParcel that you are using. Have a look in the KinematicParcel code to see if there is anything that you can use:
https://www.openfoam.com/documentati...0de8e48ae.html

[omid20110]

Yes I know that
Please have a look at here:
https://www.openfoam.com/documentati...l.html#details


There is a d() that returns const access to diameter.
And a dTarget() that returns const access to target diameter.
Now how can I use these to get initial diameters in every timesteps?


Also look at this kinematicparcel.jpg
I can see a d0 but I don't know what is that and how should I use it?

[mturcios777]

That d0 is a parameter passed when the parcel is created. It looks like for KinematicParcels d doesn't change, hence no need to track d0. What solver are you using? Most of the reacting parcel solvers use basicSprayCloud which uses sprayParcel, which does have d0 tracked separately.

[omid20110]

I'm using sprayFoam (OF 5.x). I think d is changing due to evaporation and combustion also in sphereDrag they have used d() function because the diameter of droplets are changing. I just want to add a new force baced on the initial diameter

[jpeter3]

Hay!

It seems, that you are trying to write a new force model for KinematicParcel.

Force models are in lagrangian library defined for KinematicParcel, all more complicated parcells evaluate forces on them through inherited KinematicParcel class.

So, if you want to make a force model, that needs some data from "higher" particles (as your SprayParcel), you need to write new abstract force model (something like "Spray"ForceModel class), link it to Spray parcel through derived files (makeParcelModels... file), make new include files for new force model (include"Spray"ForceModels file). It is a tidius work.

If you are not very eager and not into C++ I would suggest you find a work-around using only data from KinematicParcel, or hardcoding your force inside SprayParcel class.

Cheers,
Jaka

[omid20110]

Thanks for your help,
Yes I want to write a new force model that uses initial diameters of droplets.
May you tell me exactly how can I write a new force model as you said?


For the second suggestion, I think by some coding I can use d() to give initial diameters, but how?
I don't understand what do you mean by this : "find a work-around using only data from KinematicParcel, or hardcoding your force inside SprayParcel class", can you explain it more?

[jpeter3]

Ok. To write a new force model, one that Will be defined for SprayParcel, instead of KinematicParcel you should write a new force model with a minor modification.

Assuming that SprayParcel is derived from KinematicParcel, they go usually like a tree: SprayParcel<KinematicParcel<particle> > >, defined in derived folder in intermediate by a file probably called basicSprayParcel.H. This is an important concept to lagrangian library, as you Will surely find out. Your sprayParcel most certainly is derived from particle and kinematic parcel itself, and for example, when d() function is called on SprayParcel, it is actually passed down to KinematicParcel hiding in there and evaluated by KinematicParcel and passed back to whichever SprayParcel or some other function that called it.


So, to make a new force model for SprayParcel, you can copy paste force model as it is, rename it into something new, e.g. SprayParticleForce, and then the key is to change the last part of the main model, where macro defines the way the model is build. Instead for kinematic cloud, it should be for spray cloud.
(https://github.com/OpenFOAM/OpenFOAM...articleForce.H)

Then you do some work to make it work (do the right changes to makeSprayParcelModels.. file, to include the new and not the old forces, make changes in SprayParcelCloud, to contain the new not the old force model ...) and at the end, parcel that you are refering to in your new SprayParticleForce Will be SprayParcel, not KinematicParcel as it is in current force model. Then you can program a new force, and by calling p.d0(), the model Will be able to look into SprayParcel data and functions and give you the value.

Maybe esier is to just "fix" the existing main model linked above to take in SprayCloud ... but this means that other clouds that do not contain SprayCloud, their parcels and solvers that relly on them will stop working.

Work-around using only KinematicParcel data is linked to the fact that force model as it is Works only with kinematicParcel's. So it can only Access data from KinematicParcel and all the data that KinematicParcel inherits from particle class. So, if you can use anything from this two classes to solve your problem, that is the easiest as you do not have to change the main model and all above mentioned files.

This leads me to a good idea you have, to just change the d() function. I would not recommend changing it, as the SprayParcel uses it to calculate whatever it need it for (remember the structure and inheritance of parcels), so changing it would criple the SprayParcel. But, creating new function, something like, myD0() in KinematicParcel, and using some sort of trick (like that when it gets called first returns current diameter and stores it in some variable along with changing some bool to false and then with this bool changed to false only returning the stored value? do your magic ), Will allow you to call it in force models and give you the initial diameter.

If I may ask, why are you evalutaing some force on diameter of something else not the current diameter? This is physicaly fishy, do you really want that?

[omid20110]

I think the first part of creating the new force model in spray Parcel is difficult and somehow it can ruin everything
but for the last suggestion "when it gets called first returns current diameter and stores it in some variable along with changing some bool to false and then with this bool changed to false only returning the stored value" I had done this but there is some error that may be you can help me fix that.
Please refer to paramagnetic force:
I have changed the last part of the ParamagneticForce.C this way:

 forceSuSp value(Zero, 0.0);

const interpolation<vector>& HdotGradHInterp = *HdotGradHInterpPtr_;

if (time)
{
     d0=p.d();
value.Su()=d0*HdotGradHInterp.interpolate(p.coordinates(), p.currentTetIndices());
time = 0;
Info << 1 <<endl;
}
else
{
    value.Su()=d0*HdotGradHInterp.interpolate(p.coordinates(), p.currentTetIndices());
Info << 2 <<endl;

}
return value;
}

And I have defined a bool time and scalar d0 in ParamagneticForce.H as:

     public ParticleForce<CloudType>
{
    // Private data

        //- Name of electrostatic field strength field - default = "HdotGradH"
        const word HdotGradHName_;

        //- HdotGradH interpolator
        const interpolation<vector>* HdotGradHInterpPtr_;

        //- Magnetic susceptibility of particle
        const scalar charge_;
    bool time=1;
    scalar d0;

but when I compile this it gives some error. Can you help me with this?


Also another question:
Do you know how to post process NOx prediction as described by KADAR here:
NOX

[jpeter3]

Models work a bit differently. There is only one model, which gets called by each parcel in the cloud during parcel evolution. So the code that you presented, even when debuged and compiled Will remember only the initial diameter of the first parcel that Will call it.

The main idea is to program the part of the code that remembers the initial diameter of a parcel inside the KinematicParcel.H and KinematicParcel.C. This function (e.g. myD0()), should be then accessible in force model, where you would call it by p.myD0().


I think that should do the trick …

[jpeter3]

Regarding the NOx post-process utility, if I understand correctly a new partial differential equation should be solved using some sources, calculated by main solver.

If that is the case, my suggestion is to build it inside the main solver, like a scalar, thermal, NS … transport equation. You should define necessary fields in create fields dirrectory, and put in the main solver e.g. NOXeqn.H, that would contain the partial differential equation definition and execute its solve function. You can check how this is done in some scalar transport solver.

This way, it is something like run-time postprocessing. I find it more elegant this way.