Difference between revisions of "OpenFOAM guide/UML/lagrangian"
Floquation (Talk | contribs) |
Floquation (Talk | contribs) |
||
| Line 9: | Line 9: | ||
[[File:UML_lagrangian_solver2Cloud.png|From the solver to the cloud]] | [[File:UML_lagrangian_solver2Cloud.png|From the solver to the cloud]] | ||
| + | |||
| + | The figure above shows two different routes from the solver to the cloud. | ||
| + | In the 'normal' route, cloud.evolve() is called within the solver. | ||
| + | In the alternative 'functionObject' route, a FunctionObject will call cloud.evolve(). The [[Contrib/swak4Foam|swak4foam library]] provides a FunctionObject which is able to do this for an arbitrary cloud. | ||
| + | |||
| + | 'KinematicCloud' in the figure is merely an example and may be replaced by any other cloud. | ||
[[File:UML_lagrangian_cloud2Particle.png|From the cloud to the individual parcels]] | [[File:UML_lagrangian_cloud2Particle.png|From the cloud to the individual parcels]] | ||
| + | |||
| + | In the figure above, note that all clouds extend 'KinematicCloud' through inheritance, but KinematicCloud handles the motion. | ||
| + | Consequently, for every cloud, the KinematicCloud class is used. | ||
[[File:UML_lagrangian_particleType.png|How each individual parcel handles its movement event]] | [[File:UML_lagrangian_particleType.png|How each individual parcel handles its movement event]] | ||
| + | |||
| + | In the figure above, 'move()' is called several times per timestep. Each time a parcel crosses a cell face (or patch), movement stops at the face and continues in a next call to move(). The 'trackToFace()' method takes care of stopping at a face. | ||
| + | |||
| + | 'Cloud<ParticleType>' extends 'IDLList<ParticleType>' (not shown), meaning it literally IS a list/collection of parcels. | ||
| + | 'Cloud' has methods to serve the ensemble of parcels. | ||
== CloudFunctionObjects == | == CloudFunctionObjects == | ||
| + | CloudFunctionObjects allow the user to add functionality to the cloud using a 'cloudFunctions' subdict in the 'constant/<CloudName>Properties' file. | ||
| + | When writing a custom CloudFunctionObject, you may interpret it as a hook to inject code into the cloud or parcels. | ||
Revision as of 12:58, 1 December 2014
Valid versions: 
1 Overview
The three UML diagrams below are qualitative diagrams, showing the calling sequence of the important methods. The first shows two different routes from the solver level to OF's KinematicCloud class. The second shows what happens inside the KinematicCloud class up to the point that we arrive at the Cloud class, which will be moving the individual parcels. In the third, we can see what happens for the individual parcels in the KinematicParcel class.
The figure above shows two different routes from the solver to the cloud. In the 'normal' route, cloud.evolve() is called within the solver. In the alternative 'functionObject' route, a FunctionObject will call cloud.evolve(). The swak4foam library provides a FunctionObject which is able to do this for an arbitrary cloud.
'KinematicCloud' in the figure is merely an example and may be replaced by any other cloud.
In the figure above, note that all clouds extend 'KinematicCloud' through inheritance, but KinematicCloud handles the motion. Consequently, for every cloud, the KinematicCloud class is used.
In the figure above, 'move()' is called several times per timestep. Each time a parcel crosses a cell face (or patch), movement stops at the face and continues in a next call to move(). The 'trackToFace()' method takes care of stopping at a face.
'Cloud<ParticleType>' extends 'IDLList<ParticleType>' (not shown), meaning it literally IS a list/collection of parcels. 'Cloud' has methods to serve the ensemble of parcels.
2 CloudFunctionObjects
CloudFunctionObjects allow the user to add functionality to the cloud using a 'cloudFunctions' subdict in the 'constant/<CloudName>Properties' file. When writing a custom CloudFunctionObject, you may interpret it as a hook to inject code into the cloud or parcels.
