View Issue Details

IDProjectCategoryView StatusLast Update
0000774OpenFOAMBugpublic2015-02-05 12:29
Reporternogenmyr Assigned Tohenry  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOScentOSOS Version5
Summary0000774: dynamicMeshDict not read...
Descriptionin $FOAM_SRC/engineMesh/fvMotionSolverEngineMesh/fvMotionSolverEngineMesh.C line 56 should be
     IOobject::MUST_READ

not
     IOobject::NO_READ

as currently. If not opened, the dictionary cannot be read by the constructors called upon construction of the velocityComponentLaplacianFvMotionSolver

Steps To ReproduceChange kiva test tutorial from layered to fvMotionSolver
TagsNo tags attached.

Activities

henry

2013-03-13 10:21

manager   ~0001988

motionSolver_
    (
        *this,
        IOdictionary
        (
            IOobject
            (
                "dynamicMeshDict",
                time().constant(),
                *this,
                IOobject::NO_READ,
                IOobject::NO_WRITE
            ),
            engineDB_.engineDict()
        )
    )

This dictionary is constructed from components not from read. If it were forcibly read the settings provided by engineDB_.engineDict() would not be used which doesn't make much sense.

nogenmyr

2013-03-13 11:18

reporter   ~0001989

Thanks! I see. Pasting the content of my dynamicMeshDict into engineGeometry makes it work as you planned. I was simply fooled by the error message that reads:

--> FOAM FATAL IO ERROR:
keyword velocityComponentLaplacianCoeffs is undefined in dictionary "/home/user/OpenFOAM/user-2.2.x/run/kivaTest/constant/dynamicMeshDict"

file: /home/user/OpenFOAM/user-2.2.x/run/kivaTest/constant/dynamicMeshDict from line 18 to line 34.

as if tried to read constant/dynamicMeshDict, when in fact it tried to find velocityComponentLaplacianCoeffs in constant/engineGeometry.

Regards,
Kalle

henry

2013-03-13 11:24

manager   ~0001990

The message could be corrected by changing the name in the constructor of motionSolver_ but this would clash with the name of engineDict ("engineGeometry"). It would be better if it simple re-used the engineDict but it is derived from it rather holds it as a reference so that won't work. Another option would be to keep the mesh motion controls in dynamicMeshDict rather than in "engineGeometry".

nogenmyr

2013-03-13 12:52

reporter   ~0001992

I would suggest the latter... but I agree it would be more elegant to have it all in engineGeometry.

wyldckat

2015-02-03 22:28

updater  

engineMesh_engineTime_friends.patch (1,858 bytes)   
diff --git a/src/engine/engineMesh/fvMotionSolverEngineMesh/fvMotionSolverEngineMesh.C b/src/engine/engineMesh/fvMotionSolverEngineMesh/fvMotionSolverEngineMesh.C
index 50ad374..117332b 100644
--- a/src/engine/engineMesh/fvMotionSolverEngineMesh/fvMotionSolverEngineMesh.C
+++ b/src/engine/engineMesh/fvMotionSolverEngineMesh/fvMotionSolverEngineMesh.C
@@ -46,7 +46,8 @@ Foam::fvMotionSolverEngineMesh::fvMotionSolverEngineMesh(const IOobject& io)
     motionSolver_
     (
         *this,
-        IOdictionary
+        engineDB_.engineIODict()
+        /*IOdictionary
         (
             IOobject
             (
@@ -57,7 +58,7 @@ Foam::fvMotionSolverEngineMesh::fvMotionSolverEngineMesh(const IOobject& io)
                 IOobject::NO_WRITE
             ),
             engineDB_.engineDict()
-        )
+        )*/
     )
 {
     engineDB_.engineDict().readIfPresent("pistonLayers", pistonLayers_);
diff --git a/src/engine/engineTime/engineTime.H b/src/engine/engineTime/engineTime.H
index f80504f..24c2926 100644
--- a/src/engine/engineTime/engineTime.H
+++ b/src/engine/engineTime/engineTime.H
@@ -57,6 +57,9 @@ SourceFiles
 #include "dictionary.H"
 #include "dimensionedScalar.H"
 
+class engineMesh;
+class fvMotionSolverEngineMesh;
+
 // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
 
 namespace Foam
@@ -70,6 +73,8 @@ class engineTime
 :
     public Time
 {
+        friend class engineMesh;
+        friend class fvMotionSolverEngineMesh;
     // Private data
 
         IOdictionary dict_;
@@ -95,6 +100,15 @@ class engineTime
         //- adjust read time values
         void timeAdjustment();
 
+protected:
+
+        //- Return the engine geometry dictionary
+        const IOdictionary& engineIODict() const
+        {
+            return dict_;
+        }
+  
+        
 public:
 
     // Constructors

wyldckat

2015-02-03 22:37

updater   ~0003665

Attached is the patch "engineMesh_engineTime_friends.patch" which is only a quick proof of concept that seemed to work for me with OpenFOAM 2.3.x, which is another possible solution beyond the ones presented.

The idea is essentially that:

1. The class "engineTime" could share in a protected way a new method "engineIODict()", which provides the dictionary in its original "IOdictionary" form as "const".

2. The class "engineTime" gives friendly permission to the class "engineMesh" to access said "engineIODict()", which in turn could allow derived methods to access said data.

3. In the attached patch the proof of concept is that "engineDB_.engineIODict()" provides direct "const" access to the necessary "IOdictionary" object, therefore no longer needing to create a dummy "IOdictionary" dubbed "dynamicMeshDict".


This can be coded in a much better way than the attached patch. But the questions that remain are:
a) Is this concept an acceptable solution?
b) Or does it goes against a few rules of good coding?

henry

2015-02-05 12:29

manager   ~0003693

Resolved by commit 608145622b826f9ad514dc36f5dfb805708be421 in OpenFOAM-dev

Issue History

Date Modified Username Field Change
2013-03-13 08:34 nogenmyr New Issue
2013-03-13 10:21 henry Note Added: 0001988
2013-03-13 11:18 nogenmyr Note Added: 0001989
2013-03-13 11:24 henry Note Added: 0001990
2013-03-13 12:52 nogenmyr Note Added: 0001992
2015-02-03 22:28 wyldckat File Added: engineMesh_engineTime_friends.patch
2015-02-03 22:37 wyldckat Note Added: 0003665
2015-02-05 12:29 henry Note Added: 0003693
2015-02-05 12:29 henry Status new => resolved
2015-02-05 12:29 henry Resolution open => fixed
2015-02-05 12:29 henry Assigned To => henry