I'm trying a few things as a b
I'm trying a few things as a beginner, imitating an example from the programming manual, but don't seem to understand where the problem is arising:
in my createFields.H file I have :
the parameter alpha_ht is meant to replace DT in laplacianFoam, as a heat transfer parameter that is temperature dependent.
in the app.C file, I have:
volScalarField alpha_ht = 181.0/((2606.0-0.21*T)*(1074.0 - 0.046168*T));
This is an expression for the temperature dependent DT parameter, just in front of the code for the PDE solve statement.
Can I use the variable T above, or does it need to be referenced in another way?
I in the 0/ directory I have an alpha_ht file, with initial statements:
dimensions [0 2 -1 0 0 0 0];
internalField uniform 4.0E-05;
Is this the source of the problem? I was thinking that the 0/alpha_ht file is a kind of dummy initialization, and the alpha_ht field would be overwritten by the code from the app.C file. ??
the run-time error is reported as:
--> FOAM FATAL ERROR : LHS and RHS of - have different dimensions
dimensions : [0 0 0 0 0 0 0] - [0 0 0 1 0 0 0]
makes no sense to me.
Any guidance most appreciated.
Dear Ken, How can this erro
How can this error not make sense to you: it says the dimensions of the terms in the differential equation you are trying to solve do not match.
In your constructor, you have made the dimensions of alpha_ht identical with the dimensions of T, which MUST be wrong.
Furthermore, you now have 2 field variables, both called alpha_ht, probably in different scopes. Further from that, you have specified alpha_ht file in the zero directory, but your constructor clearly says IOobject::NO_READ, meaning the field WILL NOT BE READ. The file will get ignored.
This sounds like nightmarish sloppy coding or maybe you are not sure what you'd like to do in the first place.
1 figure out what you want to do: create a field in the code or read it in
2 establish only a single variable called alpha_ht and initialise it in the right way (read from a file, calculated from your formula, or made to be identical to T
3 work out what the dimensions of alpha_ht should be for your equation to make physical sense.
Once you get this far, you will be able to answer questions on where alpha should come from, how you wish to construct and initialise it. We can then talk syntax etc. I would also encourage you to have a look at the existing OpenFOAM examples and see how (easily) this kind of thing is done.
The hurdles outlined above hav
The hurdles outlined above have been overcome.
the main rookie errors were:
1. not understanding that declaring alpha_ht in two places is fatal
2. not grasping that OF is worse than the old DDR border patrols when it comes to dimensional consistency...
in light of No. 2, I have:
dimensionedScalar a1 ("a1",dimensionSet(0, 0, 0, -1, 0, 0, 0),0.21);
dimensionedScalar a2 ("a2",dimensionSet(0, 0, 0, -1, 0, 0, 0),0.046168);
dimensionedScalar a3 ("a3",dimensionSet(0, 2, -1, 0, 0, 0, 0),181.0);
alpha_ht = a3/((2606.0-a1*T ) *(1074.0 - a2*T ));
the dimensionedScalar declarations seemed necessary to get the expression to match the declared dimensions of alpha_ht.
Is there any way possible to just write the expression for alpha_ht that produces a "number", (ie; we tried T.value(), didn't work, seems the .value() thing won't work on volScalarFields... )
The expression is somewhat artificial, it's a stat. regression expression for a coefficient, that gives the coeff. in the units it requires, but the a1,a2,a3 values inside it are purely empirical.
Is there some way of simplifying the expression for alpha_ht to a single line of code??
Sure, You can circumvent di
You can circumvent dimensional checking if you wish to do so. Let's first make the field with the right dimensions:
dimensionedScalar("at", your_dimensions_here, 0),
Now, you can set the internal and boundary field separately
alpha_ht.internalField() = a3/((2606.0-a1*T.internalField() ) *(1074.0 - a2*T.internalField()));
alpha_ht.boundaryField() = a3/((2606.0-a1*T.boundaryField() ) *(1074.0 - a2*T.boundaryField()));
You can be even more clever, using, e.g. a zero gradient boundary condition to get the patch values etc, but this should do the job for the moment. Note how I have specified the field to be no-read and no-write and associated it with the mesh: this means you can merrily do field calculus with it, like for example evaluating its gradient http://www.cfd-online.com/OpenFOAM_D...part/happy.gif
|All times are GMT -4. The time now is 14:25.|