|
[Sponsors] |
|
March 26, 2018, 17:40 |
Accessing g (gravity)
|
#1 |
Member
Declan
Join Date: Oct 2016
Location: Ireland
Posts: 40
Rep Power: 9 |
Dear Foamers
I am a beginner OF programmer trying to compile a simple modification to the driftFluxFoam velocity correction function Udm that looks like: where f(x) is a combination of variables and g is gravitational acceleration. My issue is getting the function to read g, which is a file in the transportProperties dictionary. When compiling I get an error messages like ‘g was not declared in this scope’. I have tried many things like: 1. including the “readGravitationalAcceleration.H” file within some of the related files 2. adding a dimensionedVector term called ‘grav’ to the transportProperties dictionary itself then calling it along with the other velocity function variables 3. trying to define const uniformDimensionedVectorField in the modified file 4. looking at other default solvers and their functions for similar calculations I feel like this is something straightforward and it's just lack of experience getting in the way but I've been at it for days now and any help would be much appreciated!! Many Thanks! Declan |
|
March 26, 2018, 23:18 |
|
#2 |
Senior Member
Gerhard Holzinger
Join Date: Feb 2012
Location: Austria
Posts: 339
Rep Power: 28 |
Since, you are about to create your own relativeVelocityModel, which is a separate compilation unit than the solver itself, you need to include the header file for the appropriate data type. Secondly, you can look-up the gravity field from the object data base of OpenFOAM.
In the code below, the necessary include statement as well as the construction by look-up is listed. You might want to put the include statement into the header of your relativeVelocityModel class, and the look-up statement into the function-body of your Udm() method, or whereever you need to access gravity. Code:
// include data type, if necessary #include "uniformDimensionedFields.H" uniformDimensionedVectorField g ( mesh.lookupObject<uniformDimensionedVectorField>("g") ); |
|
April 1, 2018, 17:14 |
|
#3 |
Member
Declan
Join Date: Oct 2016
Location: Ireland
Posts: 40
Rep Power: 9 |
Hi Gerhard, thank you for your post.
I have not yet been able to solve the problem! I am creating an alternative relative velocity model (simple and general are the default models) called general2 and I would like to define Udm within the general2.C file. If I declare Code:
uniformDimensionedVectorField g (mesh.lookupObject<uniformDimensionedVectorField>("g")); I feel there must be a way to simply read the g file located in the constant folder without having to read it from the mesh itself? Could I somehow get transportProperties to read it for me and then just take it from transportProperties with all the other parameters? |
|
April 2, 2018, 19:37 |
|
#4 | |
Senior Member
Gerhard Holzinger
Join Date: Feb 2012
Location: Austria
Posts: 339
Rep Power: 28 |
Quote:
If you take a look at the constructor of the base class for the relative velocity models, especially, the second and third argument of the IOobject constructor, shows you how to get a reference to the mesh and the run-time objects. Code:
Foam::relativeVelocityModel::relativeVelocityModel ( const dictionary& dict, const incompressibleTwoPhaseInteractingMixture& mixture ) : mixture_(mixture), alphac_(mixture.alpha2()), alphad_(mixture.alpha1()), rhoc_(mixture.rhoc()), rhod_(mixture.rhod()), Udm_ ( IOobject ( "Udm", alphac_.time().timeName(), alphac_.mesh(), IOobject::READ_IF_PRESENT, IOobject::AUTO_WRITE ), alphac_.mesh(), dimensionedVector("Udm", dimVelocity, Zero), UdmPatchFieldTypes() ) {} There is no need to read gravity from the constant directory again, as it has been already read. And it has been registered with the mesh, hence you can use object lookup. Which is done e.g. in twoPhaseEulerFoam/twoPhaseSystem/diameterModels/IATE/IATEsources/IATEsource/IATEsource.C The whole purpose of OpenFOAM's object registry is to avoid every class reading fields on their own. If the solver and the drag model would read the velocity field independently, you end up with two independent copies of U. If the solver updates U, then the drag models needs to be told, that its copy of U is now outdated. This is a can of worms nobody really wants opened. Thus, you get yourself a reference to the one and only velocity field, which is by virtue of being the only one, always up to date. |
||
May 21, 2018, 16:38 |
|
#5 |
Member
Declan
Join Date: Oct 2016
Location: Ireland
Posts: 40
Rep Power: 9 |
Hi Gerhard,
Thanks again for your help and explaining about the OF objectRegistry. I was eventually able to implement g in the following way: Code:
g_ ( IOobject ( "g", alphac_.time().timeName(), alphac_.mesh(), IOobject::MUST_READ, IOobject::NO_WRITE ), ) |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Convergence problem when use gravity | aroma | STAR-CCM+ | 1 | April 10, 2013 10:18 |
Ok to increase gravity gradually from 0 to 9.82? | Admo | FLUENT | 3 | February 23, 2012 10:43 |
UDF fails to model 9.81m/s^2 gravity | jpo | Fluent UDF and Scheme Programming | 2 | January 24, 2012 18:15 |
how to consider gravity in CFX | shrimp | CFX | 4 | September 8, 2008 20:41 |
On gravity modelling... | Drona | CFX | 7 | November 22, 2001 10:28 |