2017-06-25 06:20 BST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002416OpenFOAM[All Projects] Bugpublic2017-01-08 23:52
ReporterSvensen 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
StatusnewResolutionopen 
PlatformGNU/LinuxOSUbuntuOS Version14.04
Product Versiondev 
Target VersionFixed in Version 
Summary0002416: surfacenormalfixedvalue. failed with timevarying boundary conditions
DescriptionI've tried to use a time-varying boundary conditions with the type surfaceNormalFixedValue. However, when I start pimpleFoam it says that:
--------------------------------------
Reading field p
Reading field U

--> FOAM FATAL IO ERROR:
wrong token type - expected Scalar, found on line 32 the word 'tableFile'

file: /home/sergey/simulation/prothmann_fusiform/0/U.boundaryField.inlet1.refValue at line 32.

    From function Foam::Istream& Foam::operator>>(Foam::Istream&, Foam::doubleScalar&)
    in file lnInclude/Scalar.C at line 93.

FOAM exiting
--------------------------------------
Code snippet is here:
inlet1
{
    type surfaceNormalFixedValue;
    refValue uniform tableFile;
    uniformValueCoeffs
    {
        fileName "$FOAM_CASE/bc/U.bc";
    }
}
Tagsboundary conditions
Attached Files

-Relationships
+Relationships

-Notes

~0007575

wyldckat (updater)

Nothing in the documentation of "surfaceNormalFixedValue", nor the code itself, indicates that this is a valid use of this boundary condition. Therefore, this is not a bug.

So I have to ask: What lead you to believe that this boundary condition would support that feature?

I ask this because the documentation doesn't mention anything list that and I can't find any indication in the release notes that would imply that:

  - http://openfoam.org/release/2-1-0/boundary-conditions-time-dependent/
  - http://openfoam.org/release/4-0/

~0007581

Svensen (reporter)

I've thought that time-varying value is also supported in surfaceNormalFixedValue as it was done for uniformFixedValue (using Function1), however it is not implemented yet.

It seems that
scalarField refValue_;

should be replaced by something like
autoPtr<Function1<Type>> refValue_;

but I'm not sure if it will work.

I will try to check this in the nearest days and will report the results.
+Notes

-Issue History
Date Modified Username Field Change
2016-12-31 12:05 Svensen New Issue
2016-12-31 12:05 Svensen Tag Attached: boundary conditions
2017-01-01 17:43 wyldckat Note Added: 0007575
2017-01-02 07:35 Svensen Note Added: 0007581
2017-01-08 23:52 wyldckat Severity minor => feature
+Issue History