CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM

raising volScalarField to an exponent

Register Blogs Community New Posts Updated Threads Search

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   December 10, 2010, 17:50
Default raising volScalarField to an exponent
  #1
Member
 
Daniel
Join Date: Jul 2010
Location: California
Posts: 39
Rep Power: 15
hyperion is on a distinguished road
Hello - I'm trying to modify a functionObject to output an additional field using the following chunk of code:


Info<< " Calculating mean free path field." << endl;
volScalarField mfp
(
IOobject
(
"mfp",
obr_.time().timeName(),
obr_,
IOobject::NO_READ
),
1/(8.9968e-19*rhoNMean*pow(overallT/300, .42))
);


Where overallT was defined as a volScalarField earlier in the code. The code doesn't like when I use overallT as an argument to the pow(base, exponent) function. Can I convert overallT ( a volScalarField) to something else like a scalar field? Where can I found out if a particular kind of argument is allowed?

I would greatly appreciate any advice on how to solve this.

Many Thanks

Last edited by hyperion; December 11, 2010 at 19:37.
hyperion is offline   Reply With Quote

Old   December 12, 2010, 05:38
Default
  #2
Senior Member
 
Martin
Join Date: Oct 2009
Location: Aachen, Germany
Posts: 255
Rep Power: 21
MartinB will become famous soon enough
Hi Daniel,

the pow() function works for me (OpenFOAM-1.6.x) with this dummy code snippet:
Code:
	volScalarField overallT
	(
			IOobject
			(
					"dummy",
					runTime.timeName(),
					mesh,
					IOobject::NO_READ,
					IOobject::AUTO_WRITE
			),
			multiPhaseProperties.mu()
	);

	volScalarField mfp
	(
	IOobject
	(
	"mfp",
	runTime.timeName(),
	mesh,
	IOobject::NO_READ
	),
	1/(8.9968e-19*overallT*pow(overallT/300, .42))
	);
	mfp.write();
It compiles and it writes results (although these results are nonsense, of course)... and overallT is a volScalarField...

Do you have a compilation problem or a runtime problem?

Martin
MartinB is offline   Reply With Quote

Old   December 12, 2010, 11:47
Default
  #3
Senior Member
 
Laurence R. McGlashan
Join Date: Mar 2009
Posts: 370
Rep Power: 23
l_r_mcglashan will become famous soon enough
If it's a runtime error, then it's most likely that somewhere in your overallT field you have a negative number if the error is from within the Foam:ow() function.
__________________
Laurence R. McGlashan :: Website
l_r_mcglashan is offline   Reply With Quote

Old   December 13, 2010, 00:59
Default
  #4
Member
 
Daniel
Join Date: Jul 2010
Location: California
Posts: 39
Rep Power: 15
hyperion is on a distinguished road
Thank you both for your responses. It is a runtime error and, as Laurence suggested, it is caused by division by zero. The zero values of overallT only occur on the boundary field and not in the internal field. Is there a way I can ignore boundary field values and only calculate values for the internal field?

Thanks Again
hyperion is offline   Reply With Quote

Old   December 13, 2010, 01:15
Default
  #5
Senior Member
 
Martin
Join Date: Oct 2009
Location: Aachen, Germany
Posts: 255
Rep Power: 21
MartinB will become famous soon enough
You can use
Code:
pow(max(overallT,VSMALL)/300, .42)
to avoid division by zero.

Martin
MartinB is offline   Reply With Quote

Old   December 13, 2010, 01:32
Default
  #6
Member
 
Daniel
Join Date: Jul 2010
Location: California
Posts: 39
Rep Power: 15
hyperion is on a distinguished road
Thanks Martin - Now I get the following error message at runtime:

--> FOAM FATAL ERROR:
Arguments of max have different dimensions
dimensions : [1 2 -2 0 0 0 0] and [0 0 0 0 0 0 0]


From function max(const dimensionSet& ds1, const dimensionSet& ds2)

in file dimensionSet/dimensionSet.C at line 199.


