Hi
To get the particle sizes that I need, I am using LIGGGHTS in the "cgs" unit system, but OpenFOAM still works in the "si" unit system. I have converted all my LIGGGHTS values to work in the cgs system, however, when I combine the data in paraview, it is obvious that the two sets of data do not match up.
I presume that the coupling software uses the (dimensionless) numerical values as output by each programme, but does not check if they are of the same unit system? Therefore I want to create a conversion routine that converts the units during the coupling.
Firstly, is this the only way to do it? Secondly, what is the best way to do this? Should I create a new "dataExchangeModel" for the coupling that converts the units as it sends the information back and forth?
Regards
Evan
cgoniva | Tue, 12/06/2011 - 15:09
Hi Evan! >>Should I create a
Hi Evan!
>>Should I create a new "dataExchangeModel" for the coupling that converts the units as it sends the information back and forth?
I would see this as a smart solution as you would do the conversion just at the interface between the programs.
This would help finding bugs and keep both programs as they are. (Just in the "spirit" of the coupling :)
The conversion itself should not cause too much trouble.
But you will have to set up the case on CFD side in SI and DEM side in cgs.
I would not mess around with the units on CFD side as they have their dimensionSets with [kg,m,s,A,V,cd]?
Cheers,
Chris
ckloss | Tue, 12/06/2011 - 23:23
Hi Evan and Chris,Evan,
Hi Evan and Chris,
Evan, thanks for bringing up this discussion. I am not sure if it would make sense from a numerical point of view to operate the two codes on different scales (unless you do multi-scale modelling, i.e. CFD on a coarse scale and DEM/MD on the fine scale)
@Chris: is there anything that would prohibit using csg in OpenFOAM (without specifying it anywhere)? Shouldn't this work out-of-the-box - as cgs is self-consistent, as SI is?
@Evan: Yes, you are completely right - the data exchange routine would be the place to code this. Instead of writing a completely new one, it would probably better to modify the current implementation.
One obvious possibility to implement this is would be be lines 95 and 110-12 in cfd_datacoupling_mpi.cpp on the LIGGGHTS side (and the corresponding lines for the file coupling). The problem I see is that at this place in the code you have no information about the units.
In general, as far as I see, operating both codes at different unit systems could be a tedious endeavor - as the OF side (Chris, correct me if I'm wrong) does track dimensions, but not the unit system and LIGGGHTS tracks the unit system used, but not the dimensions of the properties. Any suggestions?
Cheers, Christoph
cgoniva | Wed, 12/07/2011 - 08:55
Hi!>>I am not sure if it
Hi!
>>I am not sure if it would make sense from a numerical point of view to operate the two codes on different scales.
surely a point, e.g. 1dyn is 1e-5N so you might lose about 5 digits?
>>@Chris: is there anything that would prohibit using csg in OpenFOAM (without specifying it anywhere)? Shouldn't this work out-of-the-box - as cgs is self-consistent, as SI is?
you could use cgs without specifying anywhere - which IMHO will lead to a lot of confusion?! The only one who could handle your cases would be you? OF should check the exponents of weight,length,time... scales but not if you refer to cgs or SI.
If you want to use two unit systems I would simply write a converter, which should not be a big deal (without having tried) and then give it a try. But keep in mind that changing the unit system of the input parameters of one of the codes might be even less difficult/work?
Cheers,
Chris
evansmuts | Wed, 12/07/2011 - 11:50
Hi guys Thanks for the
Hi guys
Thanks for the interesting feedback.
>>I am not sure if it would make sense from a numerical point of view to operate the two codes on different scales.
surely a point, e.g. 1dyn is 1e-5N so you might lose about 5 digits?
I think the question about the numerical "correctness" of working with two different unit systems is an important one. I am having to run LIGGGHTS with the cgs system for a reason. It would probably be more correct to have OF working in cgs as well, though I have no idea how to go about changing it (and I am sure it will take more time than I think!). Therefore I am thinking about the (easy) option of just converting the values as they are passed between programmes. That way each programme can work independently of each other without any problem. However, the question of "losing" information during the conversion is a concern.
>>unless you do multi-scale modelling, i.e. CFD on a coarse scale and DEM/MD on the fine scale
I am not sure if my problem is truly multi-scale. My CFD domain is relatively small, and it is only because my particles are much smaller than LIGGGHTS can handle in si units that I need to use the cgs unit system. I agree the multi-scale issue would be a problem for most bigger CFD models with small particles. How would a multi-scale cfdem approach differ from the "traditional" one?
In terms of where to do the conversion, I will most likely create a new data exchange model like "twoWayMPI-CGStoSI". This will allow me to choose when I want the conversion to happen during the coupling. It is at a much higher level in the code than cfd_datacoupling_mpi.cpp, but should work the same. As far as I can tell, only the positions, velocities, radii and drag forces are passed between the two programmes. So it should be easy do figure out which is which and then apply the appropriate conversion factor.
Cheers
Evan
evansmuts | Tue, 12/13/2011 - 16:07
important variables
Hi Chris
Am I correct in assuming that the only variables that are passed between OF and LIGGGHTS are x, v, radius, and drag force? These are the obvious ones that I can find, so I just want to check if there are others. I am using twoWayMPI with cfdem version 2.1.
Cheers
Evan
cgoniva | Wed, 12/14/2011 - 07:31
Hi Evan, That is all you need
Hi Evan,
That is all you need for mass and momentum coupling (neglecting particle rotation on CFD side).
Cheers,
Chris