(There's also a bunch of print stack and FPE errors following the above statement. These errors were there before adding the max statement as well.)

Could you explain what code you suggested is supposed to do? What is VSMALL? What happens when you have two arguments in the max() statement?

Many Thanks
hyperion is offline   Reply With Quote

Old   December 13, 2010, 01:49
Default
  #7
Senior Member
 
Martin
Join Date: Oct 2009
Location: Aachen, Germany
Posts: 255
Rep Power: 21
MartinB will become famous soon enough
VSMALL is a constant with a very small positive value.
max(VSMALL, otherValue) therefore guarantees a nonzero positive value to be used in a function that will fail otherwise.

To add the correct dimensions to this constant, try this:
Code:
pow(max(overallT, dimensionedScalar ("VSMALL", dimensionSet(1,2,-2,0,0,0,0), VSMALL))/300, .42)
Since the small value is further divided by 300, it might be necessary to increase its value by a factor of 300 before... just try without first and see what's happening...

Martin

Last edited by MartinB; December 13, 2010 at 01:50. Reason: removed typo
MartinB is offline   Reply With Quote

Old   December 13, 2010, 04:47
Default
  #8
Senior Member
 
Laurence R. McGlashan
Join Date: Mar 2009
Posts: 370
Rep Power: 23
l_r_mcglashan will become famous soon enough
The real issue you have here is that you need to either initialise the boundary conditions, or remove them from overallT. Does mfp need boundary conditions? If not, just make the variable a scalarField. Otherwise, initialise the boundary fields.

You can access the boundaries using .boundaryField() and the cells using internalField()
__________________
Laurence R. McGlashan :: Website
l_r_mcglashan is offline   Reply With Quote

Old   December 14, 2010, 13:56
Default
  #9
Member
 
Daniel
Join Date: Jul 2010
Location: California
Posts: 39
Rep Power: 15
hyperion is on a distinguished road
Thanks Martin for the snippet of code and for your explanation of its meaning. I used that code and the application runs well now. I do obtain values for the mean free path that approach infinity at a few boundary cell faces, but I can ignore those values for now. I am treating it as a temporary fix to a larger problem, which is that the solver (dsmcFoam) attributes extreme values to particular patches in certain simulation runs. I haven't yet figured out why it does this in for certain geometry and boundary conditions.

I want to make sure I understand Laurence's remarks, so I have a few more questions. If overallT is computed from a volScalarField that has to be specified in the 0 directory, then does that mean that it is initialized and defined with boundary conditions? Can overallT be a scalarField if it's computed from a volScalarField? What do you mean I can "access" the boundary and internal fields? Do you mean as a means to read or write new values to those fields? What would be the purpose of accessing those fields?

Once Again, Many Thanks
hyperion is offline   Reply With Quote

Old   December 14, 2010, 14:41
Default
  #10
Senior Member
 
Laurence R. McGlashan
Join Date: Mar 2009
Posts: 370
Rep Power: 23
l_r_mcglashan will become famous soon enough
scalarField is just like a list of scalar values.
volScalarField is more complicated. It has a list of scalar values that represent the variable's values within the cells (the internalField()) and lists of values that represent the variable's values at each boundary patch. The files in the folder 0/ are just printouts of these volScalarFields/volVectorFields.

My point is, are you solving for mfp/overallT? If you are, you need boundary conditions. If not, then unless mfp/overallT are supplying source terms at the boundary, then they don't need boundary values and can just be defined as scalarFields.
__________________
Laurence R. McGlashan :: Website
l_r_mcglashan is offline   Reply With Quote

Reply

Tags
exponent, power


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
if-loop, volScalarField comparison volker OpenFOAM 7 March 6, 2020 20:03
Problems with creating a volScalarField georlade OpenFOAM Programming & Development 4 December 4, 2016 12:31
volScalarField DiegoNaval OpenFOAM Programming & Development 7 February 2, 2012 03:04
Fill a volScalarField DiegoNaval OpenFOAM Programming & Development 6 November 19, 2010 09:26
chemical reaction - decompostition La S. Hyuck CFX 1 May 23, 2001 00:07


All times are GMT -4. The time now is 13:10